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

調(diào)用鏈原理和場(chǎng)景

正如Service Mesh的誕生是為了解決大規(guī)模分布式服務(wù)訪問的治理問題，調(diào)用鏈的出現(xiàn)也是為了對(duì)應(yīng)于大規(guī)模的復(fù)雜的分布式系統(tǒng)運(yùn)行中碰到的故障定位定界問題。大量的服務(wù)調(diào)用、跨進(jìn)程、跨服務(wù)器，可能還會(huì)跨多個(gè)物理機(jī)房。無論是服務(wù)自身問題還是網(wǎng)絡(luò)環(huán)境的問題導(dǎo)致調(diào)用上鏈路上出現(xiàn)問題都比較復(fù)雜，如何定位就比單進(jìn)程的一個(gè)服務(wù)打印一個(gè)異常棧來找出某個(gè)方法要困難的多。需要有一個(gè)類似的調(diào)用鏈路的跟蹤，經(jīng)一次請(qǐng)求的邏輯規(guī)矩完整的表達(dá)出來，可以觀察到每個(gè)階段的調(diào)用關(guān)系，并能看到每個(gè)階段的耗時(shí)和調(diào)用詳細(xì)情況。

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的機(jī)制。模型中包含的術(shù)語(yǔ)也很多，理解最主要的兩個(gè)即可：

Trace：一次完整的分布式調(diào)用跟蹤鏈路。

Span：跨服務(wù)的一次調(diào)用； 多個(gè)Span組合成一次Trace追蹤記錄。

上圖是Dapper論文中的經(jīng)典圖示，左表示一個(gè)分布式調(diào)用關(guān)系。前端（A），兩個(gè)中間層（B和C），以及兩個(gè)后端（D和E）。用戶發(fā)起一個(gè)請(qǐng)求時(shí)，先到達(dá)前端，再發(fā)送兩個(gè)服務(wù)B和C。B直接應(yīng)答，C服務(wù)調(diào)用后端D和E交互之后給A應(yīng)答，A進(jìn)而返回最終應(yīng)答。要使用調(diào)用鏈跟蹤，就是給每次調(diào)用添加TraceId、SpanId這樣的跟蹤標(biāo)識(shí)和時(shí)間戳。

右表示對(duì)應(yīng)Span的管理關(guān)系。每個(gè)節(jié)點(diǎn)是一個(gè)Span，表示一個(gè)調(diào)用。至少包含Span的名、父SpanId和SpanId。節(jié)點(diǎn)間的連線下表示Span和父Span的關(guān)系。所有的Span屬于一個(gè)跟蹤，共用一個(gè)TraceId。從圖上可以看到對(duì)前端A的調(diào)用Span的兩個(gè)子Span分別是對(duì)B和C調(diào)用的Span，D和E兩個(gè)后端服務(wù)調(diào)用的Span則都是C的子Span。

調(diào)用鏈系統(tǒng)有很多實(shí)現(xiàn)，用的比較多的如zipkin，還有已經(jīng)加入CNCF基金會(huì)并且的用的越來越多的Jaeger，滿足Opentracing語(yǔ)義標(biāo)準(zhǔn)的就有這么多。

一個(gè)完整的調(diào)用鏈跟蹤系統(tǒng)，包括調(diào)用鏈埋點(diǎn)，調(diào)用鏈數(shù)據(jù)收集，調(diào)用鏈數(shù)據(jù)存儲(chǔ)和處理，調(diào)用鏈數(shù)據(jù)檢索（除了提供檢索的APIServer，一般還要包含一個(gè)非常酷炫的調(diào)用鏈前端）等若干重要組件。上圖是Jaeger的一個(gè)完整實(shí)現(xiàn)。這里我們僅關(guān)注與應(yīng)用相關(guān)的內(nèi)容，即調(diào)用鏈埋點(diǎn)的部分，看下在Istio中是否能做到”無侵入“的調(diào)用鏈埋點(diǎn)。當(dāng)然在最后也會(huì)看下Istio機(jī)制下提供的不同的調(diào)用鏈數(shù)據(jù)收集方式。

