項目系統架構-微服務架構
- 1. 系統架構演變
-
- 1.1 集中式架構
- 1.2 垂直拆分
- 1.3 分布式服務
- 1.4 服務治理（SOA）
- 1.5 微服務
- 2. 服務間遠端調用方式
-
- 2.1 RPC
- 2.2 Http
- 2.3 兩者比較
1. 系統架構演變
随着網際網路的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也是以也不斷的演進、更新、疊代。從單一應用，到垂直拆分，到分布式服務，到SOA，以及現在火熱的微服務架構，還有在Google帶領下來勢洶湧的Service Mesh。
1.1 集中式架構
當網站流量很小時，隻需一個應用，将所有功能都部署在一起，以減少部署節點和成本。此時，用于簡化增删改查工作量的資料通路架構(ORM)是影響項目開發的關鍵。
存在的問題：
- 代碼耦合，開發維護困難
- 無法針對不同子產品進行針對性優化
- 無法水準擴充
- 單點容錯率低，并發能力差
1.2 垂直拆分
當通路量逐漸增大，單一應用無法滿足需求，此時為了應對更高的并發和業務需求，需要根據業務功能對系統進行拆分 （即進行功能劃分）
優點：
- 系統拆分實作了流量分擔，解決了并發問題
- 可以針對不同子產品進行優化
- 友善水準擴充，負載均衡，容錯率提高
缺點：
- 系統間互相獨立，會有很多重複開發工作，影響開發效率
1.3 分布式服務
當垂直應用越來越多，應用之間互動不可避免，将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用于提高業務複用及整合的分布式調用是關鍵。
優點：
- 将基礎服務進行了抽取，系統間互相調用，提高了代碼複用和開發效率
缺點：
- 系統間耦合度變高，調用關系錯綜複雜，難以維護
1.4 服務治理（SOA）
SOA ：面向服務的架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基于通路壓力實時管理叢集容量，提高叢集使用率。此時，用于提高機器使用率的資源排程和治理中心(SOA)是關鍵
以前出現了什麼問題？
- 服務越來越多，需要管理每個服務的位址
- 調用關系錯綜複雜，難以理清依賴關系
- 服務過多，服務狀态難以管理，無法根據服務情況動态管理
服務治理要做什麼？
- 服務注冊中心，實作服務自動注冊和發現，無需人為記錄服務位址
- 服務自動訂閱，服務清單自動推送，服務調用透明化，無需關心依賴關系
- 動态監控服務狀态監控報告，人為控制服務狀态
缺點：
- 服務間會有依賴關系，一旦某個環節出錯會影響較大
- 服務關系複雜，運維、測試部署困難，不符合DevOps思想
1.5 微服務
前面說的SOA，英文翻譯過來是面向服務。微服務，似乎也是服務，都是對系統進行拆分。是以兩者非常容易混淆，但其實缺有一些差别：
微服務的特點：（多了服務的治理）
- 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
- 微：微服務的服務拆分粒度很小，例如一個使用者管理就可以作為一個服務。每個服務雖小，但“五髒俱全”。
- 面向服務：面向服務是說每個服務都要對外暴露Rest風格服務接口API。并不關心服務的技術實作，做到與平台和語言無關，也不限定用什麼技術實作，隻要提供Rest的接口即可。
- 自治：自治是說服務間互相獨立，互不幹擾
- 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多。
- 技術獨立：因為是面向服務，提供Rest接口，使用什麼技術沒有别人幹涉
- 前後端分離：采用前後端分離開發，提供統一Rest接口，後端不用再為PC、移動段開發不同接口
- 資料庫分離：每個服務都使用自己的資料源
- 部署獨立，服務間雖然有調用，但要做到服務重新開機不影響其它服務。有利于持續內建和持續傳遞。每個服務都是獨立的元件，可複用，可替換，降低耦合，易維護
微服務結構圖：
2. 服務間遠端調用方式
無論是微服務還是SOA，都面臨着服務間的遠端調用。那麼服務間的遠端調用方式有哪些呢？
常見的遠端調用方式有以下幾種：
- RPC：Remote Produce Call遠端過程調用，類似的還有RMI。自定義資料格式，基于原生TCP通信，速度快，效率高。早期的webservice，現在熱門的dubbo，都是RPC的典型
-
Http：http其實是一種網絡傳輸協定，基于TCP，規定了資料傳輸的格式。現在用戶端浏覽器與服務端通信基本都是采用Http協定。也可以用來進行遠端服務調用。缺點是消息封裝臃腫。
現在熱門的Rest風格，就可以通過http協定來實作。
2.1 RPC
RPC，即 Remote Procedure Call（遠端過程調用），是一個計算機通信協定。 該協定允許運作于一台計算機的程式調用另一台計算機的子程式，而程式員無需額外地為這個互動作用程式設計。說得通俗一點就是：A計算機提供一個服務，B計算機可以像調用本地服務那樣調用A計算機的服務。
實作RPC主要是做到兩點：
- 實作遠端調用其他計算機的服務
- 要實作遠端調用，肯定是通過網絡傳輸資料。A程式提供服務，B程式通過網絡将請求參數傳遞給A，A本地執行後得到結果，再将結果傳回給B程式。這裡需要關注的有兩點：
- 1）采用何種網絡通訊協定？
- 現在比較流行的RPC架構，都會采用TCP作為底層傳輸協定
- 2）資料傳輸的格式怎樣？
- 兩個程式進行通訊，必須約定好資料傳輸格式。就好比兩個人聊天，要用同一種語言，否則無法溝通。是以，我們必須定義好請求和響應的格式。另外，資料在網路中傳輸需要進行序列化，是以還需要約定統一的序列化的方式。
- 1）采用何種網絡通訊協定？
- 要實作遠端調用，肯定是通過網絡傳輸資料。A程式提供服務，B程式通過網絡将請求參數傳遞給A，A本地執行後得到結果，再将結果傳回給B程式。這裡需要關注的有兩點：
- 像調用本地服務一樣調用遠端服務
- 如果僅僅是遠端調用，還不算是RPC，因為RPC強調的是過程調用，調用的過程對使用者而言是應該是透明的，使用者不應該關心調用的細節，可以像調用本地服務一樣調用遠端服務。是以RPC一定要對調用的過程進行封裝
RPC調用流程圖：
2.2 Http
Http協定：超文本傳輸協定，是一種應用層協定。規定了網絡傳輸的請求格式、響應格式、資源定位和操作的方式等。但是底層采用什麼網絡傳輸協定，并沒有規定，不過現在都是采用TCP協定作為底層傳輸協定。說到這裡，大家可能覺得，Http與RPC的遠端調用非常像，都是按照某種規定好的資料格式進行網絡通信，有請求，有響應。沒錯，在這點來看，兩者非常相似，但是還是有一些細微差别。
- RPC并沒有規定資料傳輸格式，這個格式可以任意指定，不同的RPC協定，資料格式不一定相同。
- Http中還定義了資源定位的路徑，RPC中并不需要
- 最重要的一點：RPC需要滿足像調用本地服務一樣調用遠端服務，也就是對調用過程在API層面進行封裝。Http協定沒有這樣的要求，是以請求、響應等細節需要我們自己去實作。
- 優點：RPC方式更加透明，對使用者更友善。Http方式更靈活，沒有規定API和語言，跨語言、跨平台
- 缺點：RPC方式需要在API層面進行封裝，限制了開發的語言環境。
例如我們通過浏覽器通路網站，就是通過Http協定。隻不過浏覽器把請求封裝，發起請求以及接收響應，解析響應的事情都幫我們做了。如果是不通過浏覽器，那麼這些事情都需要自己去完成。
2.3 兩者比較
相同點：都是按照某種規定好的資料格式進行網絡通信，有請求，有響應。
不同點：
- RPC并沒有規定資料傳輸格式，這個格式可以任意指定，不同的RPC協定，資料格式不一定相同。
- Http中還定義了資源定位的路徑，RPC中并不需要
- 最重要的一點：RPC需要滿足像調用本地服務一樣調用遠端服務，也就是對調用過程在API層面進行封裝。Http協定沒有這樣的要求，是以請求、響應等細節需要我們自己去實作。
- 優點：RPC方式更加透明，對使用者更友善。Http方式更靈活，沒有規定API和語言，跨語言、跨平台
- 缺點：RPC方式需要在API層面進行封裝，限制了開發的語言環境。
如何選擇
- 速度來看，RPC要比http更快，雖然底層都是TCP，但是http協定的資訊往往比較臃腫，不過可以采用gzip壓縮。
- 難度來看，RPC實作較為複雜，http相對比較簡單
- 靈活性來看，http更勝一籌，因為它不關心實作細節，跨平台、跨語言。
是以，兩者都有不同的使用場景：
- 如果對效率要求更高，并且開發過程使用統一的技術棧，那麼用RPC還是不錯的。
- 如果需要更加靈活，跨語言、跨平台，顯然http更合适
微服務，更加強調的是獨立、自治、靈活。而RPC方式的限制較多，是以微服務架構中，一般都會采用基于Http的Rest風格服務。