基于開源體系的云原生微服務治理實踐與探索

作者：董藝荃 2022-12-26 16:34:51

云計算 Operator作為翻譯機包含了大量模型轉(zhuǎn)換邏輯，能夠?qū)⑴渲媚Ｐ头g成CRD模型。

目前創(chuàng)新互聯(lián)建站已為千余家的企業(yè)提供了網(wǎng)站建設、域名、虛擬空間、綿陽服務器托管、企業(yè)網(wǎng)站設計、霍爾果斯網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

作者簡介

CH3CHO，攜程高級研發(fā)經(jīng)理，負責微服務、網(wǎng)關(guān)等中間件產(chǎn)品的研發(fā)工作，關(guān)注云原生、微服務等技術(shù)領域。

一、攜程微服務產(chǎn)品的發(fā)展歷程

攜程微服務產(chǎn)品起步于2013年。最初，公司基于開源項目ServiceStack進行二次開發(fā)，推出.Net平臺下的微服務框架CServiceStack。

2014年，公司推出Java平臺下同CServiceStack完全互通的自研微服務框架Baiji和第一代服務注冊中心。該服務注冊中心后續(xù)經(jīng)歷多次重構(gòu)，目前使用的已是第四代產(chǎn)品。

2017年,公司正式引進開源產(chǎn)品Dubbo，推出整合攜程治理能力的CDubbo框架。該框架最初基于Dubbo 2.5.4版本進行二次開發(fā)，經(jīng)歷多次版本升級后，目前使用Dubbo 2.7.7版本。

2020年,公司正式開始探索落地Service Mesh項目。目前，相關(guān)產(chǎn)品已經(jīng)在生產(chǎn)環(huán)節(jié)正式落地，正在進行接入推廣工作。

攜程微服務產(chǎn)品情況復雜，主要在于以下四點。

第一，線上同時運行著三種微服務框架產(chǎn)品。

第二，同時采用HTTP和Dubbo兩種通信協(xié)議。

第三，采用完全自研的基礎設施，包括注冊中心和配置中心。

第四，現(xiàn)存8000多個線上服務，實例數(shù)超過10萬個。

隨著研發(fā)的深入，我們團隊主要遇到了以下三點問題。

第一，維護多個功能類似的中間件產(chǎn)品工作量較大，保證產(chǎn)品之間功能對齊需要花費大量的精力。

第二，由于產(chǎn)品以SDK公共依賴包的形式集成在業(yè)務應用內(nèi)，進行版本升級需要業(yè)務方配合，推動升級比較困難，版本長尾問題嚴重。

第三，由于團隊工作精力和技術(shù)棧的限制，只有少數(shù)幾個語言平臺上存在SDK支持，不利于小眾語言用戶使用微服務產(chǎn)品。?

二、攜程的云原生微服務架構(gòu)設計

由于線上集群已初具規(guī)模，如何平滑過渡和遷移框架成為關(guān)鍵問題。徹底拋棄現(xiàn)有基礎設施，一步到位實現(xiàn)全面云原生，不僅實施難度較大，項目周期也比較長。

因此，項目決定采用“小步快走”的方式。首先保證代碼完全向后兼容，其次保證整體架構(gòu)支持業(yè)務應用遷移，提升接入容錯率。

項目進行架構(gòu)設計時，遇到了三個關(guān)鍵的問題。

數(shù)據(jù)權(quán)威問題：常見的Service Mesh實踐以K8s為準則，將所有的數(shù)據(jù)保存在K8s內(nèi)，但平臺現(xiàn)有數(shù)據(jù)大部分保存在自研的注冊中心和配置中心內(nèi)。

有方案提出采用兩條推送路的方式，云內(nèi)數(shù)據(jù)保存在K8s內(nèi)，云外數(shù)據(jù)保存在現(xiàn)有注冊中心里，通過外部工具或組件實現(xiàn)雙向同步。但雙向同步復雜度較高，既要保證數(shù)據(jù)的準確性和實時性，也要保證同步不成環(huán)。

因此，出于架構(gòu)簡便性考慮，項目最終選擇保持注冊中心數(shù)據(jù)權(quán)威地位不變，通過外部組件將數(shù)據(jù)寫入K8s。

邊界劃分問題：目前的項目部署體系是一個Region內(nèi)包含多個Zone，一個Zone內(nèi)又包含多個K8s集群，集群之間網(wǎng)絡互通。但由于故障隔離的需要，數(shù)據(jù)最好保持在Zone內(nèi)收斂，使實例信息不需要進行跨Zone同步。

Zone內(nèi)收斂存在的問題是當調(diào)用方發(fā)起跨Zone調(diào)用時，需要經(jīng)過網(wǎng)關(guān)進行中轉(zhuǎn)。這種調(diào)用方式和現(xiàn)有的調(diào)用鏈路存在差異，會提高計算復雜度。

因此，項目最終選擇保持現(xiàn)有工作模式不變，使得調(diào)用方能夠獲取Region內(nèi)所有的Zone服務實例，保持數(shù)據(jù)在Region內(nèi)透明。

技術(shù)選型問題：過去，項目研發(fā)產(chǎn)品大部分采用自研模式，通過整個團隊成員協(xié)作完成開發(fā)工作，而依托開源社區(qū)能夠更容易地產(chǎn)出優(yōu)秀產(chǎn)品。

因此，項目最終選擇基于開源產(chǎn)品進行二次開發(fā)。

目前所使用的Service Mesh架構(gòu)設計，也被稱為“漸進性”架構(gòu)，主要有三個方面的特點。