Istio標(biāo)準(zhǔn)BookInfo例子

簡(jiǎn)單期間，我們以Istio最經(jīng)典的Bookinfo為例來說明。Bookinfo模擬在線書店的一個(gè)分類，顯示一本書的信息。本身是一個(gè)異構(gòu)應(yīng)用，幾個(gè)服務(wù)分別由不同的語(yǔ)言編寫的。

各個(gè)服務(wù)的模擬作用和調(diào)用關(guān)系是：

productpage ：productpage 服務(wù)會(huì)調(diào)用 details 和 reviews 兩個(gè)服務(wù)，用來生成頁(yè)面。

details ：這個(gè)微服務(wù)包含了書籍的信息。

reviews ：這個(gè)微服務(wù)包含了書籍相關(guān)的評(píng)論。并調(diào)用 ratings 微服務(wù)。

ratings ：ratings 微服務(wù)中包含了由書籍評(píng)價(jià)組成的評(píng)級(jí)信息。

調(diào)用鏈輸出

在Istio上運(yùn)行這個(gè)典型例子，不用做任何的代碼修改，自帶的Zipkin上就能看到如下的調(diào)用鏈輸出。

可以看到展示給我們的調(diào)用鏈和Boookinfo這個(gè)場(chǎng)景設(shè)計(jì)的調(diào)用關(guān)系一致：productpage 服務(wù)會(huì)調(diào)用 details 和 reviews 兩個(gè)服務(wù)，reviews調(diào)用了ratings 微服務(wù)。除了顯示調(diào)用關(guān)系外，還顯示了每個(gè)中間調(diào)用的耗時(shí)和調(diào)用詳情?；谶@個(gè)視圖，服務(wù)的運(yùn)維人員比較直觀的定界到慢的或者有問題的服務(wù)，并鉆取當(dāng)時(shí)的調(diào)用細(xì)節(jié)，進(jìn)而定位到問題。

我們就要關(guān)注下調(diào)用鏈埋點(diǎn)到底是在哪里做的，怎么做的？

在Istio中，所有的治理邏輯的執(zhí)行體都是和業(yè)務(wù)容器一起部署的Envoy這個(gè)Sidecar，不管是負(fù)載均衡、熔斷、流量路由還是安全、可觀察性的數(shù)據(jù)生成都是在Envoy上。Sidecar攔截了所有的流入和流出業(yè)務(wù)程序的流量，根據(jù)收到的規(guī)則執(zhí)行執(zhí)行各種動(dòng)作。實(shí)際使用中一般是基于K8S提供的InitContainer機(jī)制，用于在Pod中執(zhí)行一些初始化任務(wù). InitContainer中執(zhí)行了一段iptables的腳本。正是通過這些Iptables規(guī)則攔截pod中流量，并發(fā)送到Envoy上。Envoy攔截到Inbound和Outbound的流量會(huì)分別作不同操作，執(zhí)行上面配置的操作，另外再把請(qǐng)求往下發(fā)，對(duì)于Outbound就是根據(jù)服務(wù)發(fā)現(xiàn)找到對(duì)應(yīng)的目標(biāo)服務(wù)后端上；對(duì)于Inbound流量則直接發(fā)到本地的服務(wù)實(shí)例上。

我們今天的重點(diǎn)是看下攔截到流量后Sidecar在調(diào)用鏈埋點(diǎn)怎么做的。

Istio調(diào)用鏈埋點(diǎn)邏輯

Envoy的埋點(diǎn)規(guī)則和在其他服務(wù)調(diào)用方和被調(diào)用方的對(duì)應(yīng)埋點(diǎn)邏輯沒有太大差別。

Inbound流量：對(duì)于經(jīng)過Sidecar流入應(yīng)用程序的流量，如果經(jīng)過Sidecar時(shí)Header中沒有任何跟蹤相關(guān)的信息，則會(huì)在創(chuàng)建一個(gè)根Span，TraceId就是這個(gè)SpanId，然后再將請(qǐng)求傳遞給業(yè)務(wù)容器的服務(wù)；如果請(qǐng)求中包含Trace相關(guān)的信息，則Sidecar從中提取Trace的上下文信息并發(fā)給應(yīng)用程序。

