本文轉(zhuǎn)載自微信公眾號(hào)「趙化冰」，轉(zhuǎn)載本文請(qǐng)聯(lián)系趙化冰公眾號(hào)。

[[328847]]

目錄

• Istio 服務(wù)模型
• Pilot 服務(wù)模型源碼分析
• 第三方服務(wù)注冊(cè)表集成
  • Consul 集成
  • 其他服務(wù)注冊(cè)表的集成
• 小結(jié)
• 參考文檔

作為云原生服務(wù)網(wǎng)格領(lǐng)域的熱門(mén)開(kāi)源項(xiàng)目，Istio 可以為微服務(wù)提供無(wú)侵入的流量管理、安全通信、服務(wù)可見(jiàn)性等服務(wù)治理能力。目前越來(lái)越多的微服務(wù)項(xiàng)目開(kāi)始考慮將自己的微服務(wù)基礎(chǔ)設(shè)施向 Istio 進(jìn)行遷移。

Istio 對(duì) Kubernetes 具有較強(qiáng)的依賴性，其服務(wù)發(fā)現(xiàn)就是基于 Kubernetes 實(shí)現(xiàn)的。大量現(xiàn)存的微服務(wù)項(xiàng)目要么還沒(méi)有遷移到 Kubernetes 上;要么雖然采用了 Kubernetes 來(lái)進(jìn)行部署和管理，但還是使用了 Consul，Eureka 等其他服務(wù)注冊(cè)解決方案或者自建的服務(wù)注冊(cè)中心。

在這種情況下，我們?nèi)绾文軌蛞宰钚〉拇鷥r(jià)快速地將現(xiàn)有微服務(wù)項(xiàng)目和 Istio 進(jìn)行集成，以享受 Istio 提供的各種服務(wù)治理能力呢?本文將分析 Istio 服務(wù)注冊(cè)機(jī)制的原理，并提出幾種 Istio 與第三方服務(wù)注冊(cè)中心集成的可行方案，以供讀者參考。

Istio 服務(wù)模型

我們先來(lái)看一下 Istio 內(nèi)部的服務(wù)模型。在 Istio 控制面中，Pilot 組件負(fù)責(zé)管理服務(wù)網(wǎng)格內(nèi)部的服務(wù)和流量策略。Pilot 將服務(wù)信息和路由策略轉(zhuǎn)換為 xDS 接口的標(biāo)準(zhǔn)數(shù)據(jù)結(jié)構(gòu)，下發(fā)到數(shù)據(jù)面的 Envoy。

Pilot 自身并不負(fù)責(zé)網(wǎng)格中的服務(wù)注冊(cè)，而是通過(guò)集成其他服務(wù)注冊(cè)表來(lái)獲取網(wǎng)格中管理的服務(wù)。除此以外，Istio 還支持通過(guò) API 向網(wǎng)格中添加注冊(cè)表之外的獨(dú)立服務(wù)。

圖1 Istio 服務(wù)模型數(shù)據(jù)來(lái)源

從上圖中可以得知， Pilot 中管理的服務(wù)數(shù)據(jù)有兩處數(shù)據(jù)來(lái)源：

• Service Registry：來(lái)源于各個(gè)服務(wù)注冊(cè)表，例如 Kubernetes 中的 Service 和 Consul Catalog 中注冊(cè)的服務(wù)。Istio 通過(guò)特定的適配器連接這些服務(wù)注冊(cè)表，由適配器將服務(wù)注冊(cè)表中的私有服務(wù)模型轉(zhuǎn)換為 Istio 內(nèi)部支持的標(biāo)準(zhǔn)服務(wù)模型。
• Config Storage：來(lái)源于各種配置數(shù)據(jù)源中的獨(dú)立服務(wù)，通過(guò) Istio 定義的 ServiceEntry 和 WorkloadEntry 資源類型加入到 Pilot 的內(nèi)部服務(wù)模型中。

Pilot 服務(wù)模型源碼分析

Pilot 中涉及到服務(wù)模型的代碼模塊如下圖所示：

圖2 Pilot 服務(wù)模型相關(guān)的代碼結(jié)構(gòu)

Pilot 的入口函數(shù)是 pilot/cmd/pilot-discovery/main.go 中的 main 方法。main方法中創(chuàng)建了 Discovery Server，Discovery Server 中和服務(wù)模型相關(guān)的主要包含三部分內(nèi)容：

