Service Mesh漸熱:我們跟專家聊了聊這些疑問該怎麼解決

有人把2018年稱爲 Service Mesh之年,在2018年至今的兩年時間內,Service Mesh從概念期進入到應用期,國內部分企業甚至已經進入 Service Mesh大規模落地的深水區。但是伴隨而來的,是對Service Mesh的諸多疑問:非Kubernetes環境是否可以進行Service Mesh研發?Service Mesh改造或自研面臨的風險有哪些?Service Mesh維護複雜、成本高昂的問題如何解決?近期InfoQ記者採訪了Tetrate.io CEO Varun Talwar,Founding Engineer吳晟,以及Head of Products Sridhar Krishnamurthy,就以上問題給出答案。

InfoQ:Kubernetes在應用生命週期管理方面很成熟,那麼,Service Mesh補足了哪些Kubernetes不太成熟的地方?

A:Service Mesh更多的關注服務間通訊的管理。Kubernetes解決了服務註冊和發現的問題,但是在通訊層面、安全、監控,以及由此爲數據基礎的審計、擴容等能力等方面,這些都是Service Mesh帶來的新特性。同時更爲重要的是,Service Mesh還提供另外兩種核心能力:

  • 提供了智能網關,替代F5成爲主入口的能力。並由於Service Mesh對Envoy在網關和Sidecar具有相同的管理能力,可以更爲平滑的完成傳統Proxy負載均衡到Service Mesh的過渡。
  • 在從VM到Kubernetes遷移過程中,Service Mesh提供了橋接兩端的能力。即使針對陳舊的系統架構,無需微服務化技術改造,依然能獲得相應的能力,併爲向Kubernetes的遷移掃清障礙和提供保障。

InfoQ:國內大部分技術專家認爲 Service Mesh 最關鍵的部分是將服務通信管理能力從業務應用剝離下沉到基礎設施,您認爲Service Mesh的關鍵部分是什麼?

A:是的。事實上,把諸如超時、重試、熔斷在內的網絡通訊相關的特性,從應用部署環境中獨立出來,可以有效的提升應用的部署能力。如果上述的這些通訊相關特性被硬編碼在業務代碼中,即使是通過SDK庫的模式,都不利於應用的快速部署。

更重要的是,這些SDK庫需要針對目標應用進行反覆的測試,以保證庫的問題。同時,SDK的多語言帶來的開發和維護工作量都是巨大的,還需要忍受版本長期無法升級的問題。Service Mesh移除了上述的這些短板,通訊管理完全獨立於應用之外。使應用開發更關注應用業務本身,將網絡層技術透明化和平臺化。

InfoQ:當企業決定部署Service Mesh時,對內部不同角色的技術人員(基礎研發、業務研發等)會有哪些不同的影響?哪類開發人員需要重點關注呢?

A:Service Mesh會幫助開發團隊提升部署能力,更利於項目更高頻率的升級。在生產環境上,無論是DevOps形式的團隊,還是傳統的運維團隊,都可以藉助Service Mesh的能力,在VM和Kubernetes環境間進行流量切換,或者實施藍綠髮布、金絲雀發佈策略等等。平臺團隊可以更加關注網絡性能、路由策略和網絡,而無需關心業務代碼的語言、類庫版本和技術選型等問題。使平臺團隊和業務開發團隊更加專注在自己擅長的領域,從而加速團隊的整體能力。

InfoQ:對於治理系統重度依託微服務框架的用戶,應用 Service Mesh 要做出較大改動,至少需要將服務發現、路由等功能遷移到 Sidecar 中,對這類用戶有沒有比較好的建議?

A:從微服務框架切換到Service Mesh的技術難度不大,只需要不再依賴原有框架中的服務發現、路由等功能,而Service Mesh的這些特性是透明、對應用無感知的。但是,這些用戶真正需要改變的更多是在組織架構層面,而非純粹技術角度。Service Mesh給應用開發團隊提供了更爲靈活的服務管理工具,公司必須調整自己的運作模式來使得Service Mesh的效能最大化。

Service Mesh更傾向於讓應用團隊能夠在統一的平臺之下,還能夠對各自部署的應用進行管理,包括流量控制、安全、可觀察性、容災、動態發佈等。同時保證不同團隊間的隔離性。而至於遷移問題,在Service Mesh上,這些都是簡單的配置即可完成,只需要停掉應用側框架的服務發現,通過服務名稱直接調用目標應用,即可快速遷移到Service Mesh的環境上。

