Istio調(diào)用鏈埋點原理剖析—是否真的“零修改”分享實錄（上）

本文整理自華為Cloud BU技術(shù)專家在K8S技術(shù)社上

關(guān)于Istio調(diào)用鏈的分享。

前言

大家好，我是idouba，來自華為Cloud BU，當(dāng)前在做Istio服務(wù)網(wǎng)格在華為云容器服務(wù)的產(chǎn)品化工作。今天跟大家分享的主題是Istio調(diào)用鏈相關(guān)內(nèi)容。通過剖析Istio的架構(gòu)機制與Istio中調(diào)用鏈的工作原理來解答一個大家經(jīng)常問道的一個問題：Istio是否像其官方文檔中宣傳的一樣，對業(yè)務(wù)代碼完全的無侵入，無需用做任何修改就可以完成所有的治理能力，包括調(diào)用鏈的埋點？

關(guān)于這個問題，可以提前透漏下，答案是讓人有點沮喪的，得改點。在Isito中你不用在自己的代碼里使用各種埋點的SDK來做埋點的邏輯，但是必須要有適當(dāng)?shù)呐浜系男薷摹?/p>

為什么本來無侵入的Service Mesh形態(tài)的技術(shù)卻要求我們開發(fā)者修改些代碼，到底要做哪些修改？Istio中調(diào)用鏈到底是怎么工作的？在下面的內(nèi)容中將逐個回答這些問題。

本次分享的主題包括兩部分: 第一部分作為背景和基礎(chǔ)，介紹Istio的架構(gòu)和機制；第二部分將重點介紹Istio調(diào)用鏈的相關(guān)內(nèi)容，解答前面提出的幾個問題。

Isito的架構(gòu)和機制

Service Mesh

如官方介紹，Istio是一個用于連接、控制、保護和觀測服務(wù)的一個開放平臺。即：智能控制服務(wù)間的流量和API調(diào)用；提供授權(quán)、認(rèn)證和通信加密機制自動保護服務(wù)安全；并使用各種策略來控制調(diào)用者對服務(wù)的訪問；另外可以擴展豐富的調(diào)用鏈、監(jiān)控、日志等手段來對服務(wù)的與性能進行觀測。

Istio是Google繼Kubernetes之后的又一重要項目，提供了Service Mesh方式服務(wù)治理的完整的解決方案。2017年5月發(fā)布第一個版本 0.1， 2018年6月1日發(fā)布了0.8版本，第一個LTS版本，當(dāng)前在使用的1.0版本是今年7.31發(fā)布，對外宣傳可用于生產(chǎn)。最新的1.1版本將2018.11中旬最近發(fā)布(當(dāng)時規(guī)劃實際已延遲，作者注)。

Istio屬于Service Mesh的一種實現(xiàn)。通過一張典型圖來了解下Service Mesh。如圖示深色是Proxy，淺色的是服務(wù)，所有流入流出服務(wù)的都通過Proxy。Service Mesh正是由這一組輕量代理組成，和應(yīng)用程序部署在一起，但是應(yīng)用程序感知不到他的存在。特別對于云原生應(yīng)用，服務(wù)間的應(yīng)用訪問拓?fù)涠急容^復(fù)雜，可以通過Service Mesh來保證服務(wù)間的調(diào)用請求在可靠、安全的傳遞。在實現(xiàn)上一般會有一個統(tǒng)一的控制面，對這些代理有個統(tǒng)一的管理，所有的代理都接入一個控制面。對代理進行生命期管理和統(tǒng)一的治理規(guī)則的配置。

這里是對Service Mesh特點的一個一般性描述，后面結(jié)合Isito的架構(gòu)和機制可以看下在Istio中對應(yīng)的實現(xiàn)。

可以看到Service Mesh最核心的特點是在Proxy中實現(xiàn)治理邏輯，從而做到應(yīng)用程序無感知。其實這個形態(tài)也是經(jīng)過一個演變的過程的：

最早的治理邏輯直接由業(yè)務(wù)代碼開發(fā)人員設(shè)計和實現(xiàn)，對服務(wù)間的訪問進行管理，在代碼里其實也不分治理和業(yè)務(wù)，治理本身就是業(yè)務(wù)的一部分。這種形態(tài)的缺點非常明顯就是業(yè)務(wù)代碼和治理的耦合，同時公共的治理邏輯有大量的重復(fù)。

