基於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輪詢）
這種是目前市面上 開源註冊中心的核心體系 ， 這一套開發人員介入較多，運維人員介入較少， 同程藝龍老版DSF就類似這樣的結構
2.3 模式三: 獨立進程代理
再回顧模式二、 很明顯，我們需要針對不同技術語言開發SDk，而且sdk是被髮散部署在各應用上(實則脫離管控、碎片化)。
在技術、業務快速迭代、大規模部署實例的現實面前，模式二：[侵入式太強、業務方升級sdk沒動力、sdk版本碎片化嚴重、sdk帶包袱演進] 都極其費勁心力。
模型三的核心是將 服務註冊、發現功能從原應用中剝離，以獨立進程部署
- 獨立進程接管 服務治理相關，還可以接手更細粒度的流量調度、負載均衡+鑑權
- 獨立進程在物理層面與應用分離 (有的是獨立進程部署在主機，由主機上應用共享；有的是一對一部署在應用側)
![]()
模式三因爲對應用更加透明，獨立進程的部署可能需要 運維人員更多精力, 當然如果是容器/k8s部署獨立進程，可以規避很多環境、配置的瑣碎差異。
3. Service Mesh
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，最好是結合k8s, 使用Init容器做一些劫持配置(修改iptables)
4.2 XDs
基於 xDS 協議提供了標準的控制面規範，並以此向數據面傳遞服務信息和治理規則。
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協議是 全量傳輸 單鏈接拿單資源， 現在主流的還是ADS全量傳輸 聚合gRPC Stream。
下面我們挨個分析一下 設計者爲什麼要延伸出兩個角度 ？
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方案的演變過程，
相比原中文官網垂直灌輸式的輸出，本文強調以流暢的思路來清楚表達演變過程，知其然更知其所以然。