Outbound流量：對(duì)于經(jīng)過Sidecar流出的流量，如果經(jīng)過Sidecar時(shí)Header中沒有任何跟蹤相關(guān)的信息，則會(huì)創(chuàng)建根Span，并將該跟Span相關(guān)上下文信息放在請(qǐng)求頭中傳遞給下一個(gè)調(diào)用的服務(wù)；當(dāng)存在Trace信息時(shí)，Sidecar從Header中提取Span相關(guān)信息，并基于這個(gè)Span創(chuàng)建子Span，并將新的Span信息加在請(qǐng)求頭中傳遞。

特別是Outbound部分的調(diào)用鏈埋點(diǎn)邏輯，通過一段偽代碼描述如圖：

調(diào)用鏈詳細(xì)解析

如圖是對(duì)前面Zipkin上輸出的一個(gè)Trace一個(gè)透視圖，觀察下每個(gè)調(diào)用的細(xì)節(jié)。可以看到每個(gè)階段四個(gè)服務(wù)與部署在它旁邊上的Sidecar是怎么配合的。在圖上只標(biāo)記了Sidecar生成的Span主要信息。

因?yàn)镾idecar 處理 Inbound和Outbound的邏輯有所不同，在圖上表也分開兩個(gè)框圖分開表達(dá)。如productpage，接收外部請(qǐng)求是一個(gè)處理，給details發(fā)出請(qǐng)求是一個(gè)處理，給reviews發(fā)出請(qǐng)求是另外一個(gè)處理，因此圍繞productpage這個(gè)app有三個(gè)黑色的處理塊，其實(shí)是一個(gè)Sidecar在做事。

同時(shí)，為了不使的圖上箭頭太多，最終的Response都沒有表達(dá)出來，其實(shí)圖上每個(gè)請(qǐng)求的箭頭都有一個(gè)反方向的Response。在服務(wù)發(fā)起方的Sidecar會(huì)收到Response時(shí)，會(huì)記錄一個(gè)CR(client Received)表示收到響應(yīng)的時(shí)間并計(jì)算整個(gè)Span的持續(xù)時(shí)間。

下面通過解析下具體數(shù)據(jù)來找出埋點(diǎn)邏輯：

首先從調(diào)用入口的Gateway開始，Gateway作為一個(gè)獨(dú)立部署在一個(gè)pod中的Envoy進(jìn)程，當(dāng)有請(qǐng)求過來時(shí)，它會(huì)將請(qǐng)求轉(zhuǎn)給入口服務(wù)productpage。Gateway這個(gè)Envoy在發(fā)出請(qǐng)求時(shí)里面沒有Trace信息，會(huì)生成一個(gè)根Span：SpanId和TraceId都是f79a31352fe7cae9，因?yàn)槭堑谝粋€(gè)調(diào)用鏈上的第一個(gè)Span，也就是一般說的根Span，所有ParentId為空，在這個(gè)時(shí)候會(huì)記錄CS（Client Send）；

請(qǐng)求從入口Gateway這個(gè)Envoy進(jìn)入productpage的app業(yè)務(wù)進(jìn)程其Inbound流量被productpage Pod內(nèi)的Envoy攔截，Envoy處理請(qǐng)求頭中帶著Trace信息，記錄SR(Server Received)，并將請(qǐng)求發(fā)送給productpage業(yè)務(wù)容器處理，productpage在處理請(qǐng)求的業(yè)務(wù)方法中在接受調(diào)用的參數(shù)時(shí)，除了接受一般的業(yè)務(wù)參數(shù)外，同時(shí)解析請(qǐng)求中的調(diào)用鏈Header信息，并把Header中的Trace信息傳遞給了調(diào)用的Details和Reviews的微服務(wù)。