• Config Controller：用于管理各種配置數(shù)據(jù)，包括用戶創(chuàng)建的流量管理規(guī)則和策略。配置數(shù)據(jù)中有兩個(gè) API 對(duì)象和服務(wù)模型相關(guān)，ServiceEntry 和 WorkloadEntry。Istio 目前支持三種類型的 Config Controller：
  • Kubernetes：使用 Kubernetes 來(lái)作為配置數(shù)據(jù)的存儲(chǔ)，該方式的直接依附于 Kubernetes 強(qiáng)大的 CRD 機(jī)制來(lái)存儲(chǔ)配置數(shù)據(jù)，簡(jiǎn)單方便，是 Istio 缺省使用的配置存儲(chǔ)方案。
  • Memory：一個(gè)在內(nèi)存中的 Config Controller 實(shí)現(xiàn)，可以監(jiān)控一個(gè)文件目錄，加載該目錄中的 yaml 文件中定義的 Istio API 配置對(duì)象，該方式主要用于測(cè)試。
  • MCP：通過(guò) MCP(Mesh Configuration Protocol) 協(xié)議，可以接入一個(gè)到多個(gè) MCP Server。Pilot 從 MCP server 中獲取網(wǎng)格的配置數(shù)據(jù)，包括 ServiceEntry 和 WorkloadEntry 定義的服務(wù)數(shù)據(jù)，以及 VirtualService，DestinationRule 等路由規(guī)則等其他配置。Istio 中有一個(gè) Galley 組件，該組件實(shí)現(xiàn)為一個(gè) MCP Server，從 Kubernetes API Server 中獲取配置數(shù)據(jù)，然后通過(guò) MCP 協(xié)議提供給 Pilot。
• Service Controller：負(fù)責(zé)接入各種 Service Registry，從 Service Registry 同步需要在網(wǎng)格中進(jìn)行管理的服務(wù)，目前Istio支持的Service Registry包括：
  • Kubernetes：對(duì)接 Kubernetes Registry，可以將 Kubernetes 的 Service 和 Endpoint 采集到 Istio 中。
  • Consul：對(duì)接Consul Catalog，將注冊(cè)到 Consul 中的服務(wù)數(shù)據(jù)采集到 Istio 中。
  • External Service Discovery：該 Service Registry 比較特殊，后端并未對(duì)接到一個(gè)服務(wù)注冊(cè)表，而是會(huì)監(jiān)聽(tīng) Config Controller 的配置變化消息，從 Config Controller 中獲取 ServiceEntry 和 WorkloadEntry 資源，然后以 Service Registry 的形式提供給 Service Controller。

Discovery Service：將服務(wù)模型和控制面配置轉(zhuǎn)換為數(shù)據(jù)面標(biāo)準(zhǔn)數(shù)據(jù)格式，通過(guò) xDS 接口下發(fā)給數(shù)據(jù)面的代理。主要包含下述邏輯：

• 啟動(dòng)GRPC Server并接收來(lái)自Envoy端的連接請(qǐng)求。
• 接收Envoy端的xDS請(qǐng)求，從Config Controller和Service Controller中獲取配置和服務(wù)信息，生成響應(yīng)消息發(fā)送給Envoy。
• 監(jiān)聽(tīng)來(lái)自Config Controller的配置變化消息和來(lái)自Service Controller的服務(wù)變化消息，并將配置和服務(wù)變化內(nèi)容通過(guò)xDS接口推送到Envoy。

第三方服務(wù)注冊(cè)表集成

Consul 集成

鑒于和 Kubernetes 的緊密關(guān)系，Istio 在最初只重點(diǎn)關(guān)注了 Kubernetes 服務(wù)注冊(cè)的集成。雖然在 Istio 最初的版本中也有 Consul 和 Eureka 的適配代碼，但這些代碼基本只是處于原型驗(yàn)證的節(jié)點(diǎn)，存在較多的故障和性能問(wèn)題。

由于在項(xiàng)目中采用了 Consul 作為自研服務(wù)注冊(cè)的后端存儲(chǔ)，我們?cè)诤?Istio 進(jìn)行集成時(shí)對(duì) Consul 的適配進(jìn)行了大量測(cè)試和研究，并解決了一些功能和性能效率方面的問(wèn)題。這些 Consul 適配的問(wèn)題解決后已經(jīng)合入了 Istio 版本中，參見(jiàn)這些 PR：

