隨著以容器為核心的新一代應用承接平臺的崛起，微服務正煥發(fā)出新的生命力。

微服務究竟是什么？它經(jīng)歷了怎樣的發(fā)展歷程？又該如何用于實踐？本期，我們將以中國聯(lián)通微服務架構變遷為例探討服務網(wǎng)格是如何在聯(lián)通微服務發(fā)展史上立足的。
中國聯(lián)合網(wǎng)絡通信有限公司軟件研究院（以下簡稱聯(lián)通軟研院），在微服務技術上進行了長期的技術研究開發(fā)與應用實踐，收益顯著。而且，由于需要支撐多種微服務架構帶來的諸多困擾，經(jīng)過業(yè)內(nèi)的調(diào)研及評估，最終確定了以服務網(wǎng)格（Service Mesh）為微服務的演進方向，組建微服務研發(fā)團隊，并完成中國聯(lián)通服務網(wǎng)格 CSM（Chinaunicom Service Mesh）產(chǎn)品研發(fā)。
在提升網(wǎng)格能力及微服務治理能力上，聯(lián)通軟研院與百度智能云聯(lián)合研發(fā) Mesh 服務治理能力并將其融合進 CSM 產(chǎn)品，并借鑒百度智能云服務網(wǎng)格在 APP、百度地圖等領域的優(yōu)秀實踐經(jīng)驗，推進 CSM 在聯(lián)通的試點推廣及規(guī)模化應用生產(chǎn)落地，持續(xù)豐富服務網(wǎng)格在各自業(yè)務場景下落地的經(jīng)驗積累。
通過服務網(wǎng)格技術將微服務能力下沉到『基礎設施層』，實現(xiàn)了微服務技術棧統(tǒng)一、技術架構云原生化、 多語言場景下微服務能力對齊、業(yè)務非侵入式接入監(jiān)控，服務治理體驗大大提升。

服務網(wǎng)格為何物？

>> 微服務1.0階段：
微服務業(yè)務需要主動『依賴 SDK』來實現(xiàn)基本的微服務能力（如熔斷、負載均衡、限流等）。因此該部分微服務能力需要和業(yè)務應用捆綁在一起，并且對編程語言有強烈的依賴，舉一個典型的例子，C++微服務 SDK 無法直接在 Java 業(yè)務中使用。
>> 微服務2.0階段：
按照『基礎設施』下沉的思路，微服務能力不再通過 SDK 來實現(xiàn)，而是通過『獨立的邊車 Sidecar』的思路來實現(xiàn)，Sidecar 作為獨立的進程和業(yè)務進程分別在兩個獨立的容器中，各自獨立，天然解決了微服務場景中多語言的依賴問題。

 如上所示，由邊車 Sidecar 形成的網(wǎng)絡平面，稱為『服務網(wǎng)格』。

聯(lián)通微服務架構發(fā)展歷程有何獨特之處？

聯(lián)通微服務架構的發(fā)展也經(jīng)歷了如下幾個階段：

• 階段1：主要采用虛擬機和 RPC 框架；

• 階段2：主要采用容器、Spring 和自研服務框架；

• 階段3：以服務網(wǎng)格（Service Mesh）技術為代表，采用 K8S 和 Istio 為主的目標架構。

此外，聯(lián)通確立了以服務網(wǎng)格作為其目標架構，因此在落地實踐中除了考慮服務網(wǎng)格技術，還重點考慮兼容存量微服務架構的遷移。

在實踐中理解聯(lián)通服務網(wǎng)格

>> RPC 架構向服務網(wǎng)格遷移

通過梳理現(xiàn)有存量微服務業(yè)務，發(fā)現(xiàn)有大量的存量微服務業(yè)務采用 SDK 方式，其中 RPC 框架是一個典型的代表，其主要技術特點和業(yè)務訴求包括三點：

• 業(yè)務代碼基于接口/方法編碼方式；

• SDK 基于接口級別的服務發(fā)現(xiàn)機制；

• 業(yè)務方希望不改動現(xiàn)有的業(yè)務代碼，實現(xiàn)向服務網(wǎng)格遷移。

結合聯(lián)通業(yè)務現(xiàn)狀以及服務網(wǎng)格的演進路線，與百度智能云進行了多輪研討和論證，雙方共同確立了如下遷移方案：
▲ 降低遷移成本低
考慮到業(yè)務方遷移的訴求在設計遷移方案時，保證業(yè)務『不改動業(yè)務代碼』是重要訴求。通過動態(tài)代理的方式兼容業(yè)務現(xiàn)有接口/方法的編碼方式，業(yè)務只需要添加幾行注解即可實現(xiàn)遷移，遷移成本極大降低。
▲ 降低冗余注冊數(shù)據(jù)
考慮到目前云原生技術中服務發(fā)現(xiàn)機制都是基于『應用級別服務發(fā)現(xiàn)機制』， 因此實現(xiàn)服務發(fā)現(xiàn)機制由接口級別轉(zhuǎn)變?yōu)閼眉墑e，使遷移后的架構服務發(fā)現(xiàn)機制更加云原生化。同時該機制的轉(zhuǎn)變，能夠有效減少注冊中心中冗余數(shù)據(jù)，降低注冊中心壓力。