很容易想到封裝一個公共庫，就是所謂的SDK，使用特定的SDK開發(fā)業(yè)務(wù)，則所有治理能力就內(nèi)置了。Spring Cloud和Netflix都是此類的工具，使用比較廣泛，除了治理能力外，SDK本身是個開發(fā)框架，基于一個語言統(tǒng)一、風(fēng)格統(tǒng)一的開發(fā)框架開發(fā)新的項目非常好用。但這種形態(tài)語言相關(guān)，當(dāng)前Java版本的SDK比較多。另外對于開發(fā)人員有一定的學(xué)習(xí)成本，必須熟悉這個SDK才能基于他開發(fā)。最重要的是推動已經(jīng)在用的成熟的系統(tǒng)使用SDK重寫下也不是個容易的事情。比如我們客戶中就有用C開發(fā)的系統(tǒng)，運行穩(wěn)定，基本不可能重寫。對這類服務(wù)的治理就需要一個服務(wù)外面的治理方式。

于是考慮是否可以繼續(xù)封裝，將治理能力提到進程外面來，作為獨立進程。即Sidecar方式，也就是廣泛關(guān)注的Service Mesh 的。真正可以做到對業(yè)務(wù)代碼和進程0侵入，這對于原來的系統(tǒng)完全不用改造，直接使用Sidecar進行治理。

用一段偽代碼來表示以上形態(tài)的演變：

可以看到隨著封裝越來越加強，從公共庫級別，到進程級別。對業(yè)務(wù)的侵入越來越少，SDK的公共庫從業(yè)務(wù)代碼中解耦，Sidecar方式直接從業(yè)務(wù)進程解耦了。對應(yīng)的治理位置越來越低，即生效的位置更加基礎(chǔ)了。尤其是Service Mesh方式下面訪問通過 Proxy執(zhí)行治理，所以Service Mesh的方式也已被稱為一種應(yīng)用的基礎(chǔ)設(shè)施層，和TCP/IP的協(xié)議棧一樣。TCP/IP負(fù)責(zé)將字節(jié)流可靠地在網(wǎng)絡(luò)節(jié)點間傳遞；而應(yīng)用基礎(chǔ)設(shè)施則保證服務(wù)間的請求在安全、可靠、可被管控的傳遞。這也對應(yīng)了前面Istio作為Service Mesh一種實現(xiàn)的定位。

Istio 關(guān)鍵能力

Istio官方介紹自己的關(guān)鍵能力如上所示，我把它分為兩部分：一部分是功能，另有一部分提供的擴展能力。

功能上包括流量管理、策略執(zhí)行、安全和可觀察性。也正好應(yīng)對了首頁的連接、保護、控制和觀測四大功能。

流量管理：是Istio中最常用的功能。可以通過配置規(guī)則和訪問路由，來控制服務(wù)間的流量和API調(diào)用。從而實現(xiàn)負(fù)載均衡、熔斷、故障注入、重試、重定向等服務(wù)治理功能，并且可以通過配置流量規(guī)則來對將流量切分到不同版本上從而實現(xiàn)灰度發(fā)布的流程。

策略執(zhí)行：指Istio支持支持訪問控制、速率限制、配額管理的能力。這些能力都是通過可動態(tài)插入的策略控制后端實現(xiàn)。

安全：Istio提供的底層的安全通道、管理服務(wù)通信的認(rèn)證、授權(quán)，使得開發(fā)任務(wù)只用關(guān)注業(yè)務(wù)代碼中的安全相關(guān)即可。

可觀察性：較之其他系統(tǒng)和平臺，Istio比較明顯的一個特點是服務(wù)運行的監(jiān)控數(shù)據(jù)都可以動態(tài)獲取和輸出，提供了強大的調(diào)用鏈、監(jiān)控和調(diào)用日志收集輸出的能力。配合可視化工具，運維人員可以方便的看到系統(tǒng)的運行狀況，并發(fā)現(xiàn)問題進而解決問題。我們這次分享的主題調(diào)用鏈也正是Isito可觀察性的一個核心能力。

后面分析可以看到以上四個特性從管理面看，正好對應(yīng)Istio的三個重要組件。

擴展性：主要是指Istio從系統(tǒng)設(shè)計上對運行平臺、交互的相關(guān)系統(tǒng)都盡可能的解耦，可擴展。這里列出的特性：

平臺支持：指Istio可以部署在各種環(huán)境上，支持Kubernetes、Consul等上部署的服務(wù)，在之前版本上還支持注冊到Eureka上的Service，新版本對Eureka的支持被拿掉了；

