隨著相關(guān)開源項目逐漸成熟，眾多企業(yè)對 Service Mesh 躍躍欲試，其中不乏著手布局并投入實踐的研發(fā)先鋒，順豐科技便是其中之一。

順豐科技在 2016 年底向云原生架構(gòu)轉(zhuǎn)型，開始了容器化建設(shè)，期間基于 Mesos 和 Marathon 自研了容器管理平臺 FBOX，應(yīng)用實例到了 18 年數(shù)量已上萬。2019 年，順豐科技基于 K8s 打造了第二代容器管理平臺 KCMP，核心應(yīng)用幾乎全部實現(xiàn)容器化，pod 實例達數(shù)萬。

經(jīng)過四年的發(fā)展，順豐科技已經(jīng)有了相當(dāng)?shù)娜萜骰A(chǔ)。在 2020 年，順豐科技邁入了自己云原生新的階段：Service Mesh。

當(dāng)時，困擾順豐科技的主要有三個問題。首先，順豐科技各業(yè)務(wù)團隊前期為了滿足自身的服務(wù)治理需求，選擇直接使用開源產(chǎn)品進行拼湊，存在不少重復(fù)造輪子的情況。隨著業(yè)務(wù)的快速發(fā)展，統(tǒng)一的服務(wù)治理標(biāo)準(zhǔn)和手段成為團隊的重要需求。

其次，為了解決安全管控、標(biāo)準(zhǔn)化 SDK 以及 SDK 兼容性問題，基礎(chǔ)設(shè)施團隊需要推動業(yè)務(wù)升級。但基礎(chǔ)框架、中間件客戶端的 SDK 與業(yè)務(wù)代碼耦合，存在依賴包沖突的情況，每次升級非常消耗時間和精力。

最后，傳統(tǒng)的藍綠灰度方案，機器資源成本高且架構(gòu)復(fù)雜。從業(yè)界和順豐科技內(nèi)部調(diào)研情況看，系統(tǒng)變更是造成系統(tǒng)生產(chǎn)異?；蚬收系闹匾?，因此研發(fā)團隊需要對功能進行灰度測試，充分驗證后才能正式發(fā)版。但順豐科技各個部門都在自建灰度能力，但不僅資源消耗大，還難以滿足各種場景的需求。

因此，順豐科技決定利用 Service Mesh 來解決上述問題，并先從原先成本和架構(gòu)復(fù)雜度相對較高的全鏈路灰度方案開始入手。

去年底，順豐科技研發(fā)平臺中心新組建一個專項小組來推動這個項目的發(fā)展，同時容器服務(wù)、DevOps 平臺、網(wǎng)絡(luò)安全等其他底盤團隊共同配合推進。

選擇合適自己的

根據(jù)順豐科技后端高級研發(fā)工程師楊定朝介紹，Service Mesh 重構(gòu)全鏈路灰度項目的落地主要分為三個階段：調(diào)研、研發(fā)和適配改造。

調(diào)研是技術(shù)選型的重要環(huán)節(jié)。要做選型，就要先了解自身的需求。之前，順豐科技同時部署了兩套環(huán)境藍綠環(huán)境，利用網(wǎng)關(guān)（Nginx、Kong）進行分流，但這也帶來了架構(gòu)復(fù)雜、運維及機器成本成倍提升、不能更好支持更多場景版本的路由等問題。

另外，順豐科技有 1700 多套系統(tǒng)，擁有 Dubbo、Spring Cloud、Spring Boot 等多個技術(shù)棧，支持 Java、Golang 等多種語言。這導(dǎo)致團隊在做安全、流控相關(guān)研發(fā)時，工作量會非常大。

因此，順豐科技的基礎(chǔ)需求主要集中在四方面：低成本、自動化、兼容和安全。這些需求具有一定的共性，實際上在對業(yè)內(nèi) Istio、MOSN 和 Polaris 等產(chǎn)品對比后，團隊也發(fā)現(xiàn)市面上大部分產(chǎn)品的功能都很豐富，這些基本都可以滿足。那么，如何更好地接入順豐系統(tǒng)就成了產(chǎn)品選擇的重點。

首先，順豐科技需要更符合自身系統(tǒng)的編程語言。2019 年的時候，順豐曾嘗試使用了 C++ 的 Envoy，但順豐的業(yè)務(wù)部門技術(shù)棧主要是 Java、容器是 Golang，雖然 C++ 有極致的性能，但有一定的上手難度，團隊沒有足夠的 C++ 經(jīng)驗和相關(guān)人才儲備。

