[[335251]]

Service Mesh早已不是一個(gè)新興的概念，但大家對Service Mesh的探索依然火熱。本文將依次講解Service Mesh的定義(什么是Service Mesh)、起因(為什么需要Service Mesh)和現(xiàn)狀(Service Mesh的主流實(shí)現(xiàn))，希望通過淺顯易懂的介紹，盡量幫助大家更好地理解Service Mesh。

引言

隨著云原生時(shí)代的來臨，微服務(wù)架構(gòu)與容器化部署模式越來越流行，從原來的新潮詞匯慢慢演變成為現(xiàn)代IT企業(yè)的技術(shù)標(biāo)配。曾經(jīng)被認(rèn)為理所當(dāng)然的巨無霸單體應(yīng)用，被擁抱了微服務(wù)的架構(gòu)師們精心拆分成了一個(gè)又一個(gè)小而獨(dú)立的微服務(wù)，接著再被擁抱了容器化的工程師們打包成了自帶依賴的Docker鏡像，最后通過某種神秘的DevOps流水線持續(xù)運(yùn)送到前線 —— 也就是無人不知的 —— 風(fēng)暴降生·谷歌之子·打碎鐐銬者·云時(shí)代操作系統(tǒng)·Kubernetes —— 之中部署和運(yùn)行。

聽上去似乎一切都很美好?顯然不是，這世上永遠(yuǎn)沒有免費(fèi)的午餐。所有美好的東西都會(huì)有它的陰暗面，微服務(wù)也不例外：

• 原來只需要部署和管理單個(gè)應(yīng)用，現(xiàn)在一下裂變成了好幾個(gè)，運(yùn)維管理成本成倍上升。
• 原來各個(gè)模塊之間的交互可以直接走應(yīng)用內(nèi)調(diào)用(進(jìn)程間通信)，現(xiàn)在都給拆分到了不同進(jìn)程甚至節(jié)點(diǎn)上，只能使用復(fù)雜的RPC通訊。

難道辛辛苦苦落地了微服務(wù)，只能一邊在老板面前強(qiáng)撐著“沒問題，一切安好”，另一邊默默忍受著研發(fā)與運(yùn)維的私下抱怨?顯然也不是。對于以“偷懶”著稱的程序員們，辦法總是比困難多。比如上面第1個(gè)問題，云原生所倡導(dǎo)的DevOps和容器化，就是一劑幾乎完美的解藥：通過自動(dòng)化的CI/CD流水線，多應(yīng)用的集成構(gòu)建部署變得更加快捷;通過Docker鏡像和K8s編排，多應(yīng)用的資源調(diào)度運(yùn)維管理也變得不那么痛苦。至于第2個(gè)問題，那就該看本文的主角 —— Service Mesh(服務(wù)網(wǎng)格)，是如何力挽狂瀾，近乎完美地解決微服務(wù)之間的通訊問題了。

什么是 Service Mesh?

Service Mesh 誕生

從概念到落地?不，是從落地到概念。

時(shí)間回到2016年9⽉29⽇，那是一個(gè)即將放假迎來普天同慶的日子(是說我們)。在Buoyant公司內(nèi)部一次關(guān)于微服務(wù)的分享會(huì)上，“Service Mesh” ，這個(gè)接下來幾年占據(jù)各種云原生頭條的 buzz word，就這么被造出來了。不得不說，起名真是門藝術(shù)，Micro-Services -> Service Mesh，多么承前啟后和順其自然啊，光看名字就能很形象地理解這玩意兒所做的事情：把微服務(wù)的各個(gè)service(服務(wù))節(jié)點(diǎn)，用一張mesh(網(wǎng)格)連接起來。就這樣，原本被拆散得七零八落的微服務(wù)們，又被 Service Mesh 這張大網(wǎng)緊密得連接到了一起;即使依然天各一方(進(jìn)程間隔離)，但也找回了當(dāng)年一起擠在單體應(yīng)用內(nèi)抱團(tuán)撒歡的親密感(通信更容易)。

