3.Service Mesh

隨著服務(wù)框架內(nèi)功能的日益增多，跨語言的基礎(chǔ)功能復(fù)用變得十分困難，這也就意味著微服務(wù)的開發(fā)者被綁定在某種特定語言上，從而違背了微服務(wù)的敏捷迭代原則。2016年出現(xiàn)了新的微服務(wù)架構(gòu)——Service Mesh（服務(wù)網(wǎng)格），原來被模塊化到服務(wù)框架里的微服務(wù)基礎(chǔ)能力，被進(jìn)一步從一個(gè)SDK演進(jìn)成為一個(gè)獨(dú)立進(jìn)程——Sidecar。這個(gè)變化使得多語言支持問題得以徹底解決，微服務(wù)基礎(chǔ)能力演進(jìn)和業(yè)務(wù)邏輯迭代徹底解耦。這種架構(gòu)就是云原生時(shí)代的微服務(wù)架構(gòu)——Cloud Native Microservices，Sidecar進(jìn)程開始接管微服務(wù)應(yīng)用之間的流量，承載了服務(wù)框架的功能，包括服務(wù)發(fā)現(xiàn)、調(diào)用容錯(cuò)以及豐富的服務(wù)治理功能，例如權(quán)重路由、灰度路由、流量重放、服務(wù)偽裝等。

Service Mesh是分布式應(yīng)用在微服務(wù)架構(gòu)紙上發(fā)展起來的新技術(shù)，旨在將微服務(wù)之間的連接、安全、流量控制和可觀測等通用功能下陳偉平臺(tái)基礎(chǔ)設(shè)施，實(shí)現(xiàn)應(yīng)用與平臺(tái)基礎(chǔ)設(shè)施的解耦。這個(gè)解耦意味著開發(fā)者無須關(guān)注微服務(wù)相關(guān)治理問題，而是聚焦于業(yè)務(wù)邏輯本身，提高了應(yīng)用開發(fā)效率，加速了業(yè)務(wù)探索和創(chuàng)新。換句話說，因?yàn)榇罅糠枪δ苄缘拇a實(shí)現(xiàn)從業(yè)務(wù)進(jìn)程剝離到另外的進(jìn)程中，Service Mesh以無侵入的方式實(shí)現(xiàn)了應(yīng)用輕量化。Service Mesh的典型架構(gòu)如下圖所示。

在上圖中,Service A調(diào)用Service B的所有請求都被其下的Proxy（在Envoy中是Sidecar）截獲，代理ServiceA完成到ServiceB的服務(wù)發(fā)現(xiàn)、熔斷、限流等策略，而這些策略的總控是在控制平面上配置的。

從架構(gòu)上看，Istio可以運(yùn)行在虛擬機(jī)或容器中，Istio的主要組件包括Pilot（服務(wù)發(fā)現(xiàn)、流量管理）、Galley（注冊管理）、Mixer（訪問控制、可觀測性）、Gitadel（終端用戶認(rèn)證、流量加密）。整個(gè)服務(wù)網(wǎng)格關(guān)注鏈接和流量控制、可觀測性、安全和可運(yùn)維性。相比較來說，雖然服務(wù)網(wǎng)格增加了4個(gè)IPC通信的成本，但隨著軟硬件能力的提升，并不會(huì)給整體調(diào)用的延遲帶來顯著的影響，特別是對于百毫秒級(jí)別的業(yè)務(wù)調(diào)用而言，可以控制在2%以內(nèi)。此外，服務(wù)化的應(yīng)用并沒有做任何改造，就獲得了強(qiáng)大的流量控制、服務(wù)治理、可觀測性、“4個(gè)9”以上的高可用性、容災(zāi)和安全等能力，再加上業(yè)務(wù)的橫向擴(kuò)展能力，整體收益仍然是遠(yuǎn)大于額外IPC通信支出的。

在服務(wù)網(wǎng)格的技術(shù)發(fā)展上，數(shù)據(jù)平面與控制平面之間的協(xié)議標(biāo)準(zhǔn)化是必然趨勢。大體上，Service Mesh的技術(shù)發(fā)展圍繞著“事實(shí)標(biāo)準(zhǔn)”來展開——共建各云廠商共同采納的開源軟件。

Conduit作為K8s的超輕量級(jí)Service Mesh，其目標(biāo)是成為最快、最輕、最簡單最安全的Service Mesh。它使用Rust構(gòu)架了快速、安全的數(shù)據(jù)平面，用Go開發(fā)了簡單。強(qiáng)大的控制平面，總體設(shè)計(jì)圍繞著性能、安全性和可用性進(jìn)行。它能透明地管理服務(wù)之間的通信，提供可觀測性，可靠性、安全性和彈性的支持。數(shù)據(jù)平面時(shí)應(yīng)用代碼之外運(yùn)行的輕量級(jí)代理，控制平面是一個(gè)高可用的控制器，Conduit的設(shè)計(jì)更傾向于K8s中的低資源部署。