目錄
架構的演進
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的數據訪問框架（ORM）是關鍵。
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
分佈式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分佈式服務框架（RPC）是關鍵。
什麼是RPC？
RPC——Remote Procedure Call,遠程過程調用。 即服務A調用服務B的方法，那就需要解決如下兩個問題：
- 解決分佈式系統中，服務之間的調用問題
- 遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
圖中Client對應服務A，Server對應服務B
- 1.Service A的應用層代碼中，調用了Calculator的一個實現類add()方法，希望執行一個加法運算；
- 2.這個Calculator實現類，內部並不是直接實現具體的加減乘除邏輯，而是通過遠程調用Service B的RPC接口，來獲取運算結果，因此稱爲Stub；
- 3.Stub怎麼和Service B建立遠程通訊呢？這時候就要用到遠程通訊工具了，也就是圖中的Run-Time-Library，這個工具將幫你實現遠程通訊的功能，比如Java的Socket，當然也可以使用基於Http協議的HTTPClient，或者其他的。-- RPC並沒有規定要用何種協議進行通訊。
- 4.Stub通過調用通訊工具提供的方法，和Service B建立了通訊，然後將請求數據發給Service B。需要注意的是，由於底層的網絡通訊是基於二進制格式的，因此這裏Stub傳給通訊工具類的數據也必須是二進制，比如calculator.add(1,2)，你必須把參數值1和2放到一個Request對象裏面（這個Request對象還包括調用哪個服務的哪個RPC接口等其他信息），然後序列化爲二進制，再傳給通訊工具類。
- 5.二進制的數據傳到Service B這邊了，Service B當然也有自己的通訊工具，通過這個通訊工具接受二進制的請求；
- 6.既然數據是二進制的，那麼自然要進行反序列化了，將二進制的數據反序列化爲請求對象，然後將這個請求對象交給Service B的Stub處理；
- 7.和之前的Service A的Stub一樣，這裏的Stub也同樣是個“假玩意”，它所負責的，只是去解析請求對象，知道調用方要調的是哪個RPC接口，傳進來的參數又是什麼，然後再把這些參數傳給對應的RPC接口，也就是Calculator的實際實現類去執行。很明顯，如果是Java，那這裏肯定用到了反射。
- 8.RPC接口執行完畢，返回執行結果，現在輪到Service B要把數據發給Service A了，怎麼發？一樣的流程，只是現在Service B變成了Client，Service A變成了Server而已：Service B序列化執行結果->傳輸給Service A->Service A反序列化執行結果->將結果返回給Application。
RPC–參考資料
RPC和REST區別
RPC
REST
在微服務設計中，一個服務A如果訪問另一個Module下的服務B，可以採用HTTP REST傳輸數據，並在兩個服務之間進行序列化和反序列化操作，服務B把執行結果返回過來。
由於Http在應用層中完成，整個通信的代價較高，遠程過程調用（RPC）中直接基於TCP進行遠程調用，數據傳輸在傳輸層TCP層完成，更適合對效率要求比較高的場景，RPC主要依賴於客戶端和服務端之間建立Socket鏈接進行，底層實現比REST更復雜。
延伸：dubbo基於TCP，spring cloud Feign基於HTTP
Spring Cloud Feign–參考資料
GRPC–類似dubbo的調用過程了
RPC、REST、GRPC比較–參考鏈接
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。此時提高機器利用率的資源調度和治理中心（SOA）是關鍵。
SOA
SOA（Service Orientd Architecture）“面向服務的架構”–是一種設計方法，其中包含多個服務，服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在於操作系統進程中。各個服務之間通過網絡調用。
架構特點
- 系統集成–站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構、梳理成規整、可治理的系統間星系結構，這一步往往需要引入一些產品，比如ESB、技術規範、服務管理規範等。解決的核心問題–有序
- 系統的服務化–站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生。目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用。解決的核心問題–複用
- 業務的服務化–站在企業的角度，把企業職能抽象成可複用、可組裝的服務。把原先職能化的企業架構轉變爲服務化的企業架構，進一步提升企業的對外服務能力。“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”，這裏則是以業務驅動把一個業務單元封裝成一項服務，解決的核心問題–高效
微服務架構
微服務架構–其實和SOA架構類似，微服務是在SOA上做的昇華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分爲多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。
微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想
架構特點
- 通過服務實現組件化–開發者不再需要協調其他服務部署對本服務的影響。
- 按業務能力來劃分服務和開發團隊–開發者可以自由選擇開發技術，提供API服務。
- 去中心化
–每個微服務有自己私有的數據庫持久化業務數據
–每個微服務只能訪問自己的數據庫，而不能訪問其他服務的數據庫
–某些業務場景下，需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其他微服務的數據庫，而是通過對於微服務進行操作。
–數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的數據庫技術（SQL、NoSQL等）。在複雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。 - ▪ 基礎設施自動化（devops、自動化部署）
–Java EE部署架構，通過展現層打包WARS，業務層劃分到JARs最後部署爲EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成爲一個一個的單個服務，應用Docker技術，不依賴任何服務器的數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯繫，經常是基於HTTP資源API，這些非服務基於業務能力構建，能實現集中化管理
主要區別
SOA–參考鏈接
