Categories
程式開發

架構演進的兩大方向,一個是Serverless,另一個是什麼?


《沉寂多年,無服務器爆發,其硬核是什麼? 》一文中,我們就什麼是無服務器技術,它是如何發展的,它的優點、缺點是什麼,對企業的價值在哪裡進行了梳理。本文講講Service Mesh。在架構領域,Service Mesh和Serverless一樣,是非常重要的一個方向。

這麼說吧,掌握了Service Mesh,你就選擇了一條未來技術框架的道路。至於這條道路會怎麼發展,還要再觀察。這篇文章將解釋什麼是Service Mesh,為什麼需要Service Mesh,以及Service Mesh的現狀如何。

初識Service Mesh

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

時間回到2016年10月,Alex Leong開始在Buoyant公司的官方博客中連載一系列關於“A Service Mesh for Kubernetes”的文章。

隨著2017年Linkerd加入CNCF,Service Mesh開始大規模出現在各個技術論壇上,Service Mesh在國內被翻譯為“服務網格” 。

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

架構演進的兩大方向,一個是Serverless,另一個是什麼? 1

架構演進的兩大方向,一個是Serverless,另一個是什麼? 2

現在,Service Mesh逐步發展為一個獨立的基礎設施層。在Cloud Native架構下,單個應用程序可能由數百個服務組成;每個服務可能有數千個實例;並且這些實例中的每一個實例都可能處於不斷變化的狀態,因為它們是由諸如Kubernetes之類的資源調度系統動態調度的。這個世界中的服務通信不僅非常複雜,而且是運行時的普遍行為之一,管理它對於確保端到端的性能和可靠性至關重要。

Sidecar的比喻從何而來?

業內也有類似“Sidecar”的說法。這個概念很形象,就是我們以前在戰爭影片中看到的那種挎斗車。

架構演進的兩大方向,一個是Serverless,另一個是什麼? 3

這種模式被命名為Sidecar,因為它類似於連接到摩托車的輔助車。在該模式中,輔助車被附加到父應用程序並為應用程序提供支持功能。輔助車也與父應用程序共享相同的生命週期,與父進程一起被創建和推出。

解釋了這麼多,一句話來說的話,那就是:Service Mesh幫助應用程序在海量服務、複雜的架構和網絡中建立穩定的通信機制,業務所有的流量都轉發到Service Mesh的代理服務中。

不僅如此,Service Mesh還承擔了微服務框架所有的功能,包括服務註冊發現、負載均衡、熔斷限流、認證鑑權、緩存加速等。不同的是,Service Mesh強調的是通過獨立的進程代理的方式,除此之外,還承擔了上報日誌、監控的責任。 Service Mesh架構如下。

架構演進的兩大方向,一個是Serverless,另一個是什麼? 4

輕量、自治促進不斷發展

Service Mesh的出現是由微服務架構推動的,隨著一個應用被拆分為幾百個甚至幾萬個應用,服務治理面臨巨大的挑戰。這個時候,微服務框架出現,例如,Finagle、Dubbo、SpringCloud、Netflix OSS等。這些框架都是基於客戶端負載均衡直連的方式,此方案的優勢是性能高、應用性好,如Spring Cloud。

歸根結底,在微服務架構中,我們要解決的問題是,讓開發人員感覺不到微服務之間的通信。當服務數量越來越多,升級微服務框架變得越來越複雜的時候,你不可能要求微服務框架一直不變,而且是沒有bug的。在技​​術更新如此之快的年代,就更不可能了。

因此,微服務框架的部分功能開始逐步向服務端移動,希望客戶端可以盡量“薄”,但是客戶端不可能無限制的“薄”,剩餘部分仍然比較“厚”。

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

微服務架構更強調去中心化、獨立自治、跨語言,但是通常微服務框架限制了這一點,不可能為每種語言都實現一種框架,要么都用一種語言,要么實現多種語言的框架。而Service Mesh通過獨立進程的方式進行了隔離,可以低成本實現跨語言。

隨著Docker及Kubernetes的崛起,微服務的部署模式開始發生轉變,越來越趨向於輕量級,越來越強調隔離自治。每個服務獨立佔用一個容器,將服務、依賴包、操作系統、監控運維所需的代理打包成一個鏡像。這種模式促成了Service Mesh的發展,讓Service Mesh實現起來更容易。否則開發人員需要額外維護Service Mesh進程,就非常麻煩了。

主流框架的弊病和優勢

目前Service Mesh的框架如雨後春筍般快速湧現,以下幾個框架是目前為止被提到次數最多的。

先驅者如Linkerd,被譽為業界第一個Service Mesh項目,但由於很多功能被後續框架所取代,發展有限。現在最流行的是Envoy,它在性能和資源消耗上表現得非常出色,被Istio收編之後, 專注於數據平面。最值得注意的是Istio,因為它的背後是Google和IBM。從0.3版本開始支持非Kubernetes平台,並可以獨立運行。

當然業內還有其他一些框架,由於暫時沒有投入到生產環境,進展有限,可以關註一下,比如Conduit 、nginMesh等。

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

先謹慎觀察 未來可期

實際上,如果在一個小公司,Service Mesh的優勢並不是十分明顯。例如小公司很少會考慮採用多語言,因為多一種語言就意味著要花費額外的精力進行維護,所​​以到目前為止,大多數公司在後端只使用一兩種語言。

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

Service Mesh對業務開發人員友好,但是基礎設施層的研發會更複雜,需要依賴更多的服務、組件,否則將帶來極大的架構、運維複雜度。對於很多公司來說,門檻稍高,且需要投入成本。

百度內部業務也很早就開始了基於Service Mesh思想的微服務實踐,並自研了BMesh框架,大大降低了Service Mesh的實施和維護成本,並解決其自身的性能問題。基於這些內部實踐,百度智能雲CNAP產品目前已經邀測推出了非侵入式微服務解決方案,為客戶提供可商用的基於Service Mesh的微服務監控、追踪和治理平台。目前來看,在沒有成熟起來以前,Service Mesh並不具備壓倒性的優勢。但未來隨著微服務的進一步快速普及,Service Mesh作為重要的架構演進方向值得關注。

本文參考資料

百度智能雲官網

https://cloud.baidu.com/product/cnap.html

CNCF官網:

https://www.cncf.io/

《雲原生基礎架構》,機械工業出版社,2018年9月第一版

《持續演進的Cloud Native 雲原生架構下微服務最佳實踐》,電子工業出版社,2018年10月第一版

本文轉載自公眾號AIOps智能運維(ID:AI_Ops)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzUyMzA3MTY1NA==&mid=2247485343&idx=1&sn=f6fe632e65e30f4bfb7b2f705a840369&chksm=f9c37e56ceb4f740ef473a4758fd2e1f5e16138fb743f09ec1772d3317d34decd93fb2d63d87&scene=27#wechat_redirect