微服務架構體系

前段內部聽了下分享 Service Mesh。做一些總結

架構的演進

這種東西有點信雅達，沒什麼絕對標準

單體應用：在第一階段的單體應用很好理解。

垂直應用：接著隨著業務量增大, 將應用拆成互不相干的幾個應用，Web框架(MVC) 是關鍵。

分布式應用：垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務。這時用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。

其實這時已經能算一種「微服務」了，一般會使用SpringBoot

微服務和SOA

微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並無影響，不再需要協調其它服務部署對本服務的影響；

微服務提供的接口方式更加通用化，如HTTP RESTful，各種終端都可以調用，無關語言、平臺，所以技術可以更隨意，只需要提供API

微服務更傾向於分布式去中心化的部署方式，數據的去中心化，也可以使用更不同的資料庫技術；

微服務運維使用docker,k8s 可以自動化部署，集中管理。

SOA微服務服務粒度粒度較粗細粒度拆分部署難度需要重新創建或者部署整個應用每個微服務可以獨立構建部署通信開銷大部分業務模塊在一個應用裡面，通信開銷低更多的遠程調用，增加了通信開銷存儲一般所有服務共享數據存儲每個可以擁有單獨的存儲業務易上手需要了解整個應用的業務，上手較難單服務上手容易，但是服務集群理解比較難(複雜度守恆定律：業務複雜度不會因為遷移到了微服務而降低)通信方式SOA體系結構依賴於消息傳遞（AMQP，MSMQ）和SOAP作為主要的遠程訪問協議，協議偏重量級；使用輕量級協議，如HTTP/REST可擴展性難以擴展使用容器技術很方便擴展微服務和分布式

分布式關注的是服務分開部署，也就是如何將單一服務部署，變為多服務部署（垂直+水平拆分）。
微服務關注的是服務拆分力度，即：一個服務要拆分到多大的維度合適

Spring Cloud 和 Dubbo

說到微服務，兩大框架的討論肯定跑不了

區別

定位

Dubbo 是 SOA 時代的產物，關注點主要在於服務的調用，流量分發、流量監控和熔斷，定位服務治理和** RPC；
Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外由於依託Spirng、Spirng Boot 的優勢之上，兩個框架在開始目標就不一致。
Spirng Cloud 更是一個微服務架構生態。

服務發現

對於服務發現而言，可用性比數據一致性更加重要，AP 勝過 CP，而 Eureka 設計則遵循 AP 原則。

傳輸方式：

Dubbo底層用Netty這樣的NIO框架，基於TCP協議傳輸的，配合以Hession序列化完成RPC通信;

SpringCloud基於Http協議+rest接口調用遠程過程的通信，

相對來說，Http會有更大的報文，佔的帶寬也更多。但是REST相比RPC更靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更為合適，至於注重通信速度還是方便靈活性，具體情況具體考慮。

模塊區別：

Dubbo 主要分為服務註冊中心，服務提供者，服務消費者，還有管控中心；
SpringCloud則是一個完整的分布式一站式框架，服務註冊中心，服務提供者，服務消費者，管控臺，斷路器，分布式配置服務，消息總線，以及服務追蹤等；

架構 SpringCloud

流程：

請求統一通過 API 網關（Zuul）來訪問內部服務。

網關接收到請求後，從註冊中心（Eureka）獲取可用服務。

由 Ribbon 進行均衡負載後，分發到後端具體實例。

微服務之間通過 Feign 進行通信處理業務。

Hystrix 負責處理服務超時熔斷。

Turbine 監控服務間的調用和熔斷相關指標。

架構 Dubbo

Spring Cloud 和 K8s微服務關注什麼

差不多一半關注點是和運維相關的。spring cloud只是一個開發框架，對於應用如何部署和調度是無能為力的，而kubernetes是一個運維平臺，看起來都不夠。
也許用spring cloud+cloud foundry去和kubernetes比較才更加合理，但即使加入了cloud foundry的paas能力，spring cloud仍然是「侵入式」的且語言相關，而kubernetes是「非侵入式」的且語言無關。

區別

spring cloud關注的功能是kubernetes的一個子集。

關注點Spring CloudKubernetes自愈和自動伸縮無kube-controller-manager調度和發布無kube-scheduler+Deployment配置管理Spring Cloud Config/NacosConfigMap服務發現和LBEureka/NacosService+CoreDNS/Istio彈性和容錯Hystrix/Resillience4jIstioAPI網關Zuul/Spring Cloud GatewayIngress/Istio Gateway服務安全Spring Cloud SecurityIstio調用鏈監控Spring Cloud Sleuth+ZipKinIstio+Jaeger/ZipKinMetrics監控actuator+Spring Boot AdminIstio+Prometheus日誌收集Spring Cloud Sleuth+ELKfluentd/Istio

兩邊的解決方案都是比較完整的。
kubernetes，在Istio還沒出來以前，只能提供最基礎的服務註冊、服務發現能力（service只是一個4層的轉發代理），istio出來以後，具有了相對完整的微服務能力。
spring cloud，除了發布、調度、自愈這些運維平臺的功能，其他的功能也支持的比較全面。
相對而言，雲廠商會更喜歡kubernetes的方案，原因就是：非侵入。平臺能力與應用層的解耦，使得雲廠商可以非常方便的升級、維護基礎設施而不需要去關心應用的情況。

