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

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序定制開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了宣城免費(fèi)建站歡迎大家使用！

引言

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

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

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

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

什么是 Service Mesh?

Service Mesh 誕生

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

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

最難得的是，這么好的一個(gè)概念居然不是從PPT里走出來(lái)的，人家是真的有貨(這讓廣大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版本。對(duì)于Buoyant公司而言，這也許只是無(wú)心插柳的一小步，但卻是云原生領(lǐng)域邁向成熟的一大步。幾年后的今天，Service Mesh 概念早已深入人心，各種生產(chǎn)級(jí)實(shí)現(xiàn)和大規(guī)模實(shí)踐也已遍地開(kāi)花，但請(qǐng)不要忘記這一切背后的功臣、Service Mesh革命先驅(qū)、Buoyant公司CEO —— William Morgan，以及他對(duì)Service Mesh的定義和思考：What's a service mesh? And why do I need one?[2]

Service Mesh 定義

別廢話了，我沒(méi)工夫聽(tīng)你說(shuō)這么多，請(qǐng)用一句話跟我解釋 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.

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

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

Service Mesh 形態(tài)

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

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

右邊是一張更高維和抽象的大圖，可以更形象地理解 Service Mesh 的邏輯形態(tài) —— 想象這就是一個(gè)生產(chǎn)級(jí)的大規(guī)模微服務(wù)集群，其中部署了上百個(gè)服務(wù)實(shí)例以及對(duì)應(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)歷過(guò)那個(gè)單體應(yīng)用為王的時(shí)代。所謂“單體”(Monolithic)，就是把所有組件都塞在同一個(gè)應(yīng)用內(nèi)，因此這些組件天然就緊密聯(lián)系在一起：基于相同技術(shù)棧開(kāi)發(fā)、訪問(wèn)共享的數(shù)據(jù)庫(kù)、共同部署運(yùn)維和擴(kuò)容。同時(shí)，這些組件之間的通訊也趨向于頻繁和耦合 —— 不過(guò)就是一句函數(shù)調(diào)用的事，何樂(lè)而不為。這樣做本身并沒(méi)什么錯(cuò)，畢竟那時(shí)的軟件系統(tǒng)相對(duì)簡(jiǎn)單，可能一個(gè)人寫(xiě)個(gè)兩萬(wàn)行代碼的單體應(yīng)用，就能輕松搞定所有業(yè)務(wù)場(chǎng)景。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Service Mesh 的誕生，徹底解決了上述所有問(wèn)題。聽(tīng)上去很神奇，究竟是如何辦到的呢?簡(jiǎn)單來(lái)說(shuō)，Service Mesh 就是通過(guò) Sidecar模式[3] ，將上述類庫(kù)和框架要干的事情從應(yīng)用中徹底剝離了出來(lái)，并統(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)容來(lái)自于資料搜集整理，僅供參考，更進(jìn)一步學(xué)習(xí)請(qǐng)以最新權(quán)威資料為準(zhǔn)。

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

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

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

Linkerd 簡(jiǎn)介

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

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

Envoy 簡(jiǎn)介

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

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

Istio 簡(jiǎn)介

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)，核?功能包括：前置檢查、配額管理、遙測(cè)報(bào)告。
• Istio-Auth：支持多種粒度的RBAC權(quán)限控制;支持雙向SSL認(rèn)證，包括身份識(shí)別、通訊安全、秘鑰管理。

Istio 組件 - Pilot

Pilot組件是Istio服務(wù)網(wǎng)格中的“領(lǐng)航員”，負(fù)責(zé)管理數(shù)據(jù)平面的流量規(guī)則和服務(wù)發(fā)現(xiàn)。一個(gè)典型的應(yīng)用場(chǎng)景就是灰度發(fā)布(or 金絲雀發(fā)布、藍(lán)綠部署)：開(kāi)發(fā)者通過(guò)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í)各種流量策略(如訪問(wèn)控制、限速)，也負(fù)責(zé)對(duì)流量進(jìn)行觀測(cè)分析(如日志、監(jiān)控、追蹤)。這些能力都是通過(guò)前文提到的Envoy Filter Chain擴(kuò)展機(jī)制實(shí)現(xiàn)：Mixer會(huì)分別在“請(qǐng)求路由前”(Pre-routing)擴(kuò)展點(diǎn)和“請(qǐng)求路由后”(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)問(wèn)題。對(duì)于認(rèn)證，Auth支持服務(wù)之間的雙向SSL認(rèn)證，可以讓通訊的雙方都彼此認(rèn)可對(duì)方的身份;對(duì)于鑒權(quán)，Auth支持流行的RBAC鑒權(quán)模型，可以實(shí)現(xiàn)便捷和細(xì)粒度的“用戶-角色-權(quán)限”多級(jí)訪問(wèn)控制。

Conduit 簡(jiǎn)介

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

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

結(jié)語(yǔ)

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

歡迎各位技術(shù)同路人加入阿里云云原生應(yīng)用研發(fā)平臺(tái)EMAS團(tuán)隊(duì)，我們專注于廣泛的云原生技術(shù)(Backend as a Service、Serverless、DevOps、低代碼平臺(tái)等)，致力于為企業(yè)、開(kāi)發(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

文章標(biāo)題：正確入門ServiceMesh：起源、發(fā)展和現(xiàn)狀
文章地址：http://uogjgqi.cn/article/ccdhjje.html