最難得的是，這么好的一個(gè)概念居然不是從PPT里走出來的，人家是真的有貨(這讓廣大PPT創(chuàng)業(yè)者們情何以堪)：2016年1⽉15⽇，Service Mesh的第一個(gè)實(shí)現(xiàn)Linkerd [1]就已經(jīng)完成了初次發(fā)布，緊接著次年1月23日 加入了CNCF，同年4月25日發(fā)布了 1.0版本。對于Buoyant公司而言，這也許只是無心插柳的一小步，但卻是云原生領(lǐng)域邁向成熟的一大步。幾年后的今天，Service Mesh 概念早已深入人心，各種生產(chǎn)級實(shí)現(xiàn)和大規(guī)模實(shí)踐也已遍地開花，但請不要忘記這一切背后的功臣、Service Mesh革命先驅(qū)、Buoyant公司CEO —— William Morgan，以及他對Service Mesh的定義和思考：What's a service mesh? And why do I need one?[2]

Service Mesh 定義

別廢話了，我沒工夫聽你說這么多，請用一句話跟我解釋 Service Mesh 是什么。

好的。A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

這就是上面那位又帥又能寫的CEO，對Service Mesh的權(quán)威定義。我把其中一些重點(diǎn)詞匯做了高亮：

• “dedicated infrastructure layer”：Service Mesh 不是用來解決業(yè)務(wù)領(lǐng)域問題的，而是一層專門的基礎(chǔ)設(shè)施(中間件)。
• “service-to-service communication”：Service Mesh 的定位很簡單也很清晰，就是用來處理服務(wù)與服務(wù)之間的通訊。
• “reliable delivery of requests”：服務(wù)間通訊為什么需要特殊處理?因?yàn)榫W(wǎng)絡(luò)是不可靠的，Service Mesh 的愿景就是讓服務(wù)間的請求傳遞變得可靠。
• “cloud native application”：Service Mesh 從一開始就是為現(xiàn)代化的云原生應(yīng)用而生，瞄準(zhǔn)了未來的技術(shù)發(fā)展趨勢。
• “network proxies”：具體 Service Mesh 應(yīng)該怎么實(shí)現(xiàn)?典型方式都是通過一組輕量級的網(wǎng)絡(luò)代理，在應(yīng)用無感知的情況下偷偷就把這事給干了。
• “deployed alongside application code”：這些網(wǎng)絡(luò)代理一定是跟應(yīng)用部署在一起，一對一近距離貼心服務(wù)(比房產(chǎn)中介專一得多);否則，如果應(yīng)用與代理之間也還是遠(yuǎn)程不靠譜通訊，這事兒就沒完了。

Service Mesh 形態(tài)

想致富，先修路;但大馬路可不是給馬走的，是給更現(xiàn)代化的汽車。

左邊這張圖是Linkerd的部署示意圖，其中每個(gè)微服務(wù)所處的主機(jī)(host)或容器組(pod)中都會(huì)部署一個(gè)Linkerd代理軟件，用于代理微服務(wù)應(yīng)用實(shí)例之間的RPC調(diào)用。對于應(yīng)用而言，這一切都是無感知的：它還是照常發(fā)起自己的RPC調(diào)用，只是不再需要關(guān)心對端服務(wù)方的地址，因?yàn)榉?wù)發(fā)現(xiàn)都由代理節(jié)點(diǎn)給cover了。

右邊是一張更高維和抽象的大圖，可以更形象地理解 Service Mesh 的邏輯形態(tài) —— 想象這就是一個(gè)生產(chǎn)級的大規(guī)模微服務(wù)集群，其中部署了上百個(gè)服務(wù)實(shí)例以及對應(yīng)的 Service Mesh 代理節(jié)點(diǎn);所有微服務(wù)之間的通訊都會(huì)流經(jīng)這些密密麻麻的代理節(jié)點(diǎn)，它們共同組成了一張川流不息的現(xiàn)代化交通網(wǎng)格。

為什么需要 Service Mesh ?

微服務(wù)的崛起

The Big Bang：大爆炸后的混亂之治。

大多數(shù)人都曾經(jīng)歷過那個(gè)單體應(yīng)用為王的時(shí)代。所謂“單體”(Monolithic)，就是把所有組件都塞在同一個(gè)應(yīng)用內(nèi)，因此這些組件天然就緊密聯(lián)系在一起：基于相同技術(shù)棧開發(fā)、訪問共享的數(shù)據(jù)庫、共同部署運(yùn)維和擴(kuò)容。同時(shí)，這些組件之間的通訊也趨向于頻繁和耦合 —— 不過就是一句函數(shù)調(diào)用的事，何樂而不為。這樣做本身并沒什么錯(cuò)，畢竟那時(shí)的軟件系統(tǒng)相對簡單，可能一個(gè)人寫個(gè)兩萬行代碼的單體應(yīng)用，就能輕松搞定所有業(yè)務(wù)場景。