集成和定制：指的Istio可以動態(tài)的對接各種如訪問控制、配額管理等策略執(zhí)行的后端和日志監(jiān)控等客觀性的后端。支持用戶根據(jù)需要按照模板開發(fā)自己的后端方便的集成進來。

其實這兩個擴展性的能力正好也對應(yīng)了Istio的兩個核心組件Pilot和Mixer，后面Isito架構(gòu)時一起看下。

Istio 總體架構(gòu)

以上是Isito的總體架構(gòu)。上面是數(shù)據(jù)面，下半部分是控制面。

數(shù)據(jù)面Envoy是一個C++寫的輕量代理，可以看到所有流入流出服務(wù)的流量都經(jīng)過Proxy轉(zhuǎn)發(fā)和處理，前面Istio中列出的所有的治理邏輯都是在Envoy上執(zhí)行，正是攔截到服務(wù)訪問間的流量才能進行各種治理；另外可以看到Sidecar都連到了一個統(tǒng)一的控制面。

Istio其實專指控制面的幾個服務(wù)組件：

Pilot：Pilot干兩個事情，一個是配置，就是前面功能介紹的智能路由和流量管理功能都是通過Pilot進行配置，并下發(fā)到Sidecar上去執(zhí)行；另外一個是服務(wù)發(fā)現(xiàn)，可以對接不同的服務(wù)發(fā)現(xiàn)平臺維護服務(wù)名和實例地址的關(guān)系并動態(tài)提供給Sidecar在服務(wù)請求時使用。Pilot的詳細(xì)功能和機制見后面組件介紹。

Mixer：Mixer是Istio中比較特殊，當(dāng)前甚至有點爭議的組件。前面Isito核心功能中介紹的遙測和策略執(zhí)行兩個大特性均是Mixer提供。而Istio官方強調(diào)的集成和定制也是Mixer提供。即可以動態(tài)的配置和開發(fā)策略執(zhí)行與遙測的后端，來實現(xiàn)對應(yīng)的功能。Mixer的詳細(xì)功能和機制見后面組件介紹。

Citadel：主要對應(yīng)Istio核心功能中的安全部分。配合Pilot和Mixer實現(xiàn)秘鑰和證書的管理、管理授權(quán)和審計，保證客戶端和服務(wù)端的安全通信，通過內(nèi)置的身份和憑證提供服務(wù)間的身份驗證，并進而該通基于服務(wù)表示的策略執(zhí)行。

Isito主要組件Pilot

如Istio架構(gòu)中簡介，Pilot實現(xiàn)服務(wù)發(fā)現(xiàn)和配置管理的功能。

作為服務(wù)發(fā)現(xiàn)，Pilot中定義了一個抽象的服務(wù)模型，包括服務(wù)、服務(wù)實例、版本等。并且只定義的服務(wù)發(fā)現(xiàn)的接口，并未實現(xiàn)服務(wù)發(fā)現(xiàn)的功能，而是通過Adapter機制以一種可擴展的方式來集成各種不同的服務(wù)發(fā)現(xiàn)，并轉(zhuǎn)換成Istio通用的抽象模型。 如在Kubernetes中，Pilot中的Kubernetes適配器通過Kube-APIServer服務(wù)器得到Kubernetes中對應(yīng)的資源信息。而對于像Eureka這種服務(wù)注冊表，則是使用一個Eureka的HTTP Client去訪問Eureka的名字服務(wù)的集群，獲取服務(wù)實例的列表。不管哪種方式最終都轉(zhuǎn)換成Pilot的標(biāo)準(zhǔn)服務(wù)發(fā)現(xiàn)定義，進而通過標(biāo)準(zhǔn)接口提供給Sidecar使用。

而配置管理，則是定義并維護各種的流量規(guī)則，來實現(xiàn)負(fù)載均衡、熔斷、故障注入、流量拆分等功能。并轉(zhuǎn)換成Envoy中標(biāo)準(zhǔn)格式推送給Envoy，從而實現(xiàn)治理功能。所有的這些功能用戶均不用修改代碼接口完成。詳細(xì)的配置方式可以參照Istio Traffic Routing中的規(guī)則定義。重點關(guān)注：VirtualService、 DestinationRule、 Gateway等規(guī)則定義。如可以使用流量規(guī)則來配置各種灰度發(fā)布，也可以通過注入一個故障來測試故障場景；可以配置熔斷來進行故障恢復(fù)；并且可以對HTTP請求根據(jù)我們的需要進行重定向、重寫，重試等操作。

Istio主要組件Mixer

