微服務系統架構演變
1.系統架構演變
隨著互聯網的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也因此也不斷的演進、升級、叠代。從單一應用，到垂直拆分，到分布式服務，到SOA，以及現在火熱的微服務架構，還有在Google帶領下來勢洶湧的Service Mesh。我們到底是該乘坐微服務的船只駛向遠方，還是偏安一隅得過且過？
其實生活不止眼前的茍且，還有詩和遠方。所以我們今天就回顧歷史，看一看系統架構演變的歷程；把握現在，學習現在最火的技術架構；展望未來，爭取成為一名優秀的Java工程師。
1.1. 集中式架構/單體應用
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的數據訪問框架(ORM)是影響項目開發的關鍵。
存在的問題：
- 代碼耦合，開發維護困難
- 無法針對不同模塊進行針對性優化
- 無法水平擴展
- 單點容錯率低，並發能力差
1.2.垂直拆分
當訪問量逐漸增大，單一應用無法滿足需求，此時為了應對更高的並發和業務需求，我們根據業務功能對系統進行拆分：
優點：
- 系統拆分實現了流量分擔，解決了並發問題
- 可以針對不同模塊進行優化
- 方便水平擴展，負載均衡，容錯率提高
- 系統間相互獨立
缺點：
- 服務之間相互調用，如果某個服務的端口或者ip地址發生改變，調用的系統得手動改變
- 搭建集群之後，實現負載均衡比較復雜
1.3.分布式服務
什麽是分布式：將一個大的系統拆分成多個子系統
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務復用及整合的分布式調用是關鍵。
優點：
- 將基礎服務進行了抽取，系統間相互調用，提高了代碼復用和開發效率
缺點：
- 系統間耦合度變高，調用關系錯綜復雜，難以維護
- 搭建集群之後，負載均衡比較難實現
1.4.服務治理（SOA）
OOP:面向對象編程
AOP:面向切面編程
SOA:面向服務編程
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。此時，用於提高機器利用率的資源調度和治理中心(SOA)是關鍵
阿裏巴巴內部目前使用的框架：HSF（好舒服），是dubbo的升級版
以前出現了什麽問題？
- 服務越來越多，需要管理每個服務的地址
- 調用關系錯綜復雜，難以理清依賴關系
- 服務過多，服務狀態難以管理，無法根據服務情況動態管理
服務治理要做什麽？
- 服務註冊中心，實現服務自動註冊和發現，無需人為記錄服務地址
- 服務自動訂閱，服務列表自動推送，服務調用透明化，無需關心依賴關系
- 動態監控服務狀態監控報告，人為控制服務狀態
缺點：
- 服務間會有依賴關系，一旦某個環節出錯會影響較大
- 服務關系復雜，運維、測試部署困難，不符合DevOps思想（docker）
1.5.微服務
OOP：面向對象
AOP：面向切面
SOA：面向服務
前面說的SOA，英文翻譯過來是面向服務的編程。微服務，似乎也是服務，都是對系統進行拆分。因此兩者非常容易混淆，但其實卻有一些差別：
微服務的特點：
- 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
- 微：微服務的服務拆分粒度很小，例如一個用戶管理就可以作為一個服務。每個服務雖小，但“五臟俱全”。
- 面向服務：面向服務是說每個服務都要對外暴露服務接口API。並不關心服務的技術實現，做到與平臺和語言無關，也不限定用什麽技術實現，只要提供Rest的接口即可。
- 自治：自治是說服務間互相獨立，互不幹擾
- 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多。
- 技術獨立：因為是面向服務，提供Rest接口，使用什麽技術沒有別人幹涉
- 前後端分離：采用前後端分離開發，提供統一Rest接口，後端不用再為PC、移動端開發不同接口
- 數據庫分離：每個服務都使用自己的數據源
- 部署獨立，服務間雖然有調用，但要做到服務重啟不影響其它服務。有利於持續集成和持續交付。每個服務都是獨立的組件，可復用，可替換，降低耦合，易維護 Docker部署服務
微服務結構圖：
微服務系統架構演變