1.系統構架演變

隨著網際網路的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也因此也不斷的演進、升級、迭代。從單一應用，到垂直拆分，到分散式服務，到SOA，以及現在火熱的微服務架構，還有在Google帶領下來勢洶湧的Service Mesh。我們到底是該乘坐微服務的船隻駛向遠方，還是偏安一隅得過且過？

2.集中式架構/單體應用

當網站流量很小時，只需要一個應用，將所有的功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的資料訪問框架（ORM）是影響專案開發的關鍵。

存在的問題：

• 程式碼耦合，開發維護困難
• 單點容錯率低，併發能力差

2.垂直拆分

當訪問量逐漸增大，單一應用無法滿足需求，此時為了應對更高的併發和業務需求，我們根據業務功能對系統進行拆分：
優點：

• 系統拆分實現了流量分擔，一定程度上解決了併發問題
• 系統間相互獨立
• 方便水平擴充套件，負載均衡，容錯率提高

缺點：

• 服務之間相互呼叫，如果某個服務的埠或者ip地址發生改變，呼叫的系統得手動改變
• 搭建叢集之後，實現負載均衡比較複雜

3.分散式服務

什麼是分散式：將一個大的系統拆分成多個子系統

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分散式呼叫是關鍵。

優點：

• 將基礎服務/公共介面 進行了抽取，系統間相互呼叫，提高了程式碼複用和開發效率

缺點：

• 系統間耦合度變高，呼叫關係錯綜複雜，難以維護
• 搭建叢集之後，負載均衡比較難實現

4.服務治理（SOA）

OOP:面向物件程式設計
AOP:面向切面程式設計
SOA:面向服務程式設計

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。此時，用於提高機器利用率的資源排程和治理中心(SOA)是關鍵
以前出現了什麼問題？

• 服務越來越多，需要管理每個服務的地址
• 呼叫關係錯綜複雜，難以理清依賴關係
• 服務過多，服務狀態難以管理，無法根據服務情況動態管理

服務治理要做什麼？

• 服務註冊中心，實現服務自動註冊和服務自動發現（無需人為記錄服務地址）
• 服務自動訂閱，服務列表自動推送，服務呼叫透明化（無需關心依賴關係）
• 自動監控服務狀態（人為控制服務狀態）

缺點：

• 服務間會有依賴關係，一旦某個環節出錯會影響較大
• 服務關係複雜，運維、測試部署困難，不符合DevOps思想（docker）

5.微服務

OOP：面向物件
AOP：面向切面
SOA：面向服務
前面說的SOA，英文翻譯過來是面向服務的程式設計。微服務，似乎也是服務，都是對系統進行拆分。因此兩者非常容易混淆，但其實卻有一些差別：
微服務的特點：

• 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
• 微：微服務的服務拆分粒度很小，例如一個使用者管理就可以作為一個服務。每個服務雖小，但“五臟俱全”。
• 獨立：自治是說服務間互相獨立，互不干擾
  • 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多。
  • 技術獨立：因為是面向服務，提供Rest介面，使用什麼技術沒有別人干涉
  • 前後端分離：採用前後端分離開發，提供統一Rest介面，後端不用再為PC、移動端開發不同介面
  • 資料庫分離：每個服務都使用自己的資料來源
  • 部署獨立，服務間雖然有呼叫，但要做到服務重啟不影響其它服務。有利於持續整合和持續交付。每個服務都是獨立的元件，可複用，可替換，降低耦合，易維護 Docker部署服務

微服務結構圖：