天下大事，分久必合，合久必分?，F(xiàn)代化軟件系統(tǒng)的復(fù)雜度不斷提升，協(xié)作人數(shù)也越來越多，單體應(yīng)用的固有局限性開始暴露。就仿佛宇宙大爆炸前的那個(gè)奇點(diǎn)，單體應(yīng)用開始加速膨脹，最終在幾年前達(dá)到了臨界點(diǎn)，然后“砰”的一聲就炸開了。就這樣，微服務(wù)時(shí)代王者降臨，讓軟件開發(fā)重新變得“小而美”：

• 單職責(zé)：拆分后的單個(gè)微服務(wù)，通常只負(fù)責(zé)單個(gè)高內(nèi)聚自閉環(huán)功能，因此很易于開發(fā)、理解和維護(hù)。
• 架構(gòu)靈活：不同微服務(wù)應(yīng)用之間在技術(shù)選型層面幾乎是獨(dú)立的，可以⾃由選擇最適合的技術(shù)棧。
• 部署隔離：相比巨無霸單體應(yīng)用，單個(gè)微服務(wù)應(yīng)用的代碼和產(chǎn)物體積大大減少，更容易持續(xù)集成和快速部署;同時(shí)，通過進(jìn)程級別的隔離，也不再像單體應(yīng)用一樣只能同生共死，故障隔離效果顯著提升。
• 獨(dú)擴(kuò)展：單體應(yīng)用時(shí)代，某個(gè)模塊如果存在資源瓶頸(e.g. CPU/內(nèi)存)，只能跟隨整個(gè)應(yīng)用一起擴(kuò)容，白白浪費(fèi)很多資源。微服務(wù)化后，擴(kuò)展的粒度細(xì)化到了微服務(wù)級別，可以更精確地按需獨(dú)立擴(kuò)展。

但顯然，微服務(wù)也不是銀彈。大爆炸雖然打破了單體應(yīng)用的獨(dú)裁統(tǒng)治，但那一聲聲炸裂之后的微服務(wù)新宇宙，顯然也不會(huì)立即就塵埃落定，而是需要經(jīng)歷很長一段時(shí)間的混亂之治。適應(yīng)了單體時(shí)代的開發(fā)者們，被迫需要擁抱微服務(wù)所帶來的一系列變化。其中最大的變化，就是服務(wù)間通訊：

如何找到服務(wù)的提供⽅?

微服務(wù)通訊必須走遠(yuǎn)程過程調(diào)用(HTTP/REST本質(zhì)上也屬于RPC)，當(dāng)其中一個(gè)應(yīng)用需要消費(fèi)另一個(gè)應(yīng)用的服務(wù)時(shí)，無法再像單體應(yīng)用一樣通過簡單的進(jìn)程內(nèi)機(jī)制(e.g. Spring的依賴注入)就能獲取到服務(wù)實(shí)例;你甚至都不知道有沒有這個(gè)服務(wù)方。

如何保證遠(yuǎn)程調(diào)⽤的可靠性?

既然是RPC，那必然要走IP網(wǎng)絡(luò)，而我們都知道網(wǎng)絡(luò)(相比計(jì)算和存儲(chǔ))是軟件世界里最不可靠的東西。雖然有TCP這種可靠傳輸協(xié)議，但頻繁丟包、交換機(jī)故障甚至電纜被挖斷也常有發(fā)生;即使網(wǎng)絡(luò)是好的，如果對方機(jī)器宕機(jī)了，或者進(jìn)程負(fù)載過高不響應(yīng)呢?

如何降低服務(wù)調(diào)⽤的延遲?

網(wǎng)絡(luò)不只是不可靠，還有延遲的問題。雖然相同系統(tǒng)內(nèi)的微服務(wù)應(yīng)用通常都部署在一起，同機(jī)房內(nèi)調(diào)用延遲很小;但對于較復(fù)雜的業(yè)務(wù)鏈路，很可能一次業(yè)務(wù)訪問就會(huì)包括數(shù)十次RPC調(diào)用，累積起來的延遲就很可觀了。

如何保證服務(wù)調(diào)⽤的安全性?