其次，順豐科技想要將一些公共服務(wù)能力沉淀到數(shù)據(jù)面上，比如將 Config Mesh、Auth Mesh, Cache Mesh、Event Mesh 等能力融合到 Sidecar。順豐科技內(nèi)部不同的小組都有自己的標(biāo)準(zhǔn)，比如中間件團隊有自己標(biāo)準(zhǔn)的 SDK，但基礎(chǔ)架構(gòu)團隊時不時就要進行的升級對其非常不友好。升級不得不做，但要花費不少的人力，周期還很長。

最后，接入要讓業(yè)務(wù)無感知。業(yè)務(wù)非?？咕苄薷淖约旱某绦颍词剐薷囊膊幌ＭF(xiàn)有的東西有改變。但現(xiàn)在很多開源產(chǎn)品的客戶端主要是 Java，兩三年就有一個大的版本迭代，基礎(chǔ)架構(gòu)團隊不希望因此產(chǎn)生兼容性問題。直接使用開源產(chǎn)品的后果之一就是團隊要一直做適配。

基于以上考慮，團隊在數(shù)據(jù)面上選擇了更適合自身需求的 MOSN。MOSN 用 Go 編寫，有與分布式 Runtime 融合的能力，同時衍生產(chǎn)品 Layotto 在向下對接了各種基礎(chǔ)設(shè)施的同時，還向上為應(yīng)用提供了各種具有分布式能力的標(biāo)準(zhǔn) API，能夠?qū)⒏鞣N通用能力下沉到 Sidecar 里。

但在治理面上，并沒有一個完美適配順豐科技的產(chǎn)品。

Istio 在業(yè)內(nèi)算是最流行網(wǎng)格產(chǎn)品，但對順豐科技來說，由于內(nèi)部產(chǎn)品構(gòu)建原因，沒法直接使用 Istio。Istio 雖然使用事實標(biāo)準(zhǔn)的服務(wù)治理策略 xDS 協(xié)議，但 xDS 默認(rèn)全量下發(fā)的方式使服務(wù)過多，一個服務(wù)的更新都會引起全量的配置下發(fā)，導(dǎo)致帶寬占用過大，容易引起 istiod cpu 高負(fù)載，限制了 sidecar 的規(guī)模和穩(wěn)定性。

另外，Istio 通過 iptables 無差別劫持所有 tcp 流量，但由于 iptables 本身機制問題，當(dāng) service 或連接過多時就會出現(xiàn)性能問題。另外，公司系統(tǒng)大部分用 ingress 或者天璣網(wǎng)關(guān)域名調(diào)用，要求用戶修改回使用 service 方式調(diào)用，目前這種方式已經(jīng)不現(xiàn)實。

相比之下，Polaris 對順豐科技來說優(yōu)勢更明顯，如流量治理策略屏蔽了底層技術(shù)棧、流量劫持支持服務(wù)網(wǎng)格精準(zhǔn)攔截、支持多語言的 SDK 等。但騰訊 2021 年才將 Polaris 開源，這對順豐來說有點晚了，因為順豐已經(jīng)形成了自己的一套技術(shù)棧。

“我們的初衷和 Polaris 很像，也是希望提供統(tǒng)一的治理流量界面，用戶不需要關(guān)心底層的技術(shù)棧，只需接入即可使用?？上У氖?，我們已經(jīng)有自己對應(yīng)的技術(shù)棧了，Polaris 的 SDK 流量治理技術(shù)棧與我們的不相符。”順豐科技基礎(chǔ)架構(gòu)總工程師陳煥東說道。

但陳煥東所在的基礎(chǔ)架構(gòu)團隊，在調(diào)研期間還是選擇了能覆蓋順豐大部分場景的 Polaris 作為試點，抽取了 Polaris 中符合自身需求的部分能力融入到自身的服務(wù)治理平臺，再根據(jù)其他需求進行適配改造。

“適配改造是非常關(guān)鍵的。如果開源產(chǎn)品不能很好地適用公司的場景，那么就不能直接拿過來使用?！标悷|說道。就像 MOSN 即便符合順豐的多數(shù)需求，但團隊還是要在一些細(xì)節(jié)的地方做能力增強，以便滿足場景需求。