從productpage出去的請(qǐng)求到達(dá)reviews服務(wù)前，其Oubtbound流量又一次通過同Pod的Envoy，Envoy埋點(diǎn)邏輯檢查Header中包含了Trace相關(guān)信息，在將請(qǐng)求發(fā)出前會(huì)做客戶端的調(diào)用鏈埋點(diǎn)，即以當(dāng)前Span為parent Span，生成一個(gè)子Span：新的SpanId cb4c86fb667f3114，TraceId保持一致9a31352fe7cae9，ParentId就是上個(gè)Span的Id： f79a31352fe7cae9。

從prodcutepage到review的請(qǐng)求經(jīng)過productpage的Sidecar走LB后，發(fā)給一個(gè)review的實(shí)例。請(qǐng)求在到達(dá)Review業(yè)務(wù)容器前，同樣也被Review的Envoy攔截，Envoy檢查從Header中解析出Trace信息存在，則發(fā)送Trace信息給reviews。reviews處理請(qǐng)求的服務(wù)端代碼中同樣接收和解析出這些包含Trace的Header信息，發(fā)送給下一個(gè)Ratings服務(wù)。

在這里我們只是理了一遍請(qǐng)求從入口Gateway，訪問productpage服務(wù)，再訪問reviews服務(wù)的流程。可以看到期間每個(gè)訪問階段，對(duì)服務(wù)的Inbound和Outbound流量都會(huì)被Envoy攔截并執(zhí)行對(duì)應(yīng)的調(diào)用鏈埋點(diǎn)邏輯。圖示的Reviews訪問Ratings和productpage訪問Details邏輯與以上類似，這里不做復(fù)述。

以上過程也印證了前面我們提出的Envoy的埋點(diǎn)邏輯?？梢钥吹竭^程中除了Envoy再處理Inbound和Outbound流量時(shí)要執(zhí)行對(duì)應(yīng)的埋點(diǎn)邏輯外。每一步的調(diào)用要串起來，應(yīng)用程序其實(shí)做了些事情。就是在將請(qǐng)求發(fā)給下一個(gè)服務(wù)時(shí)，需要將調(diào)用鏈相關(guān)的信息同樣傳下去，盡管這些Trace和Span的標(biāo)識(shí)并不是它生成的。這樣在出流量的proxy向下一跳服務(wù)發(fā)起請(qǐng)求前才能判斷并生成子Span并和原Span進(jìn)行關(guān)聯(lián)，進(jìn)而形成一個(gè)完整的調(diào)用鏈。否則，如果在應(yīng)用容器未處理Header中的Trace，則Sidecar在處理請(qǐng)求時(shí)會(huì)創(chuàng)建根Span，最終會(huì)形成若干個(gè)割裂的Span，并不能被關(guān)聯(lián)到一個(gè)Trace上，就會(huì)出現(xiàn)我們開始提到的問題。

不斷被問到兩個(gè)問題來試圖說明這個(gè)業(yè)務(wù)代碼配合修改來實(shí)現(xiàn)調(diào)用鏈邏輯可能不必要：?jiǎn)栴}一、既然傳入的請(qǐng)求上已經(jīng)帶了這些Header信息了，直接往下一直傳不就好了嗎？Sidecar請(qǐng)求APP的時(shí)候帶著這些Header，APP請(qǐng)求Sidecar時(shí)也帶著這些Header不就完了嗎？問題二、既然TraceId和SpanId是Sidecar生成的，為什么要再費(fèi)勁讓App收到請(qǐng)求的時(shí)候解析下，發(fā)出請(qǐng)求時(shí)候再帶著發(fā)出來傳回給Sidecar呢？

回答問題一，只需理解一點(diǎn)，這里的App業(yè)務(wù)代碼是處理請(qǐng)求不是轉(zhuǎn)發(fā)請(qǐng)求，即圖上左邊的Request to Productpage 到prodcutpage中請(qǐng)求就截止了，要怎么處理完全是productpage的服務(wù)接口的內(nèi)容了，可以是調(diào)用本地處理邏輯直接返回，也可以是如示例中的場(chǎng)景構(gòu)造新的請(qǐng)求調(diào)用其他的服務(wù)。右邊的Request from productpage 完全是服務(wù)構(gòu)造的發(fā)出的另外一個(gè)請(qǐng)求；