網(wǎng)絡(luò)不只是不可靠和有延遲，還是不安全的?；ヂ?lián)網(wǎng)時(shí)代，你永遠(yuǎn)不知道屏幕對面坐的是人還是狗;同樣，微服務(wù)間通訊時(shí)，如果直接走裸的通訊協(xié)議，你也永遠(yuǎn)不知道對端是否真的就是自己人，或者傳輸?shù)臋C(jī)密信息是否有被中間人偷聽。

服務(wù)通訊：石器時(shí)代

毛主席說：自己動(dòng)手，豐衣足食。

為了解決上述微服務(wù)引入的問題，最早那批吃螃蟹的工程師們，開始了各自的造輪子之旅：

• 服務(wù)發(fā)現(xiàn)(Service Discovery)：解決“我想調(diào)用你，如何找到你”的問題。
• 服務(wù)熔斷(Circuit Breaker)：緩解服務(wù)之間依賴的不可靠問題。
• 負(fù)載均衡(Load Balancing)：通過均勻分配流量，讓請求處理更加及時(shí)。
• 安全通訊：包括協(xié)議加密(TLS)、身份認(rèn)證(證書/簽名)、訪問鑒權(quán)(RBAC)等。

用自己的代碼解決問題，這確實(shí)是程序員們能干出來的事，沒毛病。But，時(shí)間都去哪了?

• 重復(fù)造輪子：需要編寫和維護(hù)⼤量非功能性代碼，如何集中精力專注業(yè)務(wù)創(chuàng)新?
• 與業(yè)務(wù)耦合：服務(wù)通訊邏輯與業(yè)務(wù)代碼邏輯混在一起，動(dòng)不動(dòng)還會(huì)遇到點(diǎn)匪夷所思的分布式bug。

服務(wù)通訊：摩登時(shí)代

社會(huì)主義精神：共享和復(fù)用。

更有思想覺悟的那批工程師們坐不住了：你們這是違背了共享和復(fù)用原則，對不起GNU那幫祖師爺!于是，各種高質(zhì)量、標(biāo)準(zhǔn)化、期望能大一統(tǒng)的精品輪子們應(yīng)運(yùn)而生，包括 Apache Dubbo(手動(dòng)置頂)、Spring Cloud、Netflix OSS、gRPC 等等等。

這些可復(fù)用的類庫和框架，確確實(shí)實(shí)帶來了質(zhì)量和效率上的大幅提升，但是足夠好使了嗎?Not enough：

• 并非完全透明：程序員們?nèi)匀恍枰_理解和使⽤這些庫，上手成本和出錯(cuò)概率依然很高。
• 限制技術(shù)選擇：使用這些技術(shù)后，應(yīng)用很容易就會(huì)被對應(yīng)的語⾔和框架強(qiáng)綁定(vendor-lock)。
• 維護(hù)成本高：庫版本升級，需要牽連應(yīng)⽤一起重新構(gòu)建和部署;麻煩不說，還要祈禱別出故障。

服務(wù)通訊：新⽣代

Service Mesh：我只是一個(gè)搬運(yùn)工而已。

Service Mesh 的誕生，徹底解決了上述所有問題。聽上去很神奇，究竟是如何辦到的呢?簡單來說，Service Mesh 就是通過 Sidecar模式[3] ，將上述類庫和框架要干的事情從應(yīng)用中徹底剝離了出來，并統(tǒng)一下沉到了基礎(chǔ)設(shè)施層。這是一種什么思想?這是一種古老操作系統(tǒng)中早就有了的抽象和分層思想(應(yīng)用程序并不需要關(guān)心網(wǎng)絡(luò)協(xié)議棧)，也是一種現(xiàn)代云計(jì)算平臺(tái)自底向上逐步托管的軟件服務(wù)化思想(IaaS -> CaaS -> PaaS -> SaaS)。

上述幾張 Service Mesh 的演進(jìn)圖，參考自 Service Mesh Pattern[4] 一文。

Service Mesh 主流實(shí)現(xiàn)

注：以下內(nèi)容來自于資料搜集整理，僅供參考，更進(jìn)一步學(xué)習(xí)請以最新權(quán)威資料為準(zhǔn)。

主流實(shí)現(xiàn)概覽

Service Mesh 的主流實(shí)現(xiàn)包括：