現(xiàn)在，順豐科技建成了 One Agent（Java 字節(jié)碼增強） + One Mesh（MOSN+ 改造后的 Polaris ）的順豐云原生服務(wù)治理平臺，即數(shù)據(jù)面選擇自建的 Java Agent、MOSN 產(chǎn)品，控制面選擇自建的 Plough Access 和改造 Polaris 產(chǎn)品，統(tǒng)一的治理面則圍繞順豐內(nèi)部技術(shù)自研改造。在陳煥東看來，這是更符合順豐科技現(xiàn)狀的選擇。

平臺架構(gòu)圖

方案落地

目前，順豐科技形成了以順豐云為基礎(chǔ)、應(yīng)用為中心的順豐云原生服務(wù)治理平臺。該平臺的流量負(fù)載主要圍繞 xDS 協(xié)議進行，服務(wù)功能涉及熔斷、降級、限流、黑白名單以及全鏈路灰度。而實施全鏈路灰度通常需要具備三要素：服務(wù)實例信息、路由能力和流量染色。

服務(wù)實例信息的 CDS、EDS，通過 controller 同步，然后交由治理面處理。治理面還負(fù)責(zé)制定路由功能和策略，各種 xDS 信息匯總后傳送給 MOSN。MOSN 會帶有流量染色的請求，然后將信息傳遞到服務(wù)集群，再做集群里面的負(fù)載均衡。

實際上，決定實施 Service Mesh 的時候，順豐非常確定的一點就是要用統(tǒng)一的服務(wù)治理協(xié)議 xDS 協(xié)議。

如今，業(yè)界的治理協(xié)議不斷發(fā)展，但由于沒有統(tǒng)一標(biāo)準(zhǔn)，微服務(wù)各種產(chǎn)品的治理協(xié)議異常繁雜和混亂，如果要做治理面就需要不斷地適配協(xié)議?！靶〉膱F隊可能無所謂，但是像順豐這樣體量的公司技術(shù)棧很復(fù)雜，我們也很擔(dān)心前期在一個開源產(chǎn)品上做了很多投入后項目突然不維護了，我們就得再考慮整體遷移改造的事情。大家都不想花費大量的精力去重復(fù)造輪子。”陳煥東說道。

陳煥東認(rèn)為，現(xiàn)在服務(wù)網(wǎng)格的主流廠商都是基于 xDS 協(xié)議構(gòu)建產(chǎn)品，只要按照這套標(biāo)準(zhǔn)，有需要時就可以輕松地切換，不會出現(xiàn)廠商綁定的問題。

順豐科技內(nèi)部有四萬以上的 Pod 實例，xDS 下發(fā)效率是一個不得不考慮的問題。團隊放棄了 Istio 可能導(dǎo)致 xDS 配置風(fēng)暴的全量發(fā)送方案，沿用了 Polaris 的發(fā)布訂閱模式，從 namespace 維度進行下發(fā)，既支持 namespace 全量下發(fā)，也可以訂閱其他 namespace 的服務(wù)信息。另外團隊也改造了 xDS 加載數(shù)據(jù)代碼，保證 xDS 數(shù)據(jù)可以在 5 秒內(nèi)被推送到 Sidecar 中。

在穩(wěn)定性方面，團隊沿用了 Polaris 精準(zhǔn)流量匹配的能力，服務(wù)網(wǎng)格調(diào)用的流量才會經(jīng)過 Sidecar，而調(diào)用像 Redis、Kafka、Dubbo 等時不會經(jīng)過 Sidecar。同時，現(xiàn)在入流量攔截會導(dǎo)入到 Sidecar，這樣在進行單個服務(wù)的壓測時，不做入流量攔截也不會帶來任何性能耗損。此外，基礎(chǔ)架構(gòu)團隊還計劃與容器團隊一起試水 ebpf 方案，來進一步提升網(wǎng)絡(luò)層性能。

安全方面，目前針對服務(wù)互調(diào)的場景，團隊考慮對 Mesh 層進行 mTLS 安全認(rèn)證。之前的認(rèn)證體系更多是基于設(shè)備和系統(tǒng)的靜態(tài)化體系，只涉及調(diào)用方和被調(diào)用方。認(rèn)證授權(quán)小組計劃結(jié)合基礎(chǔ)架構(gòu)團隊，將服務(wù)、接口等的認(rèn)證邏輯通過 MOSN 下沉到數(shù)據(jù)面進行處理，做到方法級流控。

