本篇文章先簡單介紹了互聯網架構的演變，進而介紹了服務化，最後再介紹微服務，微服務是服務治理的升級也是互聯網架構的進一步延伸。
互聯網架構演變
一體架構
在計算機軟件發展早期，一般桌面軟件都是採用這種架構，不管是界面還是業務處理還是數據處理都放到一個包中。這種其實談不上架構，但也可以說是很好的架構，因爲它足夠簡單。
mvc架構
但隨着瀏覽器的出現便產生了web應用，web應用的特點是界面部分是顯示在瀏覽器中，服務處理是在服務容器中的，頁面顯示一般用css+js+html技術來處理，而後端可以用Java、PHP等語言，這就產生了前後端分離。對於web系統，一體架構難以滿足前後端分離的開發需求，因而便產生了MVC架構。
MVC纔算的上真正意義上的架構，因爲它除了解決了前後端分離問題，還引入了一種全新的開發模式，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，使得整個應用層次更加分明，而且各個層次之間不但減低了耦合性，還提高了各個層次的可重用性。
但隨着應用規模的不斷擴大，應用模塊不斷增加，整個應用也顯得越來越臃腫，維護起來也更加困難，因此便又產生了多應用架構。
多應用架構
多應用架構很簡單，就是把原來的應用按照業務特點拆分成多個應用。比如一個大型電商系統可能包含用戶系統、商品系統、訂單系統、評價系統等等，我們可以把他們獨立出來形成一個個單獨的應用。多應用架構的特點是應用之間各自獨立 ，不相互調用。
多應用雖然解決了應用臃腫問題，但應用之間相互獨立，有些共同的業務或代碼無法複用。
分佈式架構
對於一個大型的互聯網系統，一般會包含多個應用，而且應用之間往往還存在共同的業務，並且應用之間還存在調用關係。除此之外 ，對於大型的互聯網系統還有一些其它的挑戰，比如如何應對急劇增長的用戶，如何管理好研發團隊快速迭代產品研發，如何保持產品升級更加穩定等等 。
因此，爲了使業務得到很好的複用，模塊更加容易拓展和維護，我們希望業務與應用分離，某個業務不再屬於一個應用，而是作爲一個獨立的服務單獨進行維護。應用本身不再是一個臃腫的模塊堆積，而是由一個個模塊化的服務組件組合而成。
服務化
服務化的特點
上面介紹的分佈式架構即服務化。我們再總結一下，服務化主要有如下特點：
- 應用按業務拆分成服務
- 各個服務均可獨立部署
- 服務可被多個應用共享
- 服務之間可以通信
服務化的好處
那麼企業採用服務化有哪些好處呢？
- 架構上系統更加清晰
- 核心模塊穩定，以服務組件爲單位進行升級，避免了頻繁發佈帶來的風險
- 開發管理方便
- 單獨團隊維護、工作分明，職責清晰
- 業務複用、代碼複用
- 非常容易拓展
服務化實現方式
如果要實現服務化的話，最常用的方式就是利用RPC框架。因爲服務組件一般分佈在不同的服務器上，所以要實現服務化需要解決的第一個問題就是RPC**遠程服務調用**。類似於RPC方案有很多，比如：
- Java RMI
- WebService
- Hessian
- Http
- Thrift
- … …
服務化面臨的挑戰
上面提到要實現服務化首先需要解決遠程服務調用問題，除此之外，還有很多其他問題需要解決。
- 服務越來越多，配置管理複雜
- 服務間依賴關係複雜
- 服務之間的負載均衡
- 服務的拓展
- 服務監控
- 服務降級
- 服務鑑權
- 服務上線與下線
- 服務文檔
- … …
服務治理
上面提到了服務化，其實要想服務化，服務治理是關鍵。那麼有沒有好的服務治理方案呢？答案是有的，而且很多人都在用這個框架，他就是-dubbo。dubbo就是一個帶有服務治理功能的RPC框架。
dubbo提供了一套較爲完整的服務治理方案，所以企業如果要實現服務化的話，dubbo 是很好的一個選擇。這裏簡單介紹一下dubbo服務治理相關方案。
服務發現註冊
服務治理領域最重要的問題就是服務發現與註冊。dubbo中引入了一個註冊中心的概念，服務的註冊與發現主要就依賴這個服務中心。
dubbo註冊中心服務註冊發現的具體過程：
- 服務提供者啓動，向註冊中心註冊自己提供的服務
- 消費者啓動，向註冊中心訂閱自己需要的服務
- 註冊中心返回服務提供者的列表給消費者
- 消費者從服務提供者列表中，按照軟負載均衡算法，選擇一臺發起請求
服務監控
集羣容錯
負載均衡
- Random Loadbalance
- RoundRobin
- LeastActive
- ConsistentHash
dubbo服務治理優勢
- 註冊中心只負責註冊查找，不負責請求轉發，壓力小
- 註冊中心宕機影響消費者，消費者本地緩存服務地址列表
- 註冊中心對等集羣，宕掉一臺自動切換到另外 一臺
- 服務提供者無狀態，可動態部署，註冊中心負責推送
- 統計無壓力，本地內存中累計次數，每分鐘發送註冊中心
- 消費者調用服務者，自動軟負載均衡
- 通過服務中心可追蹤依賴關係
- 監控中心爲擴容和降級提供依據
- 可啓用acl機制進行鑑權
- 與Spring整合，接入簡單鬆耦合
- 多種序列化協議支持
dubbo的不足
- 消費者仍需要依賴配置中心
- 消費者仍需要依賴jar包配置provider
- 提供者文檔管理功能缺失
- 無統一入口
- 不支持OAuth2.0
- 內部鑑權不方便管理
- 無外部應用鑑權
- 接口基本裸奔，無法直接對外暴露服務
- IT治理不方便
微服務
現在很多人都在談微服務，那麼到底什麼是微服務呢？這裏談談我對微服務的理解。
微服務有兩個核心：
- 微：服務的粒度要細，即服務要細化到API
- 服務：提供好服務，要讓用戶感到好用(要做到這一點很不容易)
上面兩個核心總結起來，可以用下面這幅圖表示：
從上面這幅圖看出，微服務特別簡單（好的架構就應該簡單），我們把服務再拆分成一個個API，API是一個完整的功能。然後我們把API扔到一個“雲上”，然後用戶就可以到“雲上”獲取所有API的服務，這個“雲”保證能提供好的服務。
我們可以看到，有了微服務之後，服務對用戶來說變得特別簡單，而且上面dubbo的不足之處在微服務這裏都解決了。使用者不再需要依賴任何jar包，不再需要去註冊中心查找服務，不再去做鑑權處理，不用擔心服務掛掉，不用擔心不會使用服務，所有的問題這個“雲”都解決了。這也是微服務的核心之一，提供好服務。
說到這裏，大家就應該大體知道該怎麼做微服務了，圖中的“雲”是關鍵。下面我們就慢慢撥開這朵雲。
微服務的實現
微服務的關鍵是服務網關，所以，上面提到的“雲”就是服務網關。要做微服務，我們先定義一下微服務需要具備的特點。
微服務的特點
服務需要再細化成API（服務接口——>服務API）
- 每個服務由一組API組成
- 以API形式對外提供統一格式的服務
- 使用者無需任何配置，直接調用（http）
- 完整的API文檔
- API服務安全可靠穩定
微服務要解決的問題
上面提到了，dubbo還存在一些問題 ，其實dubbo存在的問題 就是 微服務要解決的問題，這裏 再總結一下。當然，dubbo和微服務的側重點不一樣，dubbo側重於內部接口之間的RPC，而微服務則側重於對外提供服務。
- 統一入口
- 安全控制：防刷限流
- 統一鑑權：應用鑑權、用戶鑑權、OAuth鑑權、ACL
- 協議轉換：http、dubbo、Protobuf
- API配置管理
- API上線、下線
- API與服務接口映射
- 監控與報警
- 整體架構的可拓展、高併發、分佈式
- 服務容器自動收縮、擴容
實現方案
- 負載均衡層：nginx/lvs/F5
- 微服務層
- 高性能服務網關
- 統一入口、API配置管理、分流鑑權、服務監控、協議轉換
- API映射、OAuth2.0、API文檔管理
- 分佈式、可拓展
- 服務治理層
- 成熟的服務治理框架dubbo
- MQ服務之間解耦
- 彈性雲
- 服務docker化
- 基於訪問壓力的實時集羣調度與管理
彈性雲
這裏簡單介紹一下彈性雲的概念，微服務要想提供好服務，保證API不能掛掉並且有好的性能，需要很高的運維要求。這裏的彈性雲便是自動化運維解決方案，對訪問壓力進行監控，根據監控解決調度應用的發佈和回收。