• Linkerd：背后公司是Buoyant，開發(fā)語⾔使用Scala，2016年1⽉15日初次發(fā)布，2017年1⽉23日加入CNCF，2018年5⽉1⽇發(fā)布1.4.0版本。
• Envoy：背后公司是Lyft，開發(fā)語言使用C++ 11，2016年9月13日初次發(fā)布，2017年9⽉14日加⼊CNCF，2018年3月21日發(fā)布1.6.0版本。
• Istio：背后公司是Google和IBM，開發(fā)語言使用Go，2017年5⽉月10日初次發(fā)布，2018年3⽉31日發(fā)布0.7.1版本。
• Conduit：背后公司也是Buoyant，開發(fā)語言使用Rust和Go，2017年12月5日初次發(fā)布，2018年4⽉27日發(fā)布0.4.1版本。

Linkerd 簡介

Linkerd的核心組件就是一個(gè)服務(wù)代理，因此只要理清它的請求處理流程，就掌握了它的核心邏輯：

• 動(dòng)態(tài)路由：根據(jù)上游服務(wù)請求參數(shù)，確定下游目標(biāo)服務(wù);除了常規(guī)的服務(wù)路由策略，Linkerd還可以通過這一層動(dòng)態(tài)路由能力，支持灰度發(fā)布、A/B測試、環(huán)境隔離等非常有價(jià)值的場景。
• 服務(wù)發(fā)現(xiàn)：確定目標(biāo)服務(wù)后，下一步就是獲取對應(yīng)的實(shí)例的地址列表(e.g. 查詢service registry)。
• 負(fù)載均衡：如果列表中有多個(gè)地址，Linkerd會(huì)通過負(fù)載均衡算法(e.g. Least Loaded、Peak EWMA)選擇其中⼀個(gè)合適的低延遲實(shí)例。
• 執(zhí)行請求：發(fā)送請求到上一步所選擇的實(shí)例，并記錄延遲和響應(yīng)結(jié)果。
• 重試處理：如果請求未響應(yīng)，則選擇另⼀個(gè)實(shí)例重試(前提：Linkerd知道該請求是冪等的)。
• 熔斷處理：如果發(fā)往某個(gè)實(shí)例的請求經(jīng)常失敗，則主動(dòng)從地址列表中剔除該實(shí)例。
• 超時(shí)處理：如果請求超期(在給定的deadline時(shí)間點(diǎn)之前仍未返回)，則主動(dòng)返回失敗響應(yīng)。
• 可觀測性：Linkerd會(huì)持續(xù)收集和上報(bào)上述各種行為數(shù)據(jù)，包括Metrics和Tracing。

Envoy 簡介

Envoy是一個(gè)高性能的Service Mesh軟件，主要包含如下特性：

• 高性能：基于本地代碼(C++ 11)實(shí)現(xiàn);相比之下，Linkerd是基于Scala編寫，肯定要慢不少。
• 可擴(kuò)展：L4和L7層代理功能均基于可插拔的 Filter Chain 機(jī)制(類比 netfilter、servlet filter)。
• 協(xié)議升級：支持雙向、透明的 HTTP/1 to HTTP/2 代理能力。
• 其他能力：服務(wù)發(fā)現(xiàn)(符合最終一致性)、負(fù)載均衡(支持區(qū)域感知)、穩(wěn)定性(重試、超時(shí)、熔斷、限速、異常檢測)、可觀測性(統(tǒng)計(jì)/日志/追蹤)、易于調(diào)試等。

Istio 簡介

Istio是一個(gè)管控/數(shù)據(jù)平面分離的完整Service Mesh套件，包含如下組件：

• Envoy：構(gòu)成數(shù)據(jù)平⾯(其他組件共同構(gòu)成控制平⾯);可被替換為其他代理(e.g. Linkerd, nginMesh)。
• Pilot：負(fù)責(zé)流量管理(Traffic Management)，提供平臺(tái)獨(dú)⽴的服務(wù)模型定義、API以及實(shí)現(xiàn)。
• Mixer：負(fù)責(zé)策略與控制(Policies & Controls)，核⼼功能包括：前置檢查、配額管理、遙測報(bào)告。
• Istio-Auth：支持多種粒度的RBAC權(quán)限控制;支持雙向SSL認(rèn)證，包括身份識別、通訊安全、秘鑰管理。

Istio 組件 - Pilot

Pilot組件是Istio服務(wù)網(wǎng)格中的“領(lǐng)航員”，負(fù)責(zé)管理數(shù)據(jù)平面的流量規(guī)則和服務(wù)發(fā)現(xiàn)。一個(gè)典型的應(yīng)用場景就是灰度發(fā)布(or 金絲雀發(fā)布、藍(lán)綠部署)：開發(fā)者通過Pilot提供的規(guī)則API，下發(fā)流量路由規(guī)則到數(shù)據(jù)平面的Envoy代理，從而實(shí)現(xiàn)精準(zhǔn)的多版本流量分配(e.g. 將1%的流量分配到新版本服務(wù))。