開源方面：選擇Istio和Envoy作為Service Mesh的基礎設施。

實例和配置同步方面：由新開發(fā)的SOA Operator負責將存儲在注冊中心和配置中心中的數(shù)據(jù)寫入K8s。

同時，該程序也會把K8s集群內(nèi)服務提供方的數(shù)據(jù)寫入注冊中心，使得K8s集群外用戶也能夠正常讀取服務數(shù)據(jù)。并且，該服務不需要SDK支持，由SOA Operator直接完成注冊和發(fā)現(xiàn)，任何語言都可以方便地接入微服務產(chǎn)品體系。

使用方面：K8s集群外的應用仍然使用過去的交互方式，通過SDK和注冊中心進行通信。

K8s集群內(nèi)的應用，如果使用SDK，檢測到Sidecar存在之后，SDK會自動地關(guān)閉服務治理功能，使用特殊的host進行請求。如果不存在SDK支持，接入Mesh可以直接使用HTTP Client，繼續(xù)使用特殊的host發(fā)起請求。

HTTP協(xié)議在Service Mesh架構(gòu)上運行良好，但Dubbo協(xié)議在Sidecar網(wǎng)關(guān)上存在一些問題。

其一，元數(shù)據(jù)的位置：HTTP協(xié)議中元數(shù)據(jù)位于報文最前端，而Dubbo協(xié)議中元數(shù)據(jù)位于報文末端，因此需要先解析報文才能定位到元數(shù)據(jù)位置。

其二，序列化問題：解析報文需要對報文進行反序列化處理，目前Envoy支持Dubbo默認序列化協(xié)議。但這種方式會產(chǎn)生額外開銷，而且Dubbo服務使用的序列化器復雜，甚至還有一些團隊為進一步降低報文大小，使用了壓縮算法，網(wǎng)關(guān)解析難度大。

Dubbo 3推出了Triple，這是一種使用基于HTTP/2的gRPC并通過請求標頭實現(xiàn)元數(shù)據(jù)信息傳遞的通信協(xié)議，也是Dubbo 3中推薦使用的服務通信協(xié)議。

Triple協(xié)議適用于Envoy框架，且能輕松接入Service Mesh。Dubbo版本升級也并不復雜。

由于gRPC的PB序列化格式，Triple協(xié)議無法直接使用。盡管Triple協(xié)議對PB兼容性較好，但PB要求先寫契約再生成代碼，而Dubbo要求先寫代碼，不存在契約，數(shù)據(jù)模型也是與PB對象完全不同的POJO格式。

為了連接POJO和PB對象，Triple協(xié)議設計了Wrapper。將原POJO對象序列化處理得到二級數(shù)據(jù)后，傳入到Wrapper用PB進行序列化。

然而，這種方式不僅會導致內(nèi)存占用變大，而且會引發(fā)更多的GC。多次GC和重復序列化將會增大CPU負載。

為解決Triple協(xié)議帶來的問題，項目給gRPC添加了自定義序列化器。這樣不僅可以實現(xiàn)流式的序列化，也可以為用戶提供和原生Dubbo一樣的使用體驗。

其他語言想要調(diào)用這種gRPC服務，只需要具備這種自定義序列化器即可，默認的自定義序列化器JSON可以被大部分語言解析。

治理方面，Service Mesh使用Istio和Envoy作為基礎設施，通過Istio讀取K8s中CRD數(shù)據(jù)，并生成配置推送給Envoy。

因此，保存在自研服務治理系統(tǒng)里內(nèi)的實例數(shù)據(jù)、配置數(shù)據(jù)必須全部轉(zhuǎn)化成CRD格式，同步到K8s以供Istio處理。

Operator作為翻譯機包含了大量模型轉(zhuǎn)換邏輯，能夠?qū)⑴渲媚Ｐ头g成CRD模型。針對一些復雜的功能，項目通過Envoyfilter或者Envoy的二次開發(fā)，添加自定義的Envoyfilter進行實現(xiàn)。

目前，所有的常用功能都已完成對齊，整體功能覆蓋率超90%。數(shù)千個線上應用完成接入，進入后續(xù)接入推廣工作。

三、云原生微服務產(chǎn)品的未來發(fā)展趨勢

Service Mesh提供的都是通用能力，如分組、路由、流量控制、負載均衡等。這些功能本身沒有語義，一線的業(yè)務研發(fā)和運維人員理解起來存在一定困難。

而且，該產(chǎn)品功能與現(xiàn)存治理系統(tǒng)的功能存在差異。為了給一線人員提供更好的微服務治理體驗，需要將實際運維需求和底層控制數(shù)據(jù)聯(lián)系起來。

目前，社區(qū)內(nèi)Dubbo Mesh的研發(fā)工作也在積極進行，其做法跟攜程云原生微服務治理框架類似。通過單獨的控制面將配置數(shù)據(jù)寫到K8s里，將實例數(shù)據(jù)通過MCP進行同步。

另外，新的開源產(chǎn)品OpenSergo也在研發(fā)中。據(jù)官方介紹，該項目力圖打造一套通用的面向云原生的微服務治理標準，并且提供一系列的API和SDK實踐。

目前，多家大型互聯(lián)網(wǎng)企業(yè)和開源社區(qū)正在共同推進該項目的進行，希望能夠完成從服務治理到云原生基礎設施的全鏈路生態(tài)覆蓋。

分享標題：基于開源體系的云原生微服務治理實踐與探索
地址分享：http://m.5511xx.com/article/cojgpdj.html