服務網格在聯通的落地實踐

語言: CN / TW / HK

 

【百度雲原生導讀】2020年聯通集團確定了以 Kubernetes(以下簡稱K8s)為資源排程平臺的架構演進路線,與之相對的應用微服務架構也需基於 K8s。中國聯合網路通訊有限公司軟體研究院(以下簡稱 聯通軟研院)在微服務技術進行了長期的技術研究開發與應用實踐。期間,收穫了微服務為聯通生產建設帶來的紅利,也因需要支撐多種微服務架構帶來很多困擾,經過業內的調研及評估,最終確定了以服務網格(Service Mesh)為微服務的演進方向,組建微服務研發團隊,並完成中國聯通服務網格 CSM(Chinaunicom Service Mesh)產品研發。

2021年聯通軟研院持續迭代服務網格 CSM 產品,為進一步提升網格能力及微服務治理能力,與百度聯合研發 Mesh 服務治理能力並將其融合進 CSM  產品,並借鑑百度服務網格在百度 APP、百度地圖等優秀實踐經驗,推進 CSM 在聯通試點推廣及規模化應用生產落地,在實現了雙方的共贏的同時,完成了服務網格在各自業務場景下落地的經驗積累。

通過服務網格技術將微服務能力下沉到 『基礎設施層』,實現了微服務技術棧統一、技術架構雲原生化、 多語言場景下微服務能力對齊、業務非侵入式接入監控、服務治理體驗大大提升。

 

1. 什麼是服務網格

 

 

微服務1.0階段微服務業務需要主動依賴 SDK 來實現基本的微服務能力(如熔斷、負載均衡、限流等)。因此該部分微服務能力需要和業務應用捆綁在一起,並且對程式語言有強烈的依賴(一個典型的例子C++微服務 SDK 無法直接在 Java 業務中使用)。

 

微服務2.0階段按照基礎設施下沉的思路,微服務能力不再通過 SDK 來實現,而是通過獨立的邊車 Sidecar 的思路來實現,Sidecar 作為獨立的程序和業務程序分別在兩個獨立的容器中,各自獨立,其天然解決了微服務場景中多語言的依賴問題。

 

 

如上所示,由邊車 Sidecar 形成的網路平面,稱為『服務網格』。

 

2. 聯通軟研院微服務架構發展歷程

 

 

目前微服務架構的發展也經歷瞭如下幾個階段:

 

  • 階段1:以天宮1.0技術為代表,主要採用虛擬機器和 RPC 框架。

  • 階段2:以天宮2.0、3.0技術為代表,主要採用容器、Spring 和自研服務框架。

  • 階段3:以服務網格(Service Mesh)技術為代表,採用 K8S 和 Istio 為主的目標架構。

 

聯通軟研院確立了以服務網格作為其目標架構,因此在落地實踐中除了考慮服務網格技術,還重點考慮相容存量微服務架構的遷移。

 

3. 落地實踐

 

3.1  RPC 架構向服務網格遷移

 

 

通過梳理現有存量微服務業務,發現有大量的存量微服務業務採用 SDK 方式,其中 RPC 框架是一個典型的代表。通過梳理髮現現有 RPC 框架的主要技術特點和業務訴求如下:

 

  1. 業務程式碼基於介面/方法編碼方式。

  2. SDK 基於介面級別的服務發現機制。

  3. 業務方希望不改動現有的業務程式碼,實現向服務網格遷移。

 

結合聯通軟研院業務現狀以及服務網格的演進路線,與百度進行了多輪研討和論證,雙方共同確立了最終的遷移方案。遷移方案如下所述:

 

降低遷移成本低

 

考慮到業務方遷移的訴求(即不希望改動業務程式碼),因此在設計遷移方案時,重點保證業務不改動業務程式碼。通過動態代理的方式相容業務現有介面/方法的編碼方式,業務只需要新增幾行註解即可實現遷移,遷移成本大大降低。

 

降低冗餘註冊資料

 

考慮到目前雲原生技術中服務發現機制都是基於應用級別服務發現機制, 因此實現服務發現機制由介面級別轉變為應用級別,使遷移後的架構服務發現機制更加雲原生化。同時該機制的轉變,能夠有效減少註冊中心中冗餘資料,降低註冊中心壓力。

 

3.2  Mesos 架構向服務網格遷移

 

 