Istio 組件 - Mixer

Mixer組件是Istio服務(wù)網(wǎng)格中的“調(diào)音師”，既負(fù)責(zé)落實(shí)各種流量策略(如訪問控制、限速)，也負(fù)責(zé)對流量進(jìn)行觀測分析(如日志、監(jiān)控、追蹤)。這些能力都是通過前文提到的Envoy Filter Chain擴(kuò)展機(jī)制實(shí)現(xiàn)：Mixer會(huì)分別在“請求路由前”(Pre-routing)擴(kuò)展點(diǎn)和“請求路由后”(Post-routing)擴(kuò)展點(diǎn)掛載自己的Filter實(shí)現(xiàn)。

Istio 組件 - Auth

Auth組件是Istio服務(wù)網(wǎng)格中的“安全員”，負(fù)責(zé)處理服務(wù)節(jié)點(diǎn)之間通信的認(rèn)證(Authentification)和鑒權(quán)(Authorization)問題。對于認(rèn)證，Auth支持服務(wù)之間的雙向SSL認(rèn)證，可以讓通訊的雙方都彼此認(rèn)可對方的身份;對于鑒權(quán)，Auth支持流行的RBAC鑒權(quán)模型，可以實(shí)現(xiàn)便捷和細(xì)粒度的“用戶-角色-權(quán)限”多級訪問控制。

Conduit 簡介

Conduit是由Buoyant公司出品的下一代 Service Mesh。作為Istio的挑戰(zhàn)者，Conduit的整體架構(gòu)與Istio類似也明確區(qū)分了管控平面和數(shù)據(jù)平面，但同時(shí)它還具備如下關(guān)鍵特性：

• 輕量快速：Conduit的數(shù)據(jù)平面是基于原生的Rust語言編寫，非常輕量、快速和安全(Rust相比C/C++的最大改進(jìn)點(diǎn)就是安全性)。單個(gè)代理的實(shí)際內(nèi)存消耗(RSS)小于10mb，延遲的p99分位點(diǎn)小于1ms，基本相當(dāng)于能為應(yīng)用程序提供免費(fèi)(無額外開銷)的Service Mesh功能。
• 安全保障：Conduit構(gòu)建之初就考慮了云原生環(huán)境的安全性，包括Rust語言內(nèi)存安全性、默認(rèn)TLS加密等。
• 端到端可見性：Conduit可以自動(dòng)測量和聚合服務(wù)的成功率、延遲與請求容量數(shù)據(jù)，讓開發(fā)者在無需變更應(yīng)用代碼就能獲取到服務(wù)的完整行為視圖。
• Kubernetes增強(qiáng)：Conduit為K8s集群添加了可靠性、可見性和安全性，同時(shí)給予了開發(fā)者對自己應(yīng)用程序運(yùn)行時(shí)行為的完全控制。

結(jié)語

本文從云原生時(shí)代所面臨的微服務(wù)通訊問題入手，依次介紹了Service Mesh的起源、發(fā)展和現(xiàn)狀，希望能幫助讀者建立一個(gè)初步的理解和認(rèn)知。當(dāng)然，實(shí)踐出真知，與其臨淵羨魚(眼饞Service Mesh的技術(shù)紅利)，不如退而結(jié)網(wǎng)(自己動(dòng)手織一張Service網(wǎng)格)。手頭的工作沒有可實(shí)踐的業(yè)務(wù)場景?沒關(guān)系，我這有：

歡迎各位技術(shù)同路人加入阿里云云原生應(yīng)用研發(fā)平臺(tái)EMAS團(tuán)隊(duì)，我們專注于廣泛的云原生技術(shù)(Backend as a Service、Serverless、DevOps、低代碼平臺(tái)等)，致力于為企業(yè)、開發(fā)者提供一站式的應(yīng)用研發(fā)管理服務(wù)，內(nèi)推直達(dá)郵箱：pengqun.pq # alibaba-inc.com，有信必回。

相關(guān)鏈接

[1]https://github.com/linkerd/linkerd

[2]https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

[3]https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

[4]https://philcalcado.com/2017/08/03/pattern_service_mesh.html