▲ Mesos 架構向服務網(wǎng)格遷移

目前部分業(yè)務微服務架構資源調(diào)用采用 mesos+marathon，服務治理采用 spring cloud，該架構主要有以下特點：

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

• 資源調(diào)度和負載均衡依托于 Mesos、Marathon LB 能力實現(xiàn)；

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

基于不改動現(xiàn)有業(yè)務代碼的同時完成向服務網(wǎng)格平滑遷移，即存量應用中已遷移服務和未遷移服務之間的互訪目標，經(jīng)過與百度智能云的共同努力，制定了業(yè)務方滿意的遷移方案。方案如下所述：
▲ 降低遷移成本低
同樣，在遷移方案上，業(yè)務無需修改業(yè)務代碼。通過對 SDK V1（Fat SDK）移出相關微服務能力并兼容服務網(wǎng)格架構，實現(xiàn) SDK V2（Thin SDK），微服務能力統(tǒng)一在基礎設施 Sidecar 上實現(xiàn)。考慮到現(xiàn)有的 Mesos中Marathon LB 的架構，通過中心級別配置規(guī)則，配置少，平滑遷移現(xiàn)有業(yè)務邏輯。
▲ 云原生化
通過將基礎設施 Mesos 更換為 K8s 和 Istio 技術棧，使遷移后的架構更加云原生化，對齊業(yè)務主流服務網(wǎng)格架構。

可觀測性在服務網(wǎng)格場景下的建設

為推進存量業(yè)務向服務網(wǎng)格遷移，在兼顧業(yè)務的無感遷移的同時，補齊服務網(wǎng)格業(yè)務與非服務網(wǎng)格業(yè)務可觀測性的能力。
>> 實現(xiàn)業(yè)務真正的無侵入接入 Mesh
服務網(wǎng)格技術主要通過將基礎設施下沉實現(xiàn)的無侵入性，通過將微服務相關能力在邊車 Sidecar 實現(xiàn)，比如路由、限流、熔斷等。
但唯一對業(yè)務有侵入的地方，體現(xiàn)在『trace header 透傳』。什么是 header 透傳？簡而言之，業(yè)務需要在代碼當中主動透傳邊車 Sidecar 上生成的 trace 頭信息，否則會出現(xiàn) trace 鏈路不完整。
針對大量的 Java 業(yè)務，采用 Java Agent（一種字節(jié)碼增強技術）實現(xiàn)業(yè)務的零改造(業(yè)務無需感知 trace header 透傳)，實現(xiàn)在字節(jié)碼層面 trace header 透傳。
>> 實現(xiàn)方法級別監(jiān)控，監(jiān)控數(shù)據(jù)更完整
由于服務網(wǎng)格技術的特殊性，因此在監(jiān)控層面會有天然的劣勢。這里的劣勢主要體現(xiàn)在監(jiān)控信息只能通過邊車 Sidecar 來生成，而對于業(yè)務內(nèi)部的方法級別的執(zhí)行細節(jié)無從得知。
針對大量的 Java 業(yè)務，采用 Java Agent（一種字節(jié)碼增強技術）采集業(yè)務內(nèi)部的方法級別的實現(xiàn)細節(jié)，并協(xié)同邊車 Sidecar 層面監(jiān)控信息，實現(xiàn)從邊車 Sidecar 監(jiān)控到業(yè)務內(nèi)部方法級別監(jiān)控的完整鏈路。
>> 支持多種監(jiān)控系統(tǒng)，靈活性更強
通過引入 OpenTelemetry 規(guī)范，實現(xiàn)數(shù)據(jù)采集端的數(shù)據(jù)協(xié)議統(tǒng)一。
對于 Service Mesh 體系架構中采集的監(jiān)控數(shù)據(jù)，統(tǒng)一按照 OTLP 協(xié)議發(fā)送至 OpenTelemetry Collector（收集器）中，OpenTelemetry Collector 支持將數(shù)據(jù)對接至不同的監(jiān)控系統(tǒng)（如 Jaeger、Skywalking 等），以此來屏蔽底層監(jiān)控系統(tǒng)的差異性。
從傳統(tǒng)微服務框架再到服務網(wǎng)格，聯(lián)通的微服務技術不斷向基礎設備下沉，前路日益明朗，下期我們再來聊一聊未來聯(lián)通對于服務網(wǎng)格產(chǎn)品的規(guī)劃。
文/聯(lián)通：溫懷湘 百度：劉超