架構(gòu)演進(jìn)兩大方向，一個(gè)是Serverless，另一個(gè)是什么？

原標(biāo)題：架構(gòu)演進(jìn)兩大方向，一個(gè)是Serverless，另一個(gè)是什么？

在架構(gòu)領(lǐng)域，Service Mesh和Serverless一樣，是非常重要的一個(gè)方向。

這么說(shuō)吧，掌握了Service Mesh，你就選擇了一條未來(lái)技術(shù)框架的道路。至于這條道路會(huì)怎么發(fā)展，還要再觀察。這篇文章將解釋什么是Service Mesh，為什么需要Service Mesh，以及Service Mesh的現(xiàn)狀如何。

初識(shí)Service Mesh

Service Mesh很新，最早在2016年9月29日由開(kāi)發(fā)Linkerd的Buoyant公司提出。

時(shí)間回到2016年10月，Alex Leong開(kāi)始在Buoyant公司的官方博客中連載一系列關(guān)于“A Service Mesh for Kubernetes”的文章。 隨著2017年Linkerd加入CNCF，Service Mesh開(kāi)始大規(guī)模出現(xiàn)在各個(gè)技術(shù)論壇上，Service Mesh在國(guó)內(nèi)被翻譯為“服務(wù)網(wǎng)格” 。

那么到底什么是Service Mesh呢？目前比較公認(rèn)的定義是Buoyant的CEO William Morgan在博客中給出的具體描述，如下：

現(xiàn)在，Service Mesh逐步發(fā)展為一個(gè)獨(dú)立的基礎(chǔ)設(shè)施層。

在Cloud Native架構(gòu)下，單個(gè)應(yīng)用程序可能由數(shù)百個(gè)服務(wù)組成；每個(gè)服務(wù)可能有數(shù)千個(gè)實(shí)例；并且這些實(shí)例中的每一個(gè)實(shí)例都可能處于不斷變化的狀態(tài)，因?yàn)樗鼈兪怯芍T如Kubernetes之類的資源調(diào)度系統(tǒng)動(dòng)態(tài)調(diào)度的。這個(gè)世界中的服務(wù)通信不僅非常復(fù)雜，而且是運(yùn)行時(shí)的普遍行為之一，管理它對(duì)于確保端到端的性能和可靠性至關(guān)重要。

Sidecar的比喻從何而來(lái)？

業(yè)內(nèi)也有類似“Sidecar”的說(shuō)法。這個(gè)概念很形象，就是我們以前在戰(zhàn)爭(zhēng)影片中看到的那種挎斗車。

在模式庫(kù)中，Sidecar被這樣描述：

將應(yīng)用程序的組件部署到單獨(dú)的進(jìn)程或容器中以提供隔離和封裝。這種模式還可以使應(yīng)用程序由異構(gòu)組件和技術(shù)組成。

這種模式被命名為Sidecar，因?yàn)樗愃朴谶B接到摩托車的輔助車。在該模式中，輔助車被附加到父應(yīng)用程序并為應(yīng)用程序提供支持功能。輔助車也與父應(yīng)用程序共享相同的生命周期，與父進(jìn)程一起被創(chuàng)建和推出。

解釋了這么多，一句話來(lái)說(shuō)的話，那就是：Service Mesh幫助應(yīng)用程序在海量服務(wù)、復(fù)雜的架構(gòu)和網(wǎng)絡(luò)中建立穩(wěn)定的通信機(jī)制，業(yè)務(wù)所有的流量都轉(zhuǎn)發(fā)到Service Mesh的代理服務(wù)中。 不僅如此，Service Mesh還承擔(dān)了微服務(wù)框架所有的功能，包括服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、熔斷限流、認(rèn)證鑒權(quán)、緩存加速等。

不同的是，Service Mesh強(qiáng)調(diào)的是通過(guò)獨(dú)立的進(jìn)程代理的方式，除此之外，還承擔(dān)了上報(bào)日志、監(jiān)控的責(zé)任。Service Mesh架構(gòu)如下。

輕量、自治促進(jìn)不斷發(fā)展

Service Mesh的出現(xiàn)是由微服務(wù)架構(gòu)推動(dòng)的，隨著一個(gè)應(yīng)用被拆分為幾百個(gè)甚至幾萬(wàn)個(gè)應(yīng)用，服務(wù)治理面臨巨大的挑戰(zhàn)。這個(gè)時(shí)候，微服務(wù)框架出現(xiàn)，例如，F(xiàn)inagle、Dubbo、SpringCloud、Netflix OSS等。這些框架都是基于客戶端負(fù)載均衡直連的方式，此方案的優(yōu)勢(shì)是性能高、應(yīng)用性好，如Spring Cloud。

歸根結(jié)底，在微服務(wù)架構(gòu)中，我們要解決的問(wèn)題是，讓開(kāi)發(fā)人員感覺(jué)不到微服務(wù)之間的通信。當(dāng)服務(wù)數(shù)量越來(lái)越多，升級(jí)微服務(wù)框架變得越來(lái)越復(fù)雜的時(shí)候，你不可能要求微服務(wù)框架一直不變，而且是沒(méi)有bug的。在技術(shù)更新如此之快的年代，就更不可能了。 因此，微服務(wù)框架的部分功能開(kāi)始逐步向服務(wù)端移動(dòng)，希望客戶端可以盡量“薄”，但是客戶端不可能無(wú)限制的“薄”，剩余部分仍然比較“厚”。

因?yàn)槭褂每蛻舳烁褚环N交付的模式，不容易變更，控制力較差，而Service Mesh則從業(yè)務(wù)進(jìn)程集成客戶端的方式演進(jìn)為獨(dú)立進(jìn)程的方式，也就是說(shuō)，原本的客戶端變成了一個(gè)獨(dú)立進(jìn)程。對(duì)這個(gè)獨(dú)立進(jìn)程升級(jí)、運(yùn)維要比綁在一起強(qiáng)得多。

