深度解读服务治理 ServiceMesh、xDS
最近在同程藝龍蹲坑，聊一聊微服務治理的核心難點、歷史演進、最新實現。
??以上內容屬自我思考，如理解有偏差、理解不透徹、現狀梳理不清楚的請大家多指教。
大綱
微服務治理的核心難點
方案演進的法寶：代理模式
2.1 集中式代理
2.2 客戶端嵌入Sdk代理
2.3 主機獨立進程
Service Mesh是模式三
3.1 目前現狀 & 建議取舍
istio是一種開源的Service Mesh實現
4.1 關鍵能力 & 平臺支持
4.2 XDS協議
- ?4.2.1 標準xDS協議
- ?4.2.2 設計者為什么引入ADS角度？
- ?4.2.3 設計者為什么引入Increment xDS角度？
4.3 ?基于同程藝龍服務治理現狀的一點看法
1.微服務治理的難點
在服務很少的情況下，直觀的講：A---> B， A如何知道B服務的實例？A是不是要使用某種負載均衡策略去請求B？
服務治理技術的演進，根源就在于此。
現代分布式體系，服務越來越多、服務的實例數也越來越多、互相調用犬牙交錯、 服務環境多且切換頻繁。技術上提出代理模型來統一管理服務注冊/發現、負載均衡。
2.演進的法寶：代理
截止目前，從宏觀上講，演進出三種代理模型，并且并不強調哪種是最佳，適合的才是最好的。
2.1 ?模式一：集中式代理
服務數在個位數、 服務實例可枚舉的中小體系， 可以采用這種集中代理模型，一般選用nginx負載均衡。
因為直觀、簡單， 由開發人員或者框架組在代理上手動配置。
容器、K8s內置了動態服務注冊、服務發現功能，倒是不需要手動去配置ip和端口
2.2 ?模式二：客戶端嵌入sdk代理
從代理功能， 強化分離出獨立的服務注冊模塊
直接變化是：A直接請求B， 但是A預先（隨時感知到）B
這種就比模型一智能一點：服務B自行注冊、服務A自行發現， 這個“自行”都是通過sdk實現
核心的服務注冊、發現在邏輯上與應用分離
很明顯，獨立的Service Registry現在除了關注自己 的核心功能外，還要負責接受心跳、維護實例狀態， 通知調用方服務實例變更（可能通過推送或sdk輪詢）
這種是目前市面上 開源注冊中心的核心體系 ， 這一套開發人員介入較多，運維人員介入較少。
2.3 模式三: 獨立進程代理
再回顧模式二、 很明顯，我們需要針對不同技術語言開發SDk，而且sdk是被發散部署在各應用上(實則脫離管控、碎片化)。
在技術、業務快速迭代、大規模部署實例的現實面前，模式二：[侵入式太強、業務方升級sdk沒動力、sdk版本碎片化嚴重、sdk帶包袱演進] 都極其費勁心力。
模型三的核心是將 服務注冊、發現功能從原應用中剝離，以獨立進程部署
獨立進程接管服務治理，還可以接手更細粒度的流量調度、負載均衡+鑒權
獨立進程在物理層面與應用分離 (有的是獨立進程部署在主機，由主機上應用共享；有的是一對一部署在應用側)
模式三因為對應用更加透明，獨立進程的部署可能需要 運維人員更多精力, 當然如果是容器/k8s部署獨立進程，可以規避很多環境、配置的瑣碎差異。
3. ?ServiceMesh
Service Mesh 基于模式三，它的職責是在由云原生應用組成服務的復雜拓撲結構下進行可靠的請求傳送。
但比模式三更加抽象和純粹。
將模式三的Service Registry抽象為控制面， 可以對接多種服務注冊Provider（k8s、Consul等）
這個與模式二、三 顯式[服務注冊--服務發現]還不一樣，從[服務發現]升級為[請求分發]， Service Mesh不做[服務注冊]的功能，由集群內生機制將服務實例注冊到控制面
強調在“基礎設施層”處理服務通信。
它不是"服務"的網格, 而是“代理”的網格
數據層截獲不同服務之間的調用并對其進行“處理”；控制層協調代理的行為，并為運維人員提供 API，用來操控和觀測整個網絡.
優勢
服務治理和應用邏輯解耦
利用控制面API與服務注冊中心解耦
通過將服務治理能力下沉到 基礎設施，支持了異構系統的統一治理
劣勢
因在基礎設施層劫持流量，需要高級運維和開發通力配合
網絡拓撲更加復雜，監測 定位 排障 變得更加困難
從調用鏈路看，服務網格是侵入式的，有毫秒級別的延遲
3.1 ?現狀& 選型
服務不會頻繁變更、服務實例不多的中小項目可以采用 經典的 集中式代理模式，穩定直觀。
強調服務集成的中型項目可以采用 客戶端嵌入sdk 服務注冊、發現；
強調流量調度的中大項目可以采用 Service Mesh 模式。
作為一個企業，如果你的微服務應用已經具有了非常完備的服務治理能力，那么你不一定非得引入Service Mesh。但是假設你的系統并不具有完善的治理功能，或者系統架構中的痛點正好可以被 Service Mesh 所解決，那么使用 Service Mesh 就是你的最佳選擇。
4. Istio是Service mesh的實現
4.1 Istio的能力
為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡。
通過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制。
提供完善的可觀察性方面的能力，包括對所有網格控制下的流量進行自動化度量、日志記錄和追蹤。
提供身份驗證和授權策略，在集群中實現安全的服務間通信。
支持的平臺：
Kubernetes
Consul
GCP
這里面穿插幾個已有答案的疑問？
Istio 中是如何做 sidecar 注入的？[1]
Sidecar proxy 是如何做透明流量劫持的？[2]
總結起來：istio注入sidecar，最好是結合k8s, 使用Init容器做一些劫持配置(修改iptables)
4.2? xDS
基于 xDS[3] 協議提供了標準的控制面規范，并以此向數據面傳遞服務信息和治理規則。
xDS是由Envoy貢獻給istio，現在已經作為sidecar的標準協議。
v1 xDS API. ?傳統的REST-JSON API， 現在已經是ProtoBufffer和 REST/gRPC api
v2 xDS API. 21年初停用
xDS 是一組發現服務的總稱，包含LDS，RDS，CDS，EDS以及SDS。
Envoy 通過xDS API 可以動態獲取Listener(監聽器)，Route(路由)，Cluster(集群/服務)，Endpoint(集群成員/服務實例)以及Secret(秘鑰)配置。
xDS協議是基于gRPC實現的傳輸協議，即Envoy通過gRPC streaming訂閱Pilot的資源配置。
Pilot借助ADS對API更新推送排序的能力，按照CDS-EDS-LDS-RDS 的順序串行分發配置。
利用XDS協議，Envoy可以實現配置的完全動態化，配置實時更新而無需重啟Envoy或者影響業務，此外，利用其L3/L4/L7 Filter機制，Envoy可以完全無侵入的擴展各種強大的功能。利用其內置的Tracing機制和Stats模塊，可以很方便的實現對流量的跟蹤以及監控，保證Envoy中流量的可觀察性。
4.2.1 標準xDS流程
這里暫時一帶而過，因為請求/響應結構體也很簡單， 但是后面我們聊到[增量xDS] 會回過頭來看。
xDS協議分析
在實際使用和性能考量中：設計者延伸出兩種設計角度：
| 維護資源的方式 | 全量傳輸 | 增量傳輸 | 性能 |
| 資源下發的方式 | 單鏈獨立資源 | 單鏈 多資源聚合 | 帶來了強一致性的能力 |
這樣就對應4種xDS效果：
State of the World（Basic xDS）：全量傳輸 獨立gRPC stream；
Incremental xDS：增量傳輸 獨立gRPC stream；
Aggregated Discovery Service（ADS）：全量傳輸 聚合gRPC stream；
Incremental ADS：增量傳輸 聚合gRPC stream （暫未實現）；
早期的xDS協議是 全量傳輸 單鏈接 獨立資源， 現在主流的還是全量傳輸 聚合gRPC Stream (ADS)。
下面我們分析一下 設計者為什么要延伸出兩個角度 ？
4.2.2 角度一：ADS （從規避流量損失的角度）
為什么設計者要延伸出這個聚合維度？或者說變更到這個主流方案？
因為有現實需要！
由于Envoy xDS采用最終一致性，部分流量可能在更新時被丟棄。
使用ADS可以解決[無法忍受數據丟棄的場景],
ADS為什么可以做到？
ADS通過一個連接（gRPC同一stream）申請多種資源/接受多種資源。
能夠保證請求一定落在同一Pilot上，解決多個管理服務器配置不一致的問題。
通過順序的配置分發，輕松解決資源更新順序的問題。
按照這個方式CDS-EDS-LDS-RDS下發，由Polit控制，規避流量丟失的問題，這就是ADS設計的由來。
4.2.3 角度二：增量xDS ?（從性能的角度）
[當配置發生變化時，僅下發和更新發生變化的配置部分]
如何實現？
這個時候就要回頭看標準XDS協議的流程， 增量 xDS 客戶端需要向服務器告知它已擁有的資源從而避免重復發送。
??以上便是本次輸出的全部內容，因為已知原因略去一些隱私內容，??
主要解讀了[服務治理]的演進過程、目前主流的 ServiceMesh的核心特征，以及xDS方案的演變過程，相比原中文官網垂直灌輸式的輸出，本文強調以流暢的思路來清楚表達演變過程，知其然更知其所以然， 如果覺得對你有所幫助，麻煩一鍵三連。
參考資料
[1]
Istio 中是如何做 sidecar 注入的？: [https://www.servicemesher.com/istio-handbook/concepts/sidecar-injection.html
[2]Sidecar proxy 是如何做透明流量劫持的？: https://www.servicemesher.com/istio-handbook/concepts/sidecar-injection.html
[3]xDS: https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/introduction
# 更多精彩
.NET微服務最佳實踐eShopOnContainers
.NET微服務
談到云原生, 繞不開"容器化"
現代云原生設計理念
什么是云原生？
實話實說：只會.NET，會讓我們一直處于鄙視鏈、食物鏈的下游
鵝廠二面，Nginx回憶錄
原創不易 點個在看支持下~
總結
以上是生活随笔為你收集整理的深度解读服务治理 ServiceMesh、xDS的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 幸运从来都只偏爱有准备的人——大龄码农的
- 下一篇： 近业务=困死在一条船上？