目前部分業務微服務架構資源呼叫採用 Mesos+Marathon,服務治理採用 Spring Cloud,該架構主要有以下特點:

 

  • 部分微服務治理能力通過 SDK 實現(如熔斷、限流等)

  • 資源排程和負載均衡依託於 Mesos、Marathon LB 能力實現

  • 治理能力分散在多種治理元件上

 

基於不改動現有業務程式碼的同時完成向服務網格平滑遷移(即存量應用中已遷移服務和未遷移服務之間的互訪)目標,經過與百度的共同努力,制定了業務方滿意的遷移方案。方案如下所述:

 

降低遷移成本低

 

同樣,在遷移方案上,業務無需修改業務程式碼。通過對SDK V1(Fat SDK)移出相關微服務能力併兼容服務網格架構,實現 SDK V2(Thin SDK),微服務能力統一在基礎設施 Sidecar 上實現。考慮到現有的 Mesos 中 Marathon LB 的架構,通過中心級別配置規則,配置少,平滑遷移現有業務邏輯。

 

雲原生化

 

通過將基礎設施 Mesos 更換為 K8s 和 Istio 技術棧,使遷移後的架構更加雲原生化,對齊業務主流服務網格架構。

 

3.3  可觀測性在服務網格場景下建設

 

 

為推進存量業務向服務網格遷移,在兼顧業務的無感遷移的同時,補齊服務網格業務與非服務網格業務可觀測性的能力。

 

實現業務真正的無侵入接入 Mesh

 

服務網格技術主要通過將基礎設施下沉實現的無侵入性,通過將微服務相關能力(如路由、限流、熔斷等)在邊車 Sidecar 實現。

 

但唯一對業務有侵入的地方,體現在 trace header 透傳,如下引用了 Istio官 網關於trace header 透傳的內容:

 

Although Istio proxies are able to automatically send spans, they need some hints to tie together the entire trace. Applications need to propagate the appropriate HTTP headers so that when the proxies send span information, the spans can be correlated correctly into a single trace.

 

因此對於業務來講並不是完全無侵入,業務方可能會問,什麼是 header 透傳?簡而言之,業務需要在程式碼當中主動透傳邊車 Sidecar 上生成的 trace 頭資訊,否則會出現trace 鏈路不完整。

 

針對大量的 Java 業務,採用Java Agent(一種位元組碼增強技術)實現業務的零改造(業務無需感知 trace header 透傳),實現在位元組碼層面 trace header 透傳。

 

實現方法級別監控,監控資料更完整

 

由於服務網格技術的特殊性(微服務能力統一由邊車 Sidecar 實現),因此在監控層面會有天然的劣勢。這裡的劣勢主要體現在監控資訊只能通過邊車 Sidecar 來生成,而對於業務內部的方法級別的執行細節無從得知。

 

針對大量的 Java 業務,採用Java Agent(一種位元組碼增強技術)採集業務內部的方法級別的實現細節,並協同邊車 Sidecar 層面監控資訊,實現從邊車 Sidecar 監控到業務內部方法級別監控的完整鏈路。

 

支援多種監控系統,靈活性更強

 

通過引入 OpenTelemetry 規範,實現資料採集端的資料協議統一。

 

對於 Service Mesh 體系架構中採集的監控資料,統一按照 OTLP 協議傳送至OpenTelemetry Collector(收集器)中,OpenTelemetry Collector 支援將資料對接至不同的監控系統(如Jaeger、Skywalking等),以此來遮蔽底層監控系統的差異性。

 

4. 未來服務網格產品的規劃

 

 

如上所示,服務網格產品已經具備了流量治理、安全、可觀測性、例項管理四個方面的能力。未來服務網格產品化也繼續緊跟 Istio 社群動態,持續迭代微服務相關能力,適配業務微服務場景,讓服務網格能夠更多業務場景落地。重點將圍繞著網格效能、治理能力和擴充套件能力進行迭代優化。以下為未來落地的初步構想:

 

4.1 服務網格效能優化 - 單跳方案

 

 

由於服務網格技術中邊車 Sidecar 用於業務的流量,其帶來的延遲,一直是業務特別關心的,也是服務網格未來能否被被業務方所接受的關鍵因素。

 

目前社群的方案為業務所有的進(Inbound)和出(Outbound)流量都會被邊車 Sidecar 攔截,該方式稱為雙跳方案。社群雙跳方案往往效能差,無法在超大規模環境下落地。

 