微服務(wù)架構(gòu)更強(qiáng)調(diào)去中心化、獨(dú)立自治、跨語(yǔ)言，但是通常微服務(wù)框架限制了這一點(diǎn)，不可能為每種語(yǔ)言都實(shí)現(xiàn)一種框架，要么都用一種語(yǔ)言，要么實(shí)現(xiàn)多種語(yǔ)言的框架。而Service Mesh通過(guò)獨(dú)立進(jìn)程的方式進(jìn)行了隔離，可以低成本實(shí)現(xiàn)跨語(yǔ)言。 隨著Docker及Kubernetes的崛起，微服務(wù)的部署模式開(kāi)始發(fā)生轉(zhuǎn)變，越來(lái)越趨向于輕量級(jí)，越來(lái)越強(qiáng)調(diào)隔離自治。每個(gè)服務(wù)獨(dú)立占用一個(gè)容器，將服務(wù)、依賴包、操作系統(tǒng)、監(jiān)控運(yùn)維所需的代理打包成一個(gè)鏡像。這種模式促成了Service Mesh的發(fā)展，讓Service Mesh實(shí)現(xiàn)起來(lái)更容易。否則開(kāi)發(fā)人員需要額外維護(hù)Service Mesh進(jìn)程，就非常麻煩了。

主流框架的弊病和優(yōu)勢(shì)

目前Service Mesh的框架如雨后春筍般快速涌現(xiàn)，以下幾個(gè)框架是目前為止被提到次數(shù)最多的。

先驅(qū)者如Linkerd，被譽(yù)為業(yè)界第一個(gè)Service Mesh項(xiàng)目，但由于很多功能被后續(xù)框架所取代，發(fā)展有限。現(xiàn)在最流行的是Envoy，它在性能和資源消耗上表現(xiàn)得非常出色，被Istio收編之后， 專注于數(shù)據(jù)平面。最值得注意的是Istio，因?yàn)樗谋澈笫荊oogle和IBM。從0.3版本開(kāi)始支持非Kubernetes平臺(tái)，并可以獨(dú)立運(yùn)行。 當(dāng)然業(yè)內(nèi)還有其他一些框架，由于暫時(shí)沒(méi)有投入到生產(chǎn)環(huán)境，進(jìn)展有限，可以關(guān)注一下，比如Conduit 、nginMesh等。

就拿Istio來(lái)說(shuō)，雖然它的架構(gòu)思想被很多人認(rèn)同，功能也很多，但是Istio的問(wèn)題仍然較多，可用性較差，幾乎沒(méi)有生產(chǎn)級(jí)的案例。有點(diǎn)像當(dāng)初Kubernetes剛剛研發(fā)出來(lái)的感覺(jué)，也許隨著技術(shù)的不斷發(fā)展會(huì)成為Service Mesh的未來(lái)，畢竟當(dāng)前很多公司都在跟隨這個(gè)框架。

先謹(jǐn)慎觀察 未來(lái)可期

實(shí)際上，如果在一個(gè)小公司，Service Mesh的優(yōu)勢(shì)并不是十分明顯。例如小公司很少會(huì)考慮采用多語(yǔ)言，因?yàn)槎嘁环N語(yǔ)言就意味著要花費(fèi)額外的精力進(jìn)行維護(hù)，所以到目前為止，大多數(shù)公司在后端只使用一兩種語(yǔ)言。

另外，微服務(wù)框架相對(duì)來(lái)說(shuō)比較穩(wěn)定，就如同Spring Framework一樣，不會(huì)輕易進(jìn)行不兼容的升級(jí)，只要保持好節(jié)奏，問(wèn)題不會(huì)太多。因此，像Netflix這樣的公司，基本上還是沿用類似Spring Cloud模式的。

Service Mesh對(duì)業(yè)務(wù)開(kāi)發(fā)人員友好，但是基礎(chǔ)設(shè)施層的研發(fā)會(huì)更復(fù)雜，需要依賴更多的服務(wù)、組件，否則將帶來(lái)極大的架構(gòu)、運(yùn)維復(fù)雜度。對(duì)于很多公司來(lái)說(shuō)，門(mén)檻稍高，且需要投入成本。 百度內(nèi)部業(yè)務(wù)也很早就開(kāi)始了基于Service Mesh思想的微服務(wù)實(shí)踐，并自研了BMesh框架，大大降低了Service Mesh的實(shí)施和維護(hù)成本，并解決其自身的性能問(wèn)題。基于這些內(nèi)部實(shí)踐，百度智能云CNAP產(chǎn)品目前已經(jīng)邀測(cè)推出了非侵入式微服務(wù)解決方案，為客戶提供可商用的基于Service Mesh的微服務(wù)監(jiān)控、追蹤和治理平臺(tái)。

目前來(lái)看，在沒(méi)有成熟起來(lái)以前，Service Mesh并不具備壓倒性的優(yōu)勢(shì)。但未來(lái)隨著微服務(wù)的進(jìn)一步快速普及，Service Mesh作為重要的架構(gòu)演進(jìn)方向值得關(guān)注。

本文參考資料

百度智能云官網(wǎng)：https://cloud.baidu.com/product/cnap.html

CNCF官網(wǎng)：https://www.cncf.io/

《云原生基礎(chǔ)架構(gòu)》，機(jī)械工業(yè)出版社，2018年9月第一版

《持續(xù)演進(jìn)的Cloud Native 云原生架構(gòu)下微服務(wù)最佳實(shí)踐》，電子工業(yè)出版社，2018年10月第一版

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。