[轉]系統架構演變--集中式架構-垂直拆分-分佈式服務-SOA(服務治理)-微服務

一.系統架構演變

1.1. 集中式架構

當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。此時，用於簡化增刪改查工做量的數據訪問框架(ORM)是影響項目開發的關鍵。

存在的問題：

代碼耦合，開發維護困難
沒法針對不一樣模塊進行鍼對性優化
沒法水平擴展
單點容錯率低，併發能力差
1.2.垂直拆分

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

優勢：

系統拆分實現了流量分擔，解決了併發問題
能夠針對不一樣模塊進行優化
方便水平擴展，負載均衡，容錯率提升
系統間相互獨立
缺點：

服務之間相互調用，若是某個服務的端口或者ip地址發生改變，調用的系統得手動改變
搭建集羣以後，實現負載均衡比較複雜
1.3.分佈式服務

當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提升業務複用及整合的分佈式調用是關鍵。

 

優勢：

將基礎服務進行了抽取，系統間相互調用，提升了代碼複用和開發效率
缺點：

系統間耦合度變高，調用關係錯綜複雜，難以維護
搭建集羣以後，負載均衡比較難實現
1.4.服務治理（SOA）

當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。此時，用於提升機器利用率的資源調度和治理中心(SOA)是關鍵

阿里巴巴內部目前使用的框架：HSF（好舒服），是dubbo的升級版

之前出現了什麼問題？

服務愈來愈多，須要管理每一個服務的地址
調用關係錯綜複雜，難以理清依賴關係
服務過多，服務狀態難以管理，沒法根據服務狀況動態管理
服務治理要作什麼？

服務註冊中心，實現服務自動註冊和發現，無需人爲記錄服務地址
服務自動訂閱，服務列表自動推送，服務調用透明化，無需關心依賴關係
動態監控服務狀態監控報告，人爲控制服務狀態
缺點：

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

OOP：面向對象

AOP：面向切面

SOA：面向服務

前面說的SOA，英文翻譯過來是面向服務的編程。微服務，彷佛也是服務，都是對系統進行拆分。所以二者很是容易混淆，但其實卻有一些差異：

 

微服務的特色：

單一職責：微服務中每個服務都對應惟一的業務能力，作到單一職責
微：微服務的服務拆分粒度很小，例如一個用戶管理就能夠做爲一個服務。每一個服務雖小，但「五臟俱全」。
面向服務：面向服務是說每一個服務都要對外暴露服務接口API。並不關心服務的技術實現，作到與平臺和語言無關，也不限定用什麼技術實現，只要提供Rest的接口便可。
自治：自治是說服務間互相獨立，互不干擾
團隊獨立：每一個服務都是一個獨立的開發團隊，人數不能過多。
技術獨立：由於是面向服務，提供Rest接口，使用什麼技術沒有別人干涉
先後端分離：採用先後端分離開發，提供統一Rest接口，後端不用再爲PC、移動端開發不一樣接口
數據庫分離：每一個服務都使用本身的數據源
部署獨立，服務間雖然有調用，但要作到服務重啓不影響其它服務。有利於持續集成和持續交付。每一個服務都是獨立的組件，可複用，可替換，下降耦合，易維護 Docker部署服務
缺點

開發人員要處理分佈式系統的複雜性
部署複雜
多服務運維難度 隨着服務的增長 運維的壓力也在增大
微服務結構圖：

參考文獻：
一、原文：系統架構演變--集中式架構-垂直拆分-分佈式服務-SOA(服務治理)-微服務

二、軟件架構的演進，瞭解單體架構，垂直架構，SOA架構和微服務架構的變化歷程

三、分佈式架構的演進過程(詳細版)