Mixer是Isito特有的一個組件。主要做兩個功能Check和Report，分別對應(yīng)Istio官方宣傳的兩個重大特性策略執(zhí)行和遙測功能。邏輯上理解每次服務(wù)間的請求都會通過proxy連接Mixer來進行處理，由Mixer來將請求派發(fā)到對應(yīng)的后端上處理。通過擴展不同的后端來增強Mixer的能力。如可以做訪問控制、配額等這樣的控制，也可以對接不同的監(jiān)控后端來做監(jiān)控數(shù)據(jù)的收集，進而提供網(wǎng)格運行的可觀察性能力。

Mixer通過使用通用插件模型實現(xiàn)的對接不同后端，避免了proxy為了完成不同的功能而去對接各種不同的后端。每個插件都被稱為Adapter。對于每個請求Sidecar會從每一次請求中收集相關(guān)信息，如請求的路徑，時間，源IP，目地服務(wù)，tracing頭，日志等，并請這些屬性上報給Mixer。Mixer和后端服務(wù)之間是通過適配器進行連接的，Mixer將Sidecar上報的內(nèi)容通過適配器發(fā)送給后端服務(wù)?？梢栽诓煌Ｖ箲?yīng)用服務(wù)的情況下動態(tài)切換后臺服務(wù)。

除了可以通過adapter機制接入不同的后端，mixer還支持根據(jù)需要定義收集的metric，和對metric的處理方式，如樣例所示，可以自定義監(jiān)控指標(biāo)。

后面我們會看到Istio中調(diào)用鏈的數(shù)據(jù)也可以通過Mixer來收集。
Istio和Kubernetes的天然結(jié)合

盡管Isito強調(diào)自己的可擴展性的重要一點就是可以適配各種不同的平臺，但實際場景上，甚至看Istio當(dāng)前代碼、設(shè)計可以發(fā)現(xiàn)其所有重要的能力都是基于Kubernetes展開的。Istio與Kubernetes結(jié)合之緊密，甚至有描述說看上去是一個團隊開發(fā)的。即Istio就是基于Kubernetes之上，對Kubernetes能力的補齊。

從功能場景看，Kubernetes提供了部署、升級和有限的運行流量管理能力；利用Service的機制來做服務(wù)注冊和發(fā)現(xiàn)，轉(zhuǎn)發(fā)，通過Kubeproxy有一定的轉(zhuǎn)發(fā)和負(fù)載均衡能力。但是往上的如熔斷、限流降級、調(diào)用鏈等治理能力就沒有了。前面的功能介紹可以發(fā)現(xiàn)Istio很好的補齊了Kubernetes在服務(wù)治理上的這部分能力。即Kubernetes提供了基礎(chǔ)服務(wù)運行能力，而Istio基于其上提供服務(wù)治理能力，對Kubernetes服務(wù)的治理能力。

除了功能互補外，從形態(tài)上看Istio也是基于Kubernetes構(gòu)建的。包括： Sicecar 運行在Kubernetes Pod里，作為一個Proxy和業(yè)務(wù)容器部署在一起，部署過程對用戶透明。Mesh中要求業(yè)務(wù)程序的運行感知不到Sidecar的存在，基于Kubernetes的pod的設(shè)計這部分做的更徹底，對用戶更透明，通過Isito的自動注入用戶甚至感知不到部署Sidecar的這個過程，和部署一個一般的Deployment沒有任何差別。試想如果是通過VM上部署一個Agent，不會有這么方便。

另外Istio的服務(wù)發(fā)現(xiàn)也是非常完美基于Kubernetes的域名訪問機制構(gòu)建。Isito中的服務(wù)就是Kubernetes的服務(wù)，避免了之前使用獨立的微服務(wù)框架在Kubernetes上運行時兩套名字服務(wù)的尬尷和困惑。機制上Pilot通過在kubernetes里面注冊一個controller來監(jiān)聽事件，從而獲取Service和Kubernetes的Endpoint以及Pod的關(guān)系，并將這些映射關(guān)系轉(zhuǎn)換成為Istio的統(tǒng)一抽象模型下發(fā)到Envoy進行轉(zhuǎn)發(fā)。

Istio所有的我們熟悉的路由規(guī)則、控制策略都是通過Kubernetes CRD表達(dá)，不需要一個單獨的APIserver和后端的配置管理。所以Istio APIServer就是Kubernetes的KubeAPIServer，數(shù)據(jù)也當(dāng)然的存在了對應(yīng)Kubernetes的ETCD中。

就連Istio的命令行工具Istioctl都是類似Kubectl風(fēng)格的功能，提供基于命令行的配置功能。