回答問題二，需要理解當(dāng)前Envoy是獨(dú)立的Listener來處理Inbound和Outbound的請(qǐng)求。Inbound只會(huì)處理入的流量并將流量轉(zhuǎn)發(fā)到本地的服務(wù)實(shí)例上。而Outbound就是根據(jù)服務(wù)發(fā)現(xiàn)找到對(duì)應(yīng)的目標(biāo)服務(wù)后端上。除了實(shí)在一個(gè)進(jìn)程里外兩個(gè)之間可以說沒有任何關(guān)系。 另外如問題一描述，因?yàn)榈絆utbound已經(jīng)是一個(gè)新構(gòu)造的請(qǐng)求了，使得想維護(hù)一個(gè)map來記錄這些Trace信息這種方案也變得不可行。

這樣基于一個(gè)例子來打開看一個(gè)調(diào)用鏈的主要過程就介紹到這里。附加productpage訪問reviews的Span詳細(xì)，刪減掉一些數(shù)據(jù)只保留主要信息大致是這樣：

Productpage的Proxy上報(bào)了個(gè)CS，CR, reviews的那個(gè)proxy上報(bào)了個(gè)SS，SR。分別表示Productpage作為client什么時(shí)候發(fā)出請(qǐng)求，什么時(shí)候最終收到請(qǐng)求，reviews的proxy什么時(shí)候收到了客戶端的請(qǐng)求，什么時(shí)候發(fā)出了response。另外還包括這次訪問的其他信息如Response Code、Response Size等。

根據(jù)前面的分析我們可以得到結(jié)論：埋點(diǎn)邏輯是在Sidecar代理中完成，應(yīng)用程序不用處理復(fù)雜的埋點(diǎn)邏輯，但應(yīng)用程序需要配合在請(qǐng)求頭上傳遞生成的Trace相關(guān)信息。

服務(wù)代碼修改示例

前面通過一個(gè)典型例子詳細(xì)解析了Istio的調(diào)用鏈埋點(diǎn)過程中Envoy作為Sidecar和應(yīng)用程序的配合關(guān)系。分析的結(jié)論是調(diào)用鏈埋點(diǎn)由Envoy來執(zhí)行，但是業(yè)務(wù)程序要有適當(dāng)修改。下面抽取服務(wù)代碼來印證下。

Python寫的 productpage在服務(wù)端處理請(qǐng)求時(shí)，先從Request中提取接收到的Header。然后再構(gòu)造請(qǐng)求調(diào)用details獲取服務(wù)接口，并將Header轉(zhuǎn)發(fā)出去。

首先處理productpage請(qǐng)問的rest方法中從Request中提取Trace相關(guān)的Header。

然后重新構(gòu)造一個(gè)請(qǐng)求發(fā)出去，請(qǐng)求reviews服務(wù)接口。可以看到請(qǐng)求中包含收到的Header。

reviews服務(wù)中Java的Rest代碼類似，在服務(wù)端接收請(qǐng)求時(shí)，除了接收Request中的業(yè)務(wù)參數(shù)外，還要提取Header信息，調(diào)用Ratings服務(wù)時(shí)再傳遞下去。其他的productpage調(diào)用details，reviews調(diào)用ratings邏輯類似。

當(dāng)然這里只是個(gè)demo，示意下要在那個(gè)位置修改代碼。實(shí)際項(xiàng)目中我們不會(huì)這樣在每個(gè)業(yè)務(wù)方法上作這樣的修改，這樣對(duì)代碼的侵入，甚至說污染太嚴(yán)重。根據(jù)語(yǔ)言的特點(diǎn)會(huì)盡力把這段邏輯提取成一段通用邏輯。

