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

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

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

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

初識Service Mesh

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

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

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

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

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

Sidecar的比喻從何而來？

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

在模式庫中，Sidecar被這樣描述：

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

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

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

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

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

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

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

因為使用客戶端更像一種交付的模式，不容易變更，控制力較差，而Service Mesh則從業(yè)務(wù)進程集成客戶端的方式演進為獨立進程的方式，也就是說，原本的客戶端變成了一個獨立進程。對這個獨立進程升級、運維要比綁在一起強得多。

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

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

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

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

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

先謹慎觀察 未來可期

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

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

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

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

本文參考資料

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

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

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

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

生成海報

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