帶來了哪些改變

實際上，順豐科技的 Service Mesh 探索不到半年，當(dāng)初實現(xiàn)全鏈路功能的根本目標(biāo)就已經(jīng)達成。期間，Service Mesh 帶給研發(fā)團隊的改變也非常明顯。

之前，研發(fā)需要做微服務(wù)框架的選型，選擇各種服務(wù)治理、混沌工程和安全生產(chǎn)工具?，F(xiàn)在，所有能力下沉到到 Service Mesh，業(yè)務(wù)通過流水線上訂閱的方式，在使用 Spring Boot 或 Golong 應(yīng)用時簡單勾選監(jiān)控、鏈路、治理等能力即可，不需要再自建和維護控制臺。

還有，業(yè)務(wù)研發(fā)需要依賴中間件資源，之前要先去順豐云申請，然后再對接各個專業(yè)組?，F(xiàn)在希望也把這些能力直接下沉到 Sidecar 里面，通過 API 的方式暴露出來，業(yè)務(wù)需要時可以直接使用 API 市場相關(guān)的中間件接口，不必再去順豐云申請。

除了順豐云原生平臺外，順豐科技也把這種拿來即用的能力慢慢下沉到 IDE 插件里，本地開發(fā)中心可以直接通過插件進行部署交付，對底層基礎(chǔ)設(shè)施基本無感知。

當(dāng)然，順豐科技的 Service Mesh 之路才剛剛開始，需要完善和改進的還有很多。比如后期團隊將流量的調(diào)度和控制、中間件 API、認(rèn)證授權(quán)等能力都放到了 Sidecar 里，數(shù)據(jù)面承擔(dān)的職責(zé)過多，資源容易消耗過多；灰度出現(xiàn)問題后，數(shù)據(jù)如何恢復(fù)之類的問題并未沒有得到很好地解決；團隊的降級方案但還無法考慮到所有場景；個別非 HTTP 業(yè)務(wù)場景的處理還需要完善等。

順豐云原生平臺的目標(biāo)是通過輕服務(wù)、分布式應(yīng)用網(wǎng)格和應(yīng)用編排三大核心產(chǎn)品，以及 One Id、One Agent、One Mesh、One Model、One Flow 五大技術(shù)體系，提供標(biāo)準(zhǔn)化、數(shù)字化和敏捷化的工具和場景化服務(wù)治理和運營管理體系，來持續(xù)改進業(yè)務(wù)質(zhì)量。輕服務(wù)產(chǎn)品接入統(tǒng)一的、輕量協(xié)議瘦客戶端即可輕松使用各種公共服務(wù)能力。應(yīng)用網(wǎng)格產(chǎn)品無論在服務(wù)內(nèi)外、云端或邊端，所有治理能力都無感知接入，并很好地融入到場景中。

產(chǎn)品全景圖

大規(guī)模落地之難

陳煥東坦言，隨著 Service Mesh 應(yīng)用體量的增大，需要考慮的事情也會越多，并不是簡單“1+1=2”的問題。

目前，Service Mesh 大規(guī)模落地的方案還是不太理想。Service Mesh 落地試點之后，團隊需要花大量的精力投入到 Service Mesh 性能、安全、穩(wěn)定性以及與現(xiàn)有基礎(chǔ)能力融合等方面。

基礎(chǔ)設(shè)施層下沉到 Sidecar 意味著分工越來越細(xì)，那么治理面就要更加完備，引進市場上的開源產(chǎn)品只是解決了一些通用性的問題，和公司現(xiàn)有基礎(chǔ)能力的適配，流程的整合，組織的匹配這些問題都需要一一解決。以順豐科技為例，企業(yè)研發(fā)流程要求傳遞和兼容不同的流量標(biāo)識，但開源產(chǎn)品里并沒有。

各種原因都導(dǎo)致企業(yè)在接入 Service Mesh 時，通常要投入很大精力做二次開發(fā)，而最初可能十幾個人的投入，經(jīng)過一段時間后也會演變?yōu)槌杀締栴}。像順豐云原生平臺的投入也還在增加，預(yù)計到今年底小組人數(shù)將達到三四十人左右。

這也是阻礙 Service Mesh 全面落地的重要因素。對于中小企業(yè)來說，系統(tǒng)數(shù)量、人力資源可能沒有那么多，更需要認(rèn)真評估在 Service Mesh 上做投入是否劃算。根據(jù)陳煥東在順豐科技內(nèi)的測算，Service Mesh 需要落地 200+ 系統(tǒng)才能使 ROI 達到平衡。陳煥東給中小企業(yè)的建議是，可以考慮“傳統(tǒng)微服務(wù)框架 +Service Mesh”的混合部署模式，等業(yè)務(wù)量上來后再慢慢遷移。

此外，有一點很重要，就是 Service Mesh 對基礎(chǔ)設(shè)施團隊是有一定要求的。像順豐內(nèi)部技術(shù)棧是 Java 為主，Go、Python 為輔，云原生技術(shù)研發(fā)和推廣需要稀缺的云原生技術(shù)人才。同時順豐內(nèi)部存在不少老系統(tǒng)需要長期維護，這要求整個基礎(chǔ)設(shè)施團隊需要對公司現(xiàn)有的技術(shù)棧非常熟悉，又對云原生產(chǎn)品有深刻的理解。

當(dāng)然在實際操作中，基礎(chǔ)設(shè)施團隊也會走一些彎路。比如很多團隊更多從技術(shù)角度去開發(fā) Service  Mesh 的相關(guān)功能，并沒有結(jié)合公司的業(yè)務(wù)研發(fā)習(xí)慣和治理流程，這也加大了推廣的難度。

還有一些內(nèi)部的系統(tǒng)經(jīng)過長年積累，技術(shù)棧非常多，各部門的使用習(xí)慣完全不一樣，要求業(yè)務(wù)研發(fā)按照某個維度進行改造并不現(xiàn)實。Service Mesh 使用還需要寫 YAML 文件，這對非 Service Mesh 專業(yè)的業(yè)務(wù)團隊來說是非常大的心智負(fù)擔(dān)。諸如此類都是落地過程中存在的挑戰(zhàn)。

總之，Service Mesh 在技術(shù)上比較依賴基礎(chǔ)設(shè)施，組織上還需要公司各個研發(fā)部門達成共識。順豐科技是成立了囊括各個研發(fā)部門技術(shù)骨干的技術(shù)委員會，通過這個委員會做標(biāo)準(zhǔn)化的推廣和新技術(shù)的引進和落地。

楊定朝表示，團隊并不是必須要實施 Service Mesh 的。Service Mesh 的使用代表著隱藏的技術(shù)底層越來越深，會增加業(yè)務(wù)研發(fā)的問題定位難度。另外，有些場景并不一定適合 Service Mesh，不恰當(dāng)?shù)氖褂貌粫玫揭庀胫械男Ч?/p>

結(jié)束語

“接入 Service Mesh，對我們云原生技術(shù)的發(fā)展有一個很好的承上啟下的作用?！标悷|表示。

目前，順豐科技將順豐云原生平臺在內(nèi)部“開源”，希望先通過“內(nèi)源”的方式吸引其他業(yè)務(wù)部門一起協(xié)同共建?；A(chǔ)架構(gòu)團隊未來會以強組織管理和項目化運作兩種模式展開工作。

今年下半年，順豐科技將在 Service Mesh 研發(fā)提效方面持續(xù)投入，支持在線調(diào)測、環(huán)境隔離、低成本創(chuàng)新、跨集群通信、認(rèn)證鑒權(quán) Mesh、中間件 Mesh 等功能。業(yè)務(wù)連續(xù)性保障方面，Service Mesh 會聚焦在容災(zāi)多活、應(yīng)用防護、混沌工程、問題排查和全域流量調(diào)度等精細(xì)化運維場景。

“我們的原則就是要先在一些業(yè)務(wù)單位試點，確實能達到業(yè)務(wù)預(yù)期、帶來業(yè)務(wù)價值后，才會進行大規(guī)模推廣?！标悷|說道。面對未來的研發(fā)規(guī)劃，團隊上下對基礎(chǔ)設(shè)施層帶來的改變拭目以待。

采訪嘉賓：

陳煥東，順豐科技研發(fā)平臺中心基礎(chǔ)架構(gòu)總工程師

楊定朝，順豐科技研發(fā)平臺中心后端高級研發(fā)工程師