調(diào)用鏈原理和場景
正如Service Mesh的誕生是為了解決大規(guī)模分布式服務(wù)訪問的治理問題，調(diào)用鏈的出現(xiàn)也是為了對應(yīng)于大規(guī)模的復(fù)雜的分布式系統(tǒng)運行中碰到的故障定位定界問題。大量的服務(wù)調(diào)用、跨進程、跨服務(wù)器，可能還會跨多個物理機房。無論是服務(wù)自身問題還是網(wǎng)絡(luò)環(huán)境的問題導(dǎo)致調(diào)用上鏈路上出現(xiàn)問題都比較復(fù)雜，如何定位就比單進程的一個服務(wù)打印一個異常棧來找出某個方法要困難的多。需要有一個類似的調(diào)用鏈路的跟蹤，經(jīng)一次請求的邏輯規(guī)矩完整的表達出來，可以觀察到每個階段的調(diào)用關(guān)系，并能看到每個階段的耗時和調(diào)用詳細(xì)情況。
Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的機制。模型中包含的術(shù)語也很多，理解最主要的兩個即可：
Trace：一次完整的分布式調(diào)用跟蹤鏈路。
Span：跨服務(wù)的一次調(diào)用； 多個Span組合成一次Trace追蹤記錄。
上圖是Dapper論文中的經(jīng)典圖示，左表示一個分布式調(diào)用關(guān)系。前端（A），兩個中間層（B和C），以及兩個后端（D和E）。用戶發(fā)起一個請求時，先到達前端，再發(fā)送兩個服務(wù)B和C。B直接應(yīng)答，C服務(wù)調(diào)用后端D和E交互之后給A應(yīng)答，A進而返回最終應(yīng)答。要使用調(diào)用鏈跟蹤，就是給每次調(diào)用添加TraceId、SpanId這樣的跟蹤標(biāo)識和時間戳。
右表示對應(yīng)Span的管理關(guān)系。每個節(jié)點是一個Span，表示一個調(diào)用。至少包含Span的名、父SpanId和SpanId。節(jié)點間的連線下表示Span和父Span的關(guān)系。所有的Span屬于一個跟蹤，共用一個TraceId。從圖上可以看到對前端A的調(diào)用Span的兩個子Span分別是對B和C調(diào)用的Span，D和E兩個后端服務(wù)調(diào)用的Span則都是C的子Span。
調(diào)用鏈系統(tǒng)有很多實現(xiàn)，用的比較多的如zipkin，還有已經(jīng)加入CNCF基金會并且的用的越來越多的Jaeger，滿足Opentracing語義標(biāo)準(zhǔn)的就有這么多。
一個完整的調(diào)用鏈跟蹤系統(tǒng)，包括調(diào)用鏈埋點，調(diào)用鏈數(shù)據(jù)收集，調(diào)用鏈數(shù)據(jù)存儲和處理，調(diào)用鏈數(shù)據(jù)檢索（除了提供檢索的APIServer，一般還要包含一個非?？犰诺恼{(diào)用鏈前端）等若干重要組件。上圖是Jaeger的一個完整實現(xiàn)。這里我們僅關(guān)注與應(yīng)用相關(guān)的內(nèi)容，即調(diào)用鏈埋點的部分，看下在Istio中是否能做到”無侵入“的調(diào)用鏈埋點。當(dāng)然在最后也會看下Istio機制下提供的不同的調(diào)用鏈數(shù)據(jù)收集方式。
Istio標(biāo)準(zhǔn)BookInfo例子
簡單期間，我們以Istio最經(jīng)典的Bookinfo為例來說明。Bookinfo模擬在線書店的一個分類，顯示一本書的信息。本身是一個異構(gòu)應(yīng)用，幾個服務(wù)分別由不同的語言編寫的。
各個服務(wù)的模擬作用和調(diào)用關(guān)系是：
productpage ：productpage 服務(wù)會調(diào)用 details 和 reviews 兩個服務(wù)，用來生成頁面。
details ：這個微服務(wù)包含了書籍的信息。
reviews ：這個微服務(wù)包含了書籍相關(guān)的評論。并調(diào)用 ratings 微服務(wù)。
ratings ：ratings 微服務(wù)中包含了由書籍評價組成的評級信息。
調(diào)用鏈輸出
在Istio上運行這個典型例子，不用做任何的代碼修改，自帶的Zipkin上就能看到如下的調(diào)用鏈輸出。
可以看到展示給我們的調(diào)用鏈和Boookinfo這個場景設(shè)計的調(diào)用關(guān)系一致：productpage 服務(wù)會調(diào)用 details 和 reviews 兩個服務(wù)，reviews調(diào)用了ratings 微服務(wù)。除了顯示調(diào)用關(guān)系外，還顯示了每個中間調(diào)用的耗時和調(diào)用詳情?；谶@個視圖，服務(wù)的運維人員比較直觀的定界到慢的或者有問題的服務(wù)，并鉆取當(dāng)時的調(diào)用細(xì)節(jié)，進而定位到問題。
我們就要關(guān)注下調(diào)用鏈埋點到底是在哪里做的，怎么做的？
在Istio中，所有的治理邏輯的執(zhí)行體都是和業(yè)務(wù)容器一起部署的Envoy這個Sidecar，不管是負(fù)載均衡、熔斷、流量路由還是安全、可觀察性的數(shù)據(jù)生成都是在Envoy上。Sidecar攔截了所有的流入和流出業(yè)務(wù)程序的流量，根據(jù)收到的規(guī)則執(zhí)行執(zhí)行各種動作。實際使用中一般是基于K8S提供的InitContainer機制，用于在Pod中執(zhí)行一些初始化任務(wù). InitContainer中執(zhí)行了一段iptables的腳本。正是通過這些Iptables規(guī)則攔截pod中流量，并發(fā)送到Envoy上。Envoy攔截到Inbound和Outbound的流量會分別作不同操作，執(zhí)行上面配置的操作，另外再把請求往下發(fā)，對于Outbound就是根據(jù)服務(wù)發(fā)現(xiàn)找到對應(yīng)的目標(biāo)服務(wù)后端上；對于Inbound流量則直接發(fā)到本地的服務(wù)實例上。
我們今天的重點是看下攔截到流量后Sidecar在調(diào)用鏈埋點怎么做的。
Istio調(diào)用鏈埋點邏輯
Envoy的埋點規(guī)則和在其他服務(wù)調(diào)用方和被調(diào)用方的對應(yīng)埋點邏輯沒有太大差別。
Inbound流量：對于經(jīng)過Sidecar流入應(yīng)用程序的流量，如果經(jīng)過Sidecar時Header中沒有任何跟蹤相關(guān)的信息，則會在創(chuàng)建一個根Span，TraceId就是這個SpanId，然后再將請求傳遞給業(yè)務(wù)容器的服務(wù)；如果請求中包含Trace相關(guān)的信息，則Sidecar從中提取Trace的上下文信息并發(fā)給應(yīng)用程序。
Outbound流量：對于經(jīng)過Sidecar流出的流量，如果經(jīng)過Sidecar時Header中沒有任何跟蹤相關(guān)的信息，則會創(chuàng)建根Span，并將該跟Span相關(guān)上下文信息放在請求頭中傳遞給下一個調(diào)用的服務(wù)；當(dāng)存在Trace信息時，Sidecar從Header中提取Span相關(guān)信息，并基于這個Span創(chuàng)建子Span，并將新的Span信息加在請求頭中傳遞。
特別是Outbound部分的調(diào)用鏈埋點邏輯，通過一段偽代碼描述如圖：
調(diào)用鏈詳細(xì)解析
如圖是對前面Zipkin上輸出的一個Trace一個透視圖，觀察下每個調(diào)用的細(xì)節(jié)?？梢钥吹矫總€階段四個服務(wù)與部署在它旁邊上的Sidecar是怎么配合的。在圖上只標(biāo)記了Sidecar生成的Span主要信息。
因為Sidecar 處理 Inbound和Outbound的邏輯有所不同，在圖上表也分開兩個框圖分開表達。如productpage，接收外部請求是一個處理，給details發(fā)出請求是一個處理，給reviews發(fā)出請求是另外一個處理，因此圍繞productpage這個app有三個黑色的處理塊，其實是一個Sidecar在做事。
同時，為了不使的圖上箭頭太多，最終的Response都沒有表達出來，其實圖上每個請求的箭頭都有一個反方向的Response。在服務(wù)發(fā)起方的Sidecar會收到Response時，會記錄一個CR(client Received)表示收到響應(yīng)的時間并計算整個Span的持續(xù)時間。
下面通過解析下具體數(shù)據(jù)來找出埋點邏輯：
首先從調(diào)用入口的Gateway開始，Gateway作為一個獨立部署在一個pod中的Envoy進程，當(dāng)有請求過來時，它會將請求轉(zhuǎn)給入口服務(wù)productpage。Gateway這個Envoy在發(fā)出請求時里面沒有Trace信息，會生成一個根Span：SpanId和TraceId都是f79a31352fe7cae9，因為是第一個調(diào)用鏈上的第一個Span，也就是一般說的根Span，所有ParentId為空，在這個時候會記錄CS（Client Send）；
請求從入口Gateway這個Envoy進入productpage的app業(yè)務(wù)進程其Inbound流量被productpage Pod內(nèi)的Envoy攔截，Envoy處理請求頭中帶著Trace信息，記錄SR(Server Received)，并將請求發(fā)送給productpage業(yè)務(wù)容器處理，productpage在處理請求的業(yè)務(wù)方法中在接受調(diào)用的參數(shù)時，除了接受一般的業(yè)務(wù)參數(shù)外，同時解析請求中的調(diào)用鏈Header信息，并把Header中的Trace信息傳遞給了調(diào)用的Details和Reviews的微服務(wù)。
從productpage出去的請求到達reviews服務(wù)前，其Oubtbound流量又一次通過同Pod的Envoy，Envoy埋點邏輯檢查Header中包含了Trace相關(guān)信息，在將請求發(fā)出前會做客戶端的調(diào)用鏈埋點，即以當(dāng)前Span為parent Span，生成一個子Span：新的SpanId cb4c86fb667f3114，TraceId保持一致9a31352fe7cae9，ParentId就是上個Span的Id： f79a31352fe7cae9。
從prodcutepage到review的請求經(jīng)過productpage的Sidecar走LB后，發(fā)給一個review的實例。請求在到達Review業(yè)務(wù)容器前，同樣也被Review的Envoy攔截，Envoy檢查從Header中解析出Trace信息存在，則發(fā)送Trace信息給reviews。reviews處理請求的服務(wù)端代碼中同樣接收和解析出這些包含Trace的Header信息，發(fā)送給下一個Ratings服務(wù)。
在這里我們只是理了一遍請求從入口Gateway，訪問productpage服務(wù)，再訪問reviews服務(wù)的流程?？梢钥吹狡陂g每個訪問階段，對服務(wù)的Inbound和Outbound流量都會被Envoy攔截并執(zhí)行對應(yīng)的調(diào)用鏈埋點邏輯。圖示的Reviews訪問Ratings和productpage訪問Details邏輯與以上類似，這里不做復(fù)述。
以上過程也印證了前面我們提出的Envoy的埋點邏輯?？梢钥吹竭^程中除了Envoy再處理Inbound和Outbound流量時要執(zhí)行對應(yīng)的埋點邏輯外。每一步的調(diào)用要串起來，應(yīng)用程序其實做了些事情。就是在將請求發(fā)給下一個服務(wù)時，需要將調(diào)用鏈相關(guān)的信息同樣傳下去，盡管這些Trace和Span的標(biāo)識并不是它生成的。這樣在出流量的proxy向下一跳服務(wù)發(fā)起請求前才能判斷并生成子Span并和原Span進行關(guān)聯(lián)，進而形成一個完整的調(diào)用鏈。否則，如果在應(yīng)用容器未處理Header中的Trace，則Sidecar在處理請求時會創(chuàng)建根Span，最終會形成若干個割裂的Span，并不能被關(guān)聯(lián)到一個Trace上，就會出現(xiàn)我們開始提到的問題。
不斷被問到兩個問題來試圖說明這個業(yè)務(wù)代碼配合修改來實現(xiàn)調(diào)用鏈邏輯可能不必要：問題一、既然傳入的請求上已經(jīng)帶了這些Header信息了，直接往下一直傳不就好了嗎？Sidecar請求APP的時候帶著這些Header，APP請求Sidecar時也帶著這些Header不就完了嗎？問題二、既然TraceId和SpanId是Sidecar生成的，為什么要再費勁讓App收到請求的時候解析下，發(fā)出請求時候再帶著發(fā)出來傳回給Sidecar呢？
回答問題一，只需理解一點，這里的App業(yè)務(wù)代碼是處理請求不是轉(zhuǎn)發(fā)請求，即圖上左邊的Request to Productpage 到prodcutpage中請求就截止了，要怎么處理完全是productpage的服務(wù)接口的內(nèi)容了，可以是調(diào)用本地處理邏輯直接返回，也可以是如示例中的場景構(gòu)造新的請求調(diào)用其他的服務(wù)。右邊的Request from productpage 完全是服務(wù)構(gòu)造的發(fā)出的另外一個請求；
回答問題二，需要理解當(dāng)前Envoy是獨立的Listener來處理Inbound和Outbound的請求。Inbound只會處理入的流量并將流量轉(zhuǎn)發(fā)到本地的服務(wù)實例上。而Outbound就是根據(jù)服務(wù)發(fā)現(xiàn)找到對應(yīng)的目標(biāo)服務(wù)后端上。除了實在一個進程里外兩個之間可以說沒有任何關(guān)系。 另外如問題一描述，因為到Outbound已經(jīng)是一個新構(gòu)造的請求了，使得想維護一個map來記錄這些Trace信息這種方案也變得不可行。
這樣基于一個例子來打開看一個調(diào)用鏈的主要過程就介紹到這里。附加productpage訪問reviews的Span詳細(xì)，刪減掉一些數(shù)據(jù)只保留主要信息大致是這樣：
Productpage的Proxy上報了個CS，CR, reviews的那個proxy上報了個SS，SR。分別表示Productpage作為client什么時候發(fā)出請求，什么時候最終收到請求，reviews的proxy什么時候收到了客戶端的請求，什么時候發(fā)出了response。另外還包括這次訪問的其他信息如Response Code、Response Size等。
根據(jù)前面的分析我們可以得到結(jié)論：埋點邏輯是在Sidecar代理中完成，應(yīng)用程序不用處理復(fù)雜的埋點邏輯，但應(yīng)用程序需要配合在請求頭上傳遞生成的Trace相關(guān)信息。
服務(wù)代碼修改示例
前面通過一個典型例子詳細(xì)解析了Istio的調(diào)用鏈埋點過程中Envoy作為Sidecar和應(yīng)用程序的配合關(guān)系。分析的結(jié)論是調(diào)用鏈埋點由Envoy來執(zhí)行，但是業(yè)務(wù)程序要有適當(dāng)修改。下面抽取服務(wù)代碼來印證下。
Python寫的 productpage在服務(wù)端處理請求時，先從Request中提取接收到的Header。然后再構(gòu)造請求調(diào)用details獲取服務(wù)接口，并將Header轉(zhuǎn)發(fā)出去。
首先處理productpage請問的rest方法中從Request中提取Trace相關(guān)的Header。
然后重新構(gòu)造一個請求發(fā)出去，請求reviews服務(wù)接口。可以看到請求中包含收到的Header。
reviews服務(wù)中Java的Rest代碼類似，在服務(wù)端接收請求時，除了接收Request中的業(yè)務(wù)參數(shù)外，還要提取Header信息，調(diào)用Ratings服務(wù)時再傳遞下去。其他的productpage調(diào)用details，reviews調(diào)用ratings邏輯類似。
當(dāng)然這里只是個demo，示意下要在那個位置修改代碼。實際項目中我們不會這樣在每個業(yè)務(wù)方法上作這樣的修改，這樣對代碼的侵入，甚至說污染太嚴(yán)重。根據(jù)語言的特點會盡力把這段邏輯提取成一段通用邏輯。
Istio調(diào)用鏈數(shù)據(jù)收集：by Envoy
一個完整的埋點過程，除了inject、extract這種處理Span信息，創(chuàng)建Span外，還要將Span report到一個調(diào)用鏈的服務(wù)端，進行存儲并支持檢索。在Isito中這些都是在Envoy這個Sidecar中處理，業(yè)務(wù)程序不用關(guān)心。在proxy自動注入到業(yè)務(wù)pod時，會自動刷這個后端地址.
即Envoy會連接zipkin的服務(wù)端上報調(diào)用鏈數(shù)據(jù)，這些業(yè)務(wù)容器完全不用關(guān)心。當(dāng)然這個調(diào) 用鏈?zhǔn)占暮蠖说刂放渲贸蒵aeger也是ok的，因為Jaeger在接收數(shù)據(jù)是兼容zipkin格式的。
Istio調(diào)用鏈數(shù)據(jù)收集：by Mixer
除了直接從Envoy上報調(diào)用鏈到zipkin后端外，Istio提供了Mixer這個統(tǒng)一的面板來對接不同的后端來收集遙測數(shù)據(jù)，當(dāng)然Trace數(shù)據(jù)也可以采用同樣的方式。
即如TraceSpan中描述，創(chuàng)建一個TraceSpan的模板，來描述從mixer的一次訪問中提取哪些數(shù)據(jù)，可以看到Trace相關(guān)的幾個ID從請求的Header中提取。除了基礎(chǔ)數(shù)據(jù)外，基于Mixer和kubernetes的繼承能力，有些對象的元數(shù)據(jù)，如Pod上的相關(guān)信息Mixr可以補充，背后其實是Mixer連了kubeapiserver獲取對應(yīng)的pod資源，從而較之直接從Envoy上收集的原始數(shù)據(jù)，可以有更多的業(yè)務(wù)上的擴張，如namespace、cluster等信息APM數(shù)據(jù)要用到，但是Envoy本身不會生成，通過這種方式就可以從Kubernetes中自動補充完整，非常方便。
這也是Istio的核心組件Mixer在可觀察性上的一個優(yōu)秀實踐。
Istio官方說明更新
最近一直在和社區(qū)溝通，督促在更顯著的位置明確的告訴使用者用Istio作治理并不是所有場景下都不需要修改代碼，比如調(diào)用鏈，雖然用戶不用業(yè)務(wù)代碼埋點，但還是需要修改些代碼。尤其是避免首頁“without any change”對大家的誤導(dǎo)。得到回應(yīng)是1.1中社區(qū)首頁what-is-istio已經(jīng)修改了這部分說明，不再是1.0中說without any changes in service code，而是改為with few or no code changes in service code。提示大家在使用Isito進行調(diào)用鏈埋點時，應(yīng)用程序需要進行適當(dāng)?shù)男薷?。?dāng)然了解了其中原理，做起來也不會太麻煩。
改了個程度輕一點的否定詞，很少幾乎不用修改，還是基本不用改的意思。這也是社區(qū)一貫的觀點。
結(jié)合對Istio調(diào)用鏈的原理的分析和一個典型例子中細(xì)節(jié)字段、流程包括代碼的額解析，再加上和社區(qū)溝通的觀點。得到以下結(jié)論：
Istio的絕大多數(shù)治理能力都是在Sidecar而非應(yīng)用程序中實現(xiàn)，因此是非侵入的；
Istio的調(diào)用鏈埋點邏輯也是在Sidecar代理中完成，對應(yīng)用程序非侵入，但應(yīng)用程序需做適當(dāng)?shù)男薷模磁浜显谡埱箢^上傳遞生成的Trace相關(guān)信息。
華為云Istio服務(wù)網(wǎng)格公測中
在騰訊的場子上只講干貨的技術(shù)，盡量少做廣告。在這里只是用一頁PPT來簡單介紹下華為云當(dāng)前正在公測的Istio服務(wù)網(wǎng)格服務(wù)。
華為云容器引擎CCE的深度集成，一鍵啟用后，即可享受Istio服務(wù)網(wǎng)格的全部治理能力；基于應(yīng)用運行的全景視圖配置管理熔斷、故障注入、負(fù)載均衡等多種智能流量治理功能；內(nèi)置金絲雀、A/B Testing典型灰度發(fā)布流程灰度版本一鍵部署，流量切換一鍵生效；配置式基于流量比例、請求內(nèi)容灰度策略配置，一站式健康、性能、流量監(jiān)控，實現(xiàn)灰度發(fā)布過程量化、智能化、可視化；集成華為云APM，使用調(diào)用鏈、應(yīng)用拓?fù)涞榷喾N手段對應(yīng)用運行進行透視、診斷和管理。
華為云Istio社區(qū)貢獻
華為作為CNCF 基金會的初創(chuàng)會員、白金會員，CNCF / Kubernetes TOC 成員。在Kubernetes社區(qū)貢獻國內(nèi)第一，全球第三，全球貢獻3000+ PR，先后貢獻了集群聯(lián)邦、高級調(diào)度策略、IPVS負(fù)載均衡，容器存儲快照等重要項目。
隨著Istio項目的深入產(chǎn)品化，團隊也積極投入到Istio的社區(qū)貢獻。當(dāng)前社區(qū)貢獻國內(nèi)第一，全球第三。Approver 3席，Member 6席，Contributor 若干。
通過Pilot agent轉(zhuǎn)發(fā)實現(xiàn)HTTP協(xié)議的健康檢查： 針對mTLS enabled環(huán)境，傳統(tǒng)的kubernetes http健康檢查不能工作，實現(xiàn) sidecar轉(zhuǎn)發(fā)功能，以及injector的自動注入。
Istioctl debug功能增強：針對istioctl缺失查詢sidecar中endpoint的能力，增加proxy-config endpoint、proxy-status endpoint命令，提高debug效率。
HTTPRetry API增強： 增加HTTPRetry 配置項RetryOn策略，可以通過此控制sidecar重試。
MCP 配置實現(xiàn)： Pilot支持mesh configuration, 可以與galley等多個實現(xiàn)了MCP協(xié)議的server端交互獲取配置。以此解耦后端注冊中心。
Pilot CPU異常問題解決：1.0.0-snapshot.0 pilot free 狀態(tài)CPU 利用率超過20%，降低到1%以下。
Pilot 服務(wù)數(shù)據(jù)下發(fā)優(yōu)化：緩存service，避免每次push時進行重復(fù)的轉(zhuǎn)換。
Pilot服務(wù)實例查詢優(yōu)化：根據(jù)label selector查詢endpoints（涵蓋95%以上的場景），避免遍歷所有namespace的endpoints。
Pilot 數(shù)據(jù)Push性能優(yōu)化：將原有的串行順序推送配置，更新為并行push，降低配置下發(fā)時延。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