通過分析發現在流量攔截機制中 Inbound 流量非必要,因此可以考慮將減少 Sidecar 非必要 Inbound 流量攔截,該方式稱為單跳方案。該方案對比雙跳方案,能夠顯著減少Sidecar帶來的時延。

 

4.2 服務網格效能優化 - eBPF 方案

 

通過引入核心 BPF 中 socketmap 和 redirect 機制(提供了一種特殊的 map 型別即 socketmap,可以來做 socket redirection),繞開 TCP/IP 協議棧,降低邊車 Sidecar 層面帶來的時延。

 

4.3 擴充套件性優化-Fallback 機制

 

服務網格中典型的代理模式是通過 Sidecar 來進行請求攔截處理,實現微服務的能力。而在實際的實踐中,業務往往對增加的 Sidecar 的穩定性有很高的要求,儘管可以儘可能保障 Sidecar 的穩定,但仍無法打消業務的顧慮。

 

因此提供直連模式,能夠保障業務能夠在極端故障情況下,實現請求不經過 Sidecar 攔截處理,而是交由業務來處理流量,即使 Sidecar 存在的情況下。

 

Fallback 機制能夠有效保障業務的可靠性,能夠實現代理模式直連模式自由切換。

 

4.4 擴充套件性優化-按需下發

 

 

通過分析社群『全量下發』的方案,發現在規模化的場景中,往往會出現瓶頸問題。主要體現在 XDS 的全量推送和頻繁低效變更。

 

因此設計『按需下發』的方案,即下發的 XDS資料一定是 Sidecar 所需要的,避免非必要的冗餘資料和無效變更,提升服務網格的整體效能,滿足規模化落地場景的需要。這裡的『按需下發』主要是要收集微服務呼叫的依賴關係,會通過手動和程式自動收集的方式來收集。

 

4.5 治理能力優化-國產化

 

 

考慮到的業務會執行在各類國產化環境中,因此也會將服務網格整個技術體系相容不同的國產化環境。在晶片層面需要相容X86、ARM和PPC,在作業系統上需要相容統信UOS 和麒麟。

 

5. 價值收益

 

無論是業內還是落地服務網格的感受,都能體會到基於雲原生服務網格給業務帶來的收益價值,下面將分享一下服務網格帶來的價值收益。

 

微服務技術棧統一

 

通過服務網格技術設施下沉的思路,實現了微服務技術棧統一。一方面能能夠節省不同微服務框架的運維人力,另一方面能夠實現微服務功能的統一。

 

目前基於現有RPC服務框架的業務應用,可以實現零改造業務程式碼,達到遷移到服務網格的目的。

 

技術架構雲原生化

 

基於 K8s 和 Istio 構建的微服務架構,正在逐步替換已有的 Mesos 和 Marathon 架構,K8s 和 Istio 的技術架構是業界主流的雲原生架構,後續也將緊跟社群,共同發展。

 

支援多開發語言

 

服務網格能夠天然支援多種開發語言的服務治理。無需針對多種開發語言維護多套微服務技術體系,明顯節省人力成本。

 

非侵入式接入監控

 

基於現有的業務現狀,實現了業務真正的非侵入式接入服務網格,同時實現了邊車Sidecar監控資料和業務內部方法級別監控資料的打通,達到服務網格上的監控能力不低於業務現有監控能力的目的。

 

服務治理體驗提升

 

通過UI化的服務治理方式替換原有手動配置服務治理項的方式,大大提升了使用者使用服務治理功能的體驗。同時也極大縮短了業務服務治理週期。

 

6. 展望

 

目前所有試點專案已完成了測試環境遷移的驗證,其表現符合預期,部分試點業務已經向生產上線並平穩執行。未來將有更多的業務會逐步向服務網格的技術架構遷移。基於優異的雲原生實踐場景,聯通軟研院和百度將攜手在服務網格領域做更深入的聯合研發和技術探索,共同實現服務網格技術平穩落地,加快業務向雲原生化轉型,加速釋放業務的核心價值。

 


 

作者:聯通軟體研究院-溫懷湘

百度-劉超

 


 

進群!聊聊服務網格

掃碼新增小助手即可申請加入,一定要備註:名字-公司/學校-地區,根據格式備註,才能通過且邀請進群。

瞭解更多微服務、雲原生技術的相關資訊,請關注我們的微信公眾號【百度雲原生】