Istio調(diào)用鏈數(shù)據(jù)收集：by Envoy

一個(gè)完整的埋點(diǎn)過程，除了inject、extract這種處理Span信息，創(chuàng)建Span外，還要將Span report到一個(gè)調(diào)用鏈的服務(wù)端，進(jìn)行存儲(chǔ)并支持檢索。在Isito中這些都是在Envoy這個(gè)Sidecar中處理，業(yè)務(wù)程序不用關(guān)心。在proxy自動(dòng)注入到業(yè)務(wù)pod時(shí)，會(huì)自動(dòng)刷這個(gè)后端地址.

即Envoy會(huì)連接zipkin的服務(wù)端上報(bào)調(diào)用鏈數(shù)據(jù)，這些業(yè)務(wù)容器完全不用關(guān)心。當(dāng)然這個(gè)調(diào) 用鏈?zhǔn)占暮蠖说刂放渲贸蒵aeger也是ok的，因?yàn)镴aeger在接收數(shù)據(jù)是兼容zipkin格式的。

Istio調(diào)用鏈數(shù)據(jù)收集：by Mixer

除了直接從Envoy上報(bào)調(diào)用鏈到zipkin后端外，Istio提供了Mixer這個(gè)統(tǒng)一的面板來對(duì)接不同的后端來收集遙測(cè)數(shù)據(jù)，當(dāng)然Trace數(shù)據(jù)也可以采用同樣的方式。

即如TraceSpan中描述，創(chuàng)建一個(gè)TraceSpan的模板，來描述從mixer的一次訪問中提取哪些數(shù)據(jù)，可以看到Trace相關(guān)的幾個(gè)ID從請(qǐng)求的Header中提取。除了基礎(chǔ)數(shù)據(jù)外，基于Mixer和kubernetes的繼承能力，有些對(duì)象的元數(shù)據(jù)，如Pod上的相關(guān)信息Mixr可以補(bǔ)充，背后其實(shí)是Mixer連了kubeapiserver獲取對(duì)應(yīng)的pod資源，從而較之直接從Envoy上收集的原始數(shù)據(jù)，可以有更多的業(yè)務(wù)上的擴(kuò)張，如namespace、cluster等信息APM數(shù)據(jù)要用到，但是Envoy本身不會(huì)生成，通過這種方式就可以從Kubernetes中自動(dòng)補(bǔ)充完整，非常方便。

這也是Istio的核心組件Mixer在可觀察性上的一個(gè)優(yōu)秀實(shí)踐。

Istio官方說明更新

最近一直在和社區(qū)溝通，督促在更顯著的位置明確的告訴使用者用Istio作治理并不是所有場(chǎng)景下都不需要修改代碼，比如調(diào)用鏈，雖然用戶不用業(yè)務(wù)代碼埋點(diǎn)，但還是需要修改些代碼。尤其是避免首頁(yè)“without any change”對(duì)大家的誤導(dǎo)。得到回應(yīng)是1.1中社區(qū)首頁(yè)what-is-istio已經(jīng)修改了這部分說明，不再是1.0中說without any changes in service code，而是改為with few or no code changes in service code。提示大家在使用Isito進(jìn)行調(diào)用鏈埋點(diǎn)時(shí)，應(yīng)用程序需要進(jìn)行適當(dāng)?shù)男薷?。?dāng)然了解了其中原理，做起來也不會(huì)太麻煩。

改了個(gè)程度輕一點(diǎn)的否定詞，很少幾乎不用修改，還是基本不用改的意思。這也是社區(qū)一貫的觀點(diǎn)。

結(jié)合對(duì)Istio調(diào)用鏈的原理的分析和一個(gè)典型例子中細(xì)節(jié)字段、流程包括代碼的額解析，再加上和社區(qū)溝通的觀點(diǎn)。得到以下結(jié)論：

Istio的絕大多數(shù)治理能力都是在Sidecar而非應(yīng)用程序中實(shí)現(xiàn)，因此是非侵入的；

