先講一講架構的演變
1.單體架構（集中式架構）
項目功能比較簡單，一個項目就需要一個應用，里面有多個模塊，所有功能部署在一起，這樣的好處是部署節點的成本比較低。
缺點：耦合性太強；開發維護困難、無法水平拓展；容錯性低，並發能力差。
2.垂直拆分架構
訪問量變大了，單一的應用服務無法滿足需求，為了應對更高的並發和業務需求，就要根據業務對系統進行拆分。
優點：
- 實現了流量分擔，處理並發請求的能力提高。
- 降低了耦合型，我們再對某個模塊進行優化的時候更加方便了。
- 水平擴展變得方便了。
- 容錯率提高了。
缺點：
- 會有大量的重復代碼，影響開發效率。
3.分布式服務
當業務越來越多、越來越復雜時，不只是垂直應用這一條線進行數據調用，可能說，應用之間也會相互調用，可能會為了完成一個業務功能，需要多個小模塊之間相互調用。
優點：
- 將服務粒度細化，減少了代碼的重復率，提高了代碼復用率，提升了開發效率。
- 系統之間耦合度變高了，調用關系錯綜復雜，比較難以管理。
4.服務治理架構SOA
當服務越來越多，一些小問題比如容量的評估、小服務的資源浪費問題開始顯現出來，這個時候就需要一個服務調度中心基於訪問壓力實時管理集群容量，提高集群利用率。
以前分布式服務的問題：
- 服務很多，服務的地址難管理
- 服務過多，服務的狀態難以管理，無法根據服務的情況進行管理
SOA服務治理架構的優點：
- 提供一個服務注冊中心，實現服務的自動注冊與發現，無需人為記錄服務地址。
- 服務自動訂閱，服務列表自動推送，服務的調用透明化，無需關心依賴關系。
- 動態的監控服務狀態，人為控制服務狀態。
SOA服務治理架構的缺點：
- 依賴關系是無法避免的，一旦某個環節出錯影響較大。
- 服務關系依舊是復雜的，運維、測試、部署困難，不符合開發-運維一站式維護的思想。
5.微服務
微服務的特點：
- 單一職責：一個微服務只對應一個業務能力，也就是粒度很小。
- 微：拆分的粒度小，但是該有的機制都有。
- 面向服務：每個服務都要對外暴露Restful風格的API。但並不關系業務具體是怎么實現的，比如說是用哪種語言寫的、在哪個平台開發的。
- 自治：是說服務之間相互獨立，互不干擾，不是自我管理。
- 團隊獨立：每個服務都由一個獨立的開發團隊完成，人數不宜過多。
- 技術獨立：只要實現業務功能，提供restful接口即可，不關心內部的實現邏輯、語言、開發平台。
- 前后端分離：提供統一的restful風格接口，后端不用再為PC、移動端開發不同的接口。
- 數據庫分離：每個服務都使用自己的數據源。
- 部署獨立：盡管服務間是有調用關系的，但也要做到一個微服務重啟不影響其他微服務。有利於持續集成、持續交付。每個服務都是獨立的組件，可復用、可替換、易維護。