微服務架構體系
架構的演進
-
（1）單體應用：在第一階段的單體應用很好理解。
-
（2）垂直應用：接著隨著業務量增大, 將應用拆成互不相干的幾個應用，Web框架(MVC)是關鍵。
-
這一步，前後端分離、使用快取、資料庫和應用服務分離都會做,但服務間是獨立的無法呼叫，且可能存在重複程式碼。
-
（3）分散式應用：垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務。這時用於提高業務複用及整合的分散式服務框架(RPC)是關鍵。
-
叢集、讀寫分離、反向代理、加速、分散式資料庫、nosql、服務拆分都會處理、訊息。
-
實現了服務呼叫，程式碼複用
-
（4）彈性流動計算：服務越來越多，容量評估，資源的使用等問題逐漸顯現，需要排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。此時，用於提高機器利用率的資源排程和治理中心(SOA面向服務架構)是關鍵。
-
這時候要有一個註冊中心，呼叫關係不需要自行維護了。
-
Dubbo 就是SOA的概念了，更關注RPC和服務治理。
-
（5）微服務：最後是通俗含義的微服務，使用 SpringCloud編碼，使用Docker、K8S等，解決微服務軟運維問題。
-
微服務本身也算是面向服務架構（SOA），它是SOA發展道路上的優化選擇，關注的是服務拆分力度，即：如何將服務合理的拆的更細、更小
-
微服務需要關注點又更多，監控、日誌、安全、排程、彈性容錯等
微服務和SOA
-
微服務相比於SOA更加精細，微服務更多的以獨立的程序的方式存在，互相之間並無影響，不再需要協調其它服務部署對本服務的影響；
-
微服務提供的介面方式更加通用化，如HTTP RESTful，各種終端都可以呼叫，無關語言、平臺，所以技術可以更隨意，只需要提供API
-
微服務更傾向於分散式去中心化的部署方式，資料的去中心化，也可以使用更不同的資料庫技術；
-
微服務運維使用docker,k8s 可以自動化部署，集中管理
Spring Cloud 和 Dubbo
傳輸方式：
-
Dubbo底層用Netty這樣的NIO框架，基於TCP協議傳輸的，配合以Hession序列化完成RPC通訊;
-
SpringCloud基於Http協議+rest介面呼叫遠端過程的通訊，
-
相對來說，Http會有更大的報文，佔的頻寬也更多。但是REST相比RPC更靈活，服務提供方和呼叫方的依賴只依靠一紙契約，不存在程式碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更為合適，至於注重通訊速度還是方便靈活性，具體情況具體考慮。
模組區別：
Dubbo 主要分為服務註冊中心，服務提供者，服務消費者，還有管控中心；
SpringCloud則是一個完整的分散式一站式框架，服務註冊中心，服務提供者，服務消費者，管控臺，斷路器，分散式配置服務，訊息匯流排，以及服務追蹤等；
架構SpringCloud
流程：
-
請求統一通過 API 閘道器（Zuul）來訪問內部服務。
-
閘道器接收到請求後，從註冊中心（Eureka）獲取可用服務。
-
由 Ribbon 進行均衡負載後，分發到後端具體例項。
-
微服務之間通過 Feign 進行通訊處理業務。
-
Hystrix 負責處理服務超時熔斷。
-
Turbine 監控服務間的呼叫和熔斷相關指標。