Istio的調(diào)用鏈埋點(diǎn)邏輯也是在Sidecar代理中完成，對(duì)應(yīng)用程序非侵入，但應(yīng)用程序需做適當(dāng)?shù)男薷?，即配合在?qǐng)求頭上傳遞生成的Trace相關(guān)信息。

華為云Istio服務(wù)網(wǎng)格公測(cè)中

在騰訊的場(chǎng)子上只講干貨的技術(shù)，盡量少做廣告。在這里只是用一頁(yè)P(yáng)PT來簡(jiǎn)單介紹下華為云當(dāng)前正在公測(cè)的Istio服務(wù)網(wǎng)格服務(wù)。

華為云容器引擎CCE的深度集成，一鍵啟用后，即可享受Istio服務(wù)網(wǎng)格的全部治理能力；基于應(yīng)用運(yùn)行的全景視圖配置管理熔斷、故障注入、負(fù)載均衡等多種智能流量治理功能；內(nèi)置金絲雀、A/B Testing典型灰度發(fā)布流程灰度版本一鍵部署，流量切換一鍵生效；配置式基于流量比例、請(qǐng)求內(nèi)容灰度策略配置，一站式健康、性能、流量監(jiān)控，實(shí)現(xiàn)灰度發(fā)布過程量化、智能化、可視化；集成華為云APM，使用調(diào)用鏈、應(yīng)用拓?fù)涞榷喾N手段對(duì)應(yīng)用運(yùn)行進(jìn)行透視、診斷和管理。

華為云Istio社區(qū)貢獻(xiàn)

華為作為CNCF 基金會(huì)的初創(chuàng)會(huì)員、白金會(huì)員，CNCF / Kubernetes TOC 成員。在Kubernetes社區(qū)貢獻(xiàn)國(guó)內(nèi)第一，全球第三，全球貢獻(xiàn)3000+ PR，先后貢獻(xiàn)了集群聯(lián)邦、高級(jí)調(diào)度策略、IPVS負(fù)載均衡，容器存儲(chǔ)快照等重要項(xiàng)目。

隨著Istio項(xiàng)目的深入產(chǎn)品化，團(tuán)隊(duì)也積極投入到Istio的社區(qū)貢獻(xiàn)。當(dāng)前社區(qū)貢獻(xiàn)國(guó)內(nèi)第一，全球第三。Approver 3席，Member 6席，Contributor 若干。

通過Pilot agent轉(zhuǎn)發(fā)實(shí)現(xiàn)HTTP協(xié)議的健康檢查： 針對(duì)mTLS enabled環(huán)境，傳統(tǒng)的kubernetes http健康檢查不能工作，實(shí)現(xiàn) sidecar轉(zhuǎn)發(fā)功能，以及injector的自動(dòng)注入。

Istioctl debug功能增強(qiáng)：針對(duì)istioctl缺失查詢sidecar中endpoint的能力，增加proxy-config endpoint、proxy-status endpoint命令，提高debug效率。

HTTPRetry API增強(qiáng)： 增加HTTPRetry 配置項(xiàng)RetryOn策略，可以通過此控制sidecar重試。

MCP 配置實(shí)現(xiàn)： Pilot支持mesh configuration, 可以與galley等多個(gè)實(shí)現(xiàn)了MCP協(xié)議的server端交互獲取配置。以此解耦后端注冊(cè)中心。

Pilot CPU異常問題解決：1.0.0-snapshot.0 pilot free 狀態(tài)CPU 利用率超過20%，降低到1%以下。

Pilot 服務(wù)數(shù)據(jù)下發(fā)優(yōu)化：緩存service，避免每次push時(shí)進(jìn)行重復(fù)的轉(zhuǎn)換。

Pilot服務(wù)實(shí)例查詢優(yōu)化：根據(jù)label selector查詢endpoints（涵蓋95%以上的場(chǎng)景），避免遍歷所有namespace的endpoints。

Pilot 數(shù)據(jù)Push性能優(yōu)化：將原有的串行順序推送配置，更新為并行push，降低配置下發(fā)時(shí)延。