系統架構演變

引言

1. 隨着互聯網的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也因此也不斷的演進、升級、迭代。從單一應用，到垂直拆分，到分佈式服務，到SOA，以及現在火熱的微服務架構，還有在Google倡導的的Service Mesh等新一代微服務技術。
2. 因此，瞭解系統架構演變的歷史，理解微服務出現的必要性也是我們學習微服務之前的一個必要的階段

集中式架構

1. 當項目體量較小時，只需要一個應用，集合所有的功能於一個項目內的架構模式成爲集中式架構。入門時學習過的J2EE的電商項目就是典型的集中式架構的項目
2. 圖片示例
   
3. 弊端
   1. 功能鍵代碼耦合度高，開發維護困難
   2. 無法針對不同模塊進行鍼對優化（不同模塊優化的方向不盡相同）
   3. 無法水平拓展
   4. 單點容錯率低，併發能力差

垂直拆分

1. 對於集中式架構，當項目體量變大，用戶訪問量增加，單一應用已無法滿足需求。例如任意的中型網站如噹噹網等，項目的各種功能不可能全部集中於一起。此時爲了應對更高的併發和業務需求，可以根據業務功能對系統進行拆分
2. 圖片示例
   
3. 優點
   1. 系統拆分實現了流量分擔，解決了併發問題
   2. 可以針對不同模塊進行優化
   3. 方便水平擴展，負載均衡，容錯率提高
4. 缺點
   1. 系統間相互獨立，可能會存在一些模塊重複出現在不同的功能中，影響效率開發

分佈式服務

1. 在垂直拆分的基礎上，當服務越來越多，應用間的交互就不可避免。此時，可以將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能夠更快速的響應用戶需求。此時，影響系統性能的因素更多的是如何提高業務複用率以及如何整合分佈式調用
2. 圖片示例
   
3. 優點
   將基礎服務進行了抽取，系統間相互調用，提高了代碼複用和開發效率
4. 缺點
   系統間耦合度變高，調用關係錯綜複雜，難以維護

服務治理（SOA）

1. 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。此時，用於提高機器利用率的資源調度和治理中心(SOA)是關鍵
2. 圖片示例
   
3. 分佈式處理的問題：
   錯綜複雜的服務之間彼此調用，某個服務出現意外容易引發一系列連鎖反應，難以動態管理各種服務的即時信息
4. 服務治理目標：
   註冊中心統一管理所有的服務，服務向註冊中心發送自己即時的狀態信息，同時，以註冊中心爲中轉站，調用其他服務
5. 缺點
   1. 服務間會有依賴關係，一旦某個環節出錯會影響較大
   2. 服務關係複雜，運維、測試部署困難，不符合DevOps思想

微服務

1. 前面說的SOA，英文翻譯過來是面向服務。微服務，似乎也是服務，都是對系統進行拆分。因此兩者非常容易混淆，但其實缺有一些差別
   
2. 微服務的特點
   1. 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
   2. 微：微服務的服務拆分粒度很小，例如一個用戶管理就可以作爲一個服務。每個服務雖小，但“五臟俱全”
   3. 面向服務：面向服務是說每個服務都要對外暴露服務接口API。並不關心服務的技術實現，做到與平臺和語言無關，也不限定用什麼技術實現，只要提供Rest的接口即可
   4. 自治：自治是說服務間互相獨立，互不干擾
3. 微服務結構圖
   

總結

1. 與之前各種新技術的出現一樣，系統架構的演變也是由於項目體量不斷變大，訪問量不斷增多，原有的架構模式開發維護起來冗餘，複雜。
2. 架構演變也是由最初的整體開發到後來的以服務爲單位進行管理，最終目的仍然是爲了使項目開發維護時候更方便，邏輯上更加明瞭，也便於後期的更新等
3. 無論 SOA 還是 微服務都是面向服務的思想，即將項目內的各種功能模塊作爲面向的對象
4. 微服務即生成一個對象用來管理項目內的各種服務對象，各種服務對象將自己的實時信息交付給這個中轉站，同時也通過這個中轉站調用其他的服務。