InfoQ:對於服務化和容器化均不完善的企業,是否可以進行Service Mesh研發?難點在哪裏?是否有好的解決辦法?

A:Service Mesh特別是istio,可以在VM或者只是普通基於容器的非Kubernetes環境中使用,不過在這種使用方式實現和部署起來並不是那麼容易。主要的挑戰在於,這些環境中沒有Kubernetes提供的服務註冊,服務發現,Envoy設置、啓動和聲明週期管理能力以及跨網絡(VPC、Cloud Region等)的mesh設置能力。

這也是Tetrate在提供商業級Service Mesh時特別重視的點,我們提供了基於Kubernetes,VM環境以及兩者混合環境的Service Mesh一致性解決方案。

InfoQ:Service Mesh 模式在業務每次遠程調用增加 1 跳至 2 跳時,會帶來性能損耗,一條實際的調用鏈路可能包含多次遠程調用,性能損耗會被明顯放大,有好的解決方案嗎?

A:目前公開的Service Mesh中Envoy造成的額外訪問延時大概是3毫秒。在這個背景下,應用獲得包括安全控制、流量管理和可觀察性在內的能力。除非應用對於延遲是極其敏感的,否則這些用戶可以在使用前對系統工作在Service Mesh上的效果進行評估。但是對於多數應用來說,這個延遲不會是真正的問題。

很多公開資料包括SkyWalking的實際使用案例看來,絕大多數應用無論集羣節點併發流量多大,在單節點點對點模式下,普遍單點很少超過1000TPS/QPS,延遲也在50-100毫秒,甚至更高。在此背景下,3毫秒的延遲不會給系統帶來真正的問題。同時,對於分佈式調用深度的問題,超過5層的串行深度應用系統,一般已經無法很好的提供優良的響應和SLA,也更不會因爲Envoy的額外性能開銷,有更明顯的降低。多數的深層調用,都是通過低延遲MQ或者批量任務異步化處理的,在這個過程中,幾十毫秒(即使包含10層的分佈式調用)也不會產生性能問題。

在實際的Service Mesh實踐中,Envoy對訪問的延遲能夠保證穩定,即在高流量下也依然保持在3毫秒左右的延遲,這個是對生產環境最根本的保障。

InfoQ:企業使用Service Mesh 往往需要二度改造或自研,這時會面臨哪些風險問題?

A:在北美,包括大型雲廠商內部,都有過大量的私有Service Mesh先例,這是一個非常常見的想法。但隨着Service Mesh的建立,複雜度不斷提供,即使這些廠商有着全球頂尖的技術人才,他們依然覺得維護私有的內部Service Mesh版本工作量巨大、成本高昂。所以,他們在大量轉向開源的Service Mesh解決方案,特別是Envoy和Istio。

這兩個項目的社區發展都特別迅速,雲廠商投入了很大的精力和人力在這兩個項目上。單單集成這兩個複雜的項目,往往已經是成本巨大的。如果是在內部方案中,甚至往往還不能很好的隔離控制面和數據面的功能,使得項目變得十分的臃腫和難以維護。目前,全球幾乎所有主流廠商,都在Istio和Envoy兩個社區中進行廣泛合作,以開源爲核心構建Service Mesh,而非重複造輪子。

這也是Tetrate在這個方向上提供企業級Service Mesh的原因,幫助用戶減少這方面的投入,提供高度產品化的解決方案。

針對其他的RPC機制,Envoy和其他所有開源社區一樣,需要有更多的人來參與。比如Dubbo協議已經得到初步支持,但性能還需要進一步評估;比如MySQL,PostgreSQL,Redis等等,也需要更多廠商的參與。

隨着Service Mesh的更大範圍生產應用,會被逐步補齊,我們在SkyWalking的插件貢獻中,也能明顯的發現頂級社區的強大吸引力和共建能力。

關於Tetrate.io

Tetrate.io是北美Service Mesh服務商,由來自Google,Twitter,IBM,VMWare,華爲等公司的技術專家創建,其中包括Isio,Evnoy和SkyWalking的創始團隊和核心維護者。Tetrate.io今年在Envoy的貢獻位於全球第二,第一是Google;Istio的貢獻位居第三,第一和第二分別是Google和IBM;在SkyWalking中有近4萬行提交,排名第一。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章