Service Mesh介紹

又譯作「服務網格」，作為服務間通信的基礎設施層。
可以將它比作是應用程式或微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。
對於編寫應用程式來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關係服務間的那些原來是通過應用程式或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。

Isito

目前Service Mesh具體落地實現的一種，呼聲最高。

功能列表Spring CloudIsito服務註冊與發現支持，基於Eureka，consul等組件，提供server，和Client管理支持，基於XDS接口獲取服務信息，並依賴「虛擬服務路由表」實現服務發現鏈路監控支持，基於Zikpin或者Pinpoint或者Skywalking實現支持，基於sideCar代理模型，記錄網絡請求信息實現API網關支持，基於zuul或者spring-cloud-gateway實現支持，基於Ingress gateway以及egress實現熔斷器支持，基於Hystrix實現支持，基於聲明配置文件，最終轉化成路由規則實現服務路由支持，基於網關層實現路由轉發支持，基於iptables規則實現安全策略支持，基於spring-security組件實現，包括認證，鑑權等，支持通信加密支持，基於RBAC的權限模型，依賴Kubernetes實現，同時支持通信加密配置中心支持，springcloud-config組件實現不支持性能監控支持，基於Spring cloud提供的監控組件收集數據，對接第三方的監控數據存儲支持，基於SideCar代理，記錄服務調用性能數據，並通過metrics adapter，導入第三方數據監控工具日誌收集支持，提供client，對接第三方日誌系統，例如ELK支持，基於SideCar代理，記錄日誌信息，並通過log adapter，導入第三方日誌系統工具客戶端集成支持，提供消息，總線，部署管道，數據處理等多種工具客戶端SDK不支持分布式事務支持，支持不同的分布式事務模式：JTA，TCC，SAGA等，並且提供實現的SDK框架不支持其他…………

從上面表格中可以看到，如果從功能層面考慮，Spring Cloud與Service Mesh在服務治理場景下，有相當大量的重疊功能，從這個層面而言，為Spring Cloud向Service Mesh遷移提供了一種潛在的可能性。

服務網格

服務網格從總體架構上來講比較簡單，不過是一堆緊挨著各項服務的用戶代理，外加一組任務管理流程組成。

更進一步地說，服務網格是一個專用的基礎設施層，旨在「在微服務架構中實現可靠、快速和安全的服務間調用」。它不是一個「服務」的網格，而是一個「代理」的網格，服務可以插入這個代理，從而使網絡抽象化。

在典型的服務網格中，這些代理作為一個 sidecar（邊車）被注入到每個服務部署中。服務不直接通過網絡調用服務，而是調用它們本地的 sidecar 代理，而 sidecar 代理又代表服務管理請求，從而封裝了服務間通信的複雜性。

相互連接的 sidecar 代理集實現了所謂的數據平面，這與用於配置代理和收集指標的服務網格組件（控制平面）形成對比。
總而言之，Service Mesh 的基礎設施層主要分為兩部分：控制平面與數據平面。當前流行的兩款開源服務網格 Istio 和 Linkerd 實際上都是這種構造。

控制平面 數據平面

控制平面的特點：

數據平面的特點：

服務網格帶來的變化

第一，微服務治理與業務邏輯的解耦。服務網格把 SDK 中的大部分能力從應用中剝離出來，拆解為獨立進程，以 sidecar 的模式進行部署。

第二，異構系統的統一治理。不同語言、不同框架的應用和服務，能夠統一管控

技術優勢

此外，服務網格相對於傳統微服務框架，還擁有三大技術優勢：

服務網格被稱為第二代「微服務架構」。但服務網格也有它的局限性。

複雜度。服務網格將 sidecar 代理和其它組件引入到已經很複雜的分布式環境中，會極大地增加整體鏈路和操作運維的複雜性。

運維人員能力。

延遲。從鏈路層面來講，服務網格是一種侵入性的、複雜的技術，可以為系統調用增加顯著的延遲。

適配。服務網格的侵入性要適應高度自治的平臺並遵守平臺的規則。

小結

從架構演進路徑來看，從最早期的巨石單體（Monolithic）到分布式（Distributed），再到微服務（Microservices）、容器化（Containerization）、容器編排（Container Orchestration），最後到服務網格（Service Mesh）、無伺服器（Serverless）。

K8S 正爆炸式發展，已經成為企業綠地應用的容器編排的首選。如果說 Kubernetes 已經徹底贏得了市場，並且基於 Kubernetes 的應用程式的規模和複雜性持續增加，那麼就會有一個臨界點，而服務網格則將是有效管理這些應用程式所必需的。

隨著服務網格技術的持續發展，其實現產品（如 Istio）的架構與功能的不斷優化，服務網格將完全取代傳統微服務架構，成為大小企業微服務化和上雲改造的首選架構。

參考

微服務架構發展和趨勢
SpringCloud和Dubbo
SpingBoot+K8s搭建環境
[serviceMesh服務網格]