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

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

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

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

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

聯(lián)通微服務(wù)架構(gòu)發(fā)展歷程有何獨(dú)特之處？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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