• Use watching instead of polling to get update from Consul catalog #17881
• Fix: Consul high CPU usage (#15509) #15510
• Avoid unnecessary service change events(#11971) #12148
• Use ServiceMeta to convey the protocol and other service properties #9713

這些問(wèn)題處理后，Consul 注冊(cè)表的集成已經(jīng)基本可用。要將 Consul 接入到 Pilot 中， 只需要在 pilot-discovery 的啟動(dòng)命令中通過(guò)這兩個(gè)參數(shù)指定 registry 類型和 consul 的連接地址即可： --registries Consul --consulserverURL http://$consul-ip:$port。

其他服務(wù)注冊(cè)表的集成

雖然在 1.0 中還有 Eureka 的適配代碼框架，但在 Istio 后面的版本完全刪除了 Eureka 適配的相關(guān)代碼。除了 Kubernetes 和 Consul 之外，原生 Istio 代碼不支持其他服務(wù)注冊(cè)表。但我們可以采用以下三種方式將其集成到 Istio 的方式。

圖3 集成第三方服務(wù)注冊(cè)表的三種方式

上圖中分別用紅、綠、三種顏色標(biāo)識(shí)了這三種不同的集成方式。

自定義 Service Registry 適配器

如圖3中紅色箭頭所示，我們可以編寫(xiě)一個(gè)自定義的適配器來(lái)集成第三方服務(wù)注冊(cè)表。該自定義適配器從第三方服務(wù)注冊(cè)表中獲取服務(wù)和服務(wù)實(shí)例，轉(zhuǎn)換為 Pilot 內(nèi)部的標(biāo)準(zhǔn)模型，集成到 Service Controller 中。自定義適配器需要實(shí)現(xiàn) serviceregistry.Instance 接口。該方式的原理和 Consul Service Registry 的適配是類似的，可以參照 Consul Service Registry 的適配代碼進(jìn)行編寫(xiě)。

實(shí)施該方案需要熟悉 Pilot 內(nèi)部服務(wù)模型和 Service Registry 適配相關(guān) Istio 源碼，并且需要將自定義適配器代碼和 Pilot 代碼一起編譯生成定制的 Pilotd 二進(jìn)制執(zhí)行文件。該方案的問(wèn)題是和 Istio 代碼耦合較強(qiáng)，后續(xù) Istio 版本升級(jí)時(shí)可能需要修改適配器代碼并重新編譯。

自定義 MCP Server

這種集成方式的業(yè)務(wù)流程參見(jiàn)圖3中的藍(lán)色箭頭。該方案需要編寫(xiě)自定義的 MCP Server 從第三方注冊(cè)表中獲取服務(wù)和服務(wù)實(shí)例，然后轉(zhuǎn)換為 ServiceEntry 和 WorkloadEntry 資源，通過(guò) MCP 協(xié)議提供給 Pilot 中的 MCP config Controller。

采用這種方式，需要在 Global Mesh Options 中通過(guò) configSources 參數(shù)設(shè)置自定義 MCP Server 的地址。需要注意的是，目前1.6的 Config Controller 實(shí)現(xiàn)不允許同時(shí)使用不同類型的Config controller。這意味著如果采用自定義 MCP Server 來(lái)獲取第三方注冊(cè)表中的服務(wù)數(shù)據(jù)，也必須同時(shí)采用 Galley 來(lái)獲取其他控制面的配置。

configSources: 
  - address:istio-galley.istio-system.svc:9901 
  - address:${your-coustom-mcp-server}:9901 

而從1.5版本開(kāi)始，Galley 的功能以及被合并到 Istiod 中，并且缺省被禁用。從 Isito 控制面簡(jiǎn)化的趨勢(shì)來(lái)看，Galley 后續(xù)很可能會(huì)被逐漸放棄，其自身功能的穩(wěn)定性也值得懷疑。因此我不建議在產(chǎn)品中啟用 Galley。

除此以外，根據(jù) Istio 社區(qū)中的這個(gè) MCP over XDS proposal，社區(qū)正在討論使用 XDSv3/UDPA 代替目前的 MCP 協(xié)議來(lái)傳輸配置數(shù)據(jù)，因此 MCP server 和 Pilot 的通信機(jī)制在 1.7 版本中很可能變化。

向 API Server 寫(xiě)入 ServiceEntry 和 WorkloadEntry

該集成方式的業(yè)務(wù)流程如圖3中綠色箭頭所示。我們只需要編寫(xiě)一個(gè)獨(dú)立的服務(wù)，該服務(wù)從第三方法服務(wù)注冊(cè)表中獲取服務(wù)和服務(wù)實(shí)例數(shù)據(jù)，然后轉(zhuǎn)換為 Istio 的 ServiceEntry 和 WorkloadEntry 資源，通過(guò) K8s API Server 的接口寫(xiě)入到 API Server 中。Pilot 中自帶的 Kube Config Controller 會(huì)監(jiān)聽(tīng) K8s API Server 中和 Istio 相關(guān)的資源對(duì)象的變化，并將 ServiceEntry 和 WorkloadEntry 轉(zhuǎn)換為 Piolt 的內(nèi)部服務(wù)模型。

小結(jié)

本文分析了 Istio 和第三方服務(wù)注冊(cè)表集成的幾種可能的方式，包括自定義的 Service Registry 適配代碼，自定義 MCP Server 和采用一個(gè)獨(dú)立服務(wù)向 API Server 寫(xiě)入 ServiceEntry 和 WorkloadEntry 三種方法。有需要的讀者可以根據(jù)項(xiàng)目的實(shí)際情況選擇采用哪一種方法。由于第一種和第二種方法目前都存在一些問(wèn)題，個(gè)人建議先采用第三種方式，待 Istio 對(duì) Galley 和 MCP 的改造徹底完成后再考慮向第二種方式遷移。

備注：本文的分析和建議都是基于使用 Istio 1.6 的前提下。隨著 Istio 版本的不斷發(fā)展，其服務(wù)模型和注冊(cè)相關(guān)機(jī)制可能發(fā)生變化，和第三方服務(wù)注冊(cè)表的集成方式也可能變化。

參考文檔

• Istio 服務(wù)注冊(cè)插件機(jī)制
• Istio Pilot代碼深度解析
• Istio and managing microservices
• Istio 1.6 Change Notes
• The recommended way to integrate a third-party service registry with Istio