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

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

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

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

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

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

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

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

選擇合適自己的

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

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

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

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

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

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

最后，接入要讓業(yè)務無感知。業(yè)務非常抗拒修改自己的程序，即使修改也不希望現(xiàn)有的東西有改變。但現(xiàn)在很多開源產品的客戶端主要是 Java，兩三年就有一個大的版本迭代，基礎架構團隊不希望因此產生兼容性問題。直接使用開源產品的后果之一就是團隊要一直做適配。

基于以上考慮，團隊在數(shù)據(jù)面上選擇了更適合自身需求的 MOSN。MOSN 用 Go 編寫，有與分布式 Runtime 融合的能力，同時衍生產品 Layotto 在向下對接了各種基礎設施的同時，還向上為應用提供了各種具有分布式能力的標準 API，能夠將各種通用能力下沉到 Sidecar 里。

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

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

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

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

“我們的初衷和 Polaris 很像，也是希望提供統(tǒng)一的治理流量界面，用戶不需要關心底層的技術棧，只需接入即可使用。可惜的是，我們已經(jīng)有自己對應的技術棧了，Polaris 的 SDK 流量治理技術棧與我們的不相符?！表権S科技基礎架構總工程師陳煥東說道。

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

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

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

平臺架構圖

方案落地

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

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

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

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

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

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

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

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

帶來了哪些改變

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

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

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

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

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

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

產品全景圖

大規(guī)模落地之難

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

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

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

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

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

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

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

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

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

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

結束語

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

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

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

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

采訪嘉賓：

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

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