一、前言

海管家是一家業(yè)務(wù)和服務(wù)遍布全球的國際物流 ToB SaaS 公司。

公司融合運(yùn)用AI、大數(shù)據(jù)、云計(jì)算等前沿技術(shù)，研發(fā)完成物流領(lǐng)域多個變革性產(chǎn)品，為港口、船公司、貨代企業(yè)、船代企業(yè)提供系統(tǒng)解決方案和數(shù)據(jù)對接服務(wù)，在無紙化碼頭系統(tǒng)領(lǐng)域有豐富的項(xiàng)目經(jīng)驗(yàn)，旗下的預(yù)配艙單發(fā)送系統(tǒng)，海外艙單發(fā)送系統(tǒng)、E-BOOKING 系統(tǒng) 、港口業(yè)務(wù)風(fēng)控推送系統(tǒng)、智能貨代SaaS（貨代企業(yè)操作系統(tǒng)）、全國貨運(yùn)車輛定位系統(tǒng)已實(shí)現(xiàn)國際物流信息化服務(wù)的全方位覆蓋，客戶涵蓋物流、生產(chǎn)制造商、外貿(mào)、跨境等行業(yè)，服務(wù)客戶數(shù)量達(dá)百萬級，遍布全國各地。

目前海管家主要以貨代操作系統(tǒng)和國際物流數(shù)據(jù)服務(wù)平臺作為服務(wù)底座，形成了以可視化、電子單證發(fā)送、SaaS貨代操作系統(tǒng)、跨境業(yè)務(wù)系統(tǒng)、獲客和IM工具為主的SaaS產(chǎn)品矩陣，并提供在線報(bào)關(guān)、線上代訂艙（E-BOOKING）等公共物流服務(wù)。

海管家系統(tǒng)整體基于微服務(wù)架構(gòu)之上，隨著越來越多新的產(chǎn)品發(fā)布，及其產(chǎn)品之間的依賴越來越多，在服務(wù)治理上也面臨越來越大的挑戰(zhàn)。在此基礎(chǔ)上海管家期望引入統(tǒng)一的微服務(wù)引擎來解決安全防護(hù)、版本管理、灰度、彈性、流量控制、配置管理、故障容錯、服務(wù)發(fā)現(xiàn)、服務(wù)治理等一系列問題，同時也期望兼具有更好的擴(kuò)展能力以應(yīng)對特殊定制的需求。

云計(jì)算是 SaaS 發(fā)展的根基。在云原生帶來的全云開發(fā)新趨勢下，下一代 SaaS 技術(shù)方向?qū)⑾蚝翁幯葸M(jìn)？本文將通過海管家物流SaaS基于容器服務(wù)和北極星（Polaris Mesh）[1][2]的實(shí)踐案例，分享以 Kubernetes 為基礎(chǔ)的云原生架構(gòu)如何助力海管家物流 SaaS 實(shí)現(xiàn)更加穩(wěn)定、可靠的服務(wù)，并進(jìn)一步幫助企業(yè)優(yōu)化資源和人力成本。

二、業(yè)務(wù)增長與研發(fā)效能的挑戰(zhàn)

可以預(yù)想的，隨著海管家 SaaS 業(yè)務(wù)的上線，注冊認(rèn)證用戶呈現(xiàn)出了爆發(fā)式的增長，用戶的使用場景也不斷擴(kuò)大。在這個過程中，SaaS 的用戶使用體驗(yàn)變得愈發(fā)重要，如何在用戶規(guī)模高速增長的同時可以保證 SaaS 的穩(wěn)定性、敏捷性， SaaS 的微服務(wù)開發(fā)效率如何保證，這些都給研發(fā)團(tuán)隊(duì)帶來了一定的挑戰(zhàn)。

2.1 業(yè)務(wù)迭代實(shí)效變慢、開發(fā)效率變低

隨著SaaS用戶場景需求的增加，越來越多的功能等待發(fā)開、發(fā)布上線，對迭代頻率的要求越來越高，但由于 SaaS 服務(wù)技術(shù)架構(gòu)偏向于傳統(tǒng)的應(yīng)用開發(fā)方式，不能夠像微服務(wù)、模塊化架構(gòu)一樣，進(jìn)行多線并行開發(fā)，同時對于應(yīng)用發(fā)布，缺少灰度發(fā)布能力，為了保障業(yè)務(wù)穩(wěn)定性，每次發(fā)布客戶只能選擇在凌晨的業(yè)務(wù)低峰期進(jìn)行，開發(fā)、運(yùn)維、測試同學(xué)苦不堪言，對于發(fā)版無損發(fā)布能力的需求聲音越來越大。

海管家 · 開發(fā)架構(gòu)演進(jìn)示意圖

2.2 業(yè)務(wù)架構(gòu)與技術(shù)架構(gòu)能力不匹配

疫情物流承壓、貨代數(shù)字化成大趨勢。但數(shù)字化如何在國際物流落地，海管家提出了自己的標(biāo)準(zhǔn)。我們認(rèn)為，國際物流跨境角色多、鏈條長，一個提供國際貨代服務(wù)的 SaaS 公司如果要做數(shù)字化，一條產(chǎn)品線至少要提升20%到30%的效能，才可實(shí)現(xiàn)商業(yè)的快速復(fù)制、擴(kuò)張以及落地，進(jìn)而才能發(fā)展為 SaaS 公司的核心業(yè)務(wù)線。 而且除了效能問題，國際貨代的SaaS服務(wù)的本質(zhì)其實(shí)是要解決信息、數(shù)據(jù)和相關(guān)業(yè)務(wù)的標(biāo)準(zhǔn)化問題。而這些需要行業(yè)各相關(guān)角色的協(xié)同，單個公司靠自己無法解決標(biāo)準(zhǔn)化問題，作為一家 SaaS 服務(wù)商，海管家選擇的發(fā)展路徑是跟著行業(yè)節(jié)奏逐點(diǎn)擊破、連點(diǎn)成線，最終達(dá)到平臺的融合。 未來國際物流SaaS平臺企業(yè)一定會以『數(shù)據(jù)服務(wù)化』、『全渠道服務(wù)化』和『新業(yè)務(wù)拓展敏捷化』的交融與創(chuàng)新為發(fā)展方向，這對團(tuán)隊(duì)的業(yè)務(wù)架構(gòu)能力與技術(shù)架構(gòu)能力提出來比較高的要求。

海管家 · 業(yè)務(wù)架構(gòu)示意圖 在市場需求的快速變化下，產(chǎn)品功能創(chuàng)新和迭代效率問題也是對技術(shù)架構(gòu)的一大挑戰(zhàn)。

三、微服務(wù)治理探索的實(shí)踐歷程

3.1 云原生技術(shù)發(fā)展在數(shù)字時代，隨著市場趨于多樣化，企業(yè)間競爭不斷加劇，軟件架構(gòu)的優(yōu)化是未來企業(yè)獲取競爭優(yōu)勢的重要途徑。 云原生是先進(jìn)軟件架構(gòu)技術(shù)和管理方法的思想集合，通過容器、微服務(wù)、持續(xù)交付等一系列技術(shù)，實(shí)現(xiàn)了信息系統(tǒng)由煙囪狀、重裝置和低效率的架構(gòu)向分布式、小型化和自動化的新一代軟件架構(gòu)的轉(zhuǎn)變。同時，云原生架構(gòu)具備松耦合、分布式、高韌性三大特點(diǎn)，能夠以業(yè)務(wù)應(yīng)用為中心，充分利用云計(jì)算優(yōu)勢，實(shí)現(xiàn)敏捷交付、價(jià)值聚焦的核心目標(biāo)。 同時《云計(jì)算白皮書（2022年）》指出，完整的支撐應(yīng)用云原生化構(gòu)建的全生命周期技術(shù)鏈已經(jīng)形成，隨著云原生技術(shù)和能力不斷完善，其將驅(qū)動企業(yè)組織和流程、架構(gòu)和設(shè)計(jì)、技術(shù)和基礎(chǔ)設(shè)施等IT要素的全面升級。3.2 業(yè)務(wù)架構(gòu)微服務(wù)化這些現(xiàn)狀的解法和云原生架構(gòu)帶來的核心能力不謀而合。海管家將主要的業(yè)務(wù)應(yīng)用，包括前端 Web 容器、網(wǎng)關(guān)、后端微服務(wù)、大數(shù)據(jù)等等通過 Kubernetes 集群部署，以云原生的方式幫助業(yè)務(wù)快速迭代，靈活響應(yīng)商業(yè)需求。3.2.1 微服務(wù)治理平臺選型對于微服務(wù)的治理、改造，海管家的團(tuán)隊(duì)更加看重的是改造的復(fù)雜度、侵入性、穩(wěn)定性等方面，對目前市面上的幾款開源產(chǎn)品進(jìn)行調(diào)研以及和相關(guān)團(tuán)隊(duì)進(jìn)行深入的溝通，經(jīng)過大量的預(yù)研后，我們最終選擇了北極星（Polaris Mesh），主要看重一下幾個特性：強(qiáng)大的控制面、無侵入、穩(wěn)定性高、豐富的可觀測能力、混合云支持、兼容Kubernetes等。 基于北極星（Polaris Mesh）的服務(wù)管理、流量管理、故障容錯、配置管理和可觀測性五大功能，以及容器服務(wù)的基礎(chǔ)運(yùn)行能力，我們重新架構(gòu)了業(yè)務(wù)的技術(shù)架構(gòu)如下圖。

海管家 · 服務(wù)化架構(gòu)示意圖3.2.2 微服務(wù)開發(fā)框架選型與容器化改造幾乎同步進(jìn)行的是對微服務(wù)架構(gòu)的統(tǒng)一。在此之前，海管家的各個業(yè)務(wù)單元多種技術(shù)棧并存，彼此之間相互通訊復(fù)雜度高，項(xiàng)目成員的交接往往要耗費(fèi)巨大的精力，極大程度上阻礙了業(yè)務(wù)發(fā)展的進(jìn)展，因此微服務(wù)架構(gòu)統(tǒng)一勢在必行。 海管家經(jīng)歷了 2 年多時間完成了這一項(xiàng)艱巨的工作，雖然投入精力巨大，但收益很大，在技術(shù)框架上都有統(tǒng)一的標(biāo)準(zhǔn)可以遵循，各團(tuán)隊(duì)之間統(tǒng)一技術(shù)棧，研發(fā)效率成倍提升。 關(guān)系到未來多年的技術(shù)戰(zhàn)略，在微服務(wù)架構(gòu)的選型上，開放性、成熟度、普適性標(biāo)準(zhǔn)缺一不可，考慮到海管家以 Java 為主要開發(fā)語言，Spring Cloud Tencent 就成為了微服務(wù)框架的新的選擇。同時海管家也將自研的基于Spring Cloud + Dubbo開發(fā)標(biāo)準(zhǔn)的基礎(chǔ)服務(wù)框架與Spring Cloud Tencent、Polaris Mesh進(jìn)行兼容整合。

海管家 · 微服務(wù)開發(fā)框架SCT功能3.2.3 老項(xiàng)目與新架構(gòu)之間的平滑演進(jìn)而架構(gòu)的變更需要有一個演進(jìn)過程。云原生其實(shí)源自于PaaS，所以在應(yīng)用云原生架構(gòu)的時候，也現(xiàn)在PaaS層遇到了平滑演進(jìn)的問題。如何讓產(chǎn)品和開發(fā)者即能保留以前的習(xí)慣，同時又能去嘗試新的交付、開發(fā)方式？在傳統(tǒng)的模式中，大家習(xí)慣于交付代碼包，習(xí)慣于基于虛擬機(jī)的運(yùn)維，而云原生時代以容器鏡像作為交付載體，而運(yùn)行實(shí)例則是鏡像實(shí)例化容器。 無論是基于傳統(tǒng)架構(gòu)的PaaS，還是基于kubernetes的PaaS，實(shí)現(xiàn)主要操作都是一樣的，包括：建站、發(fā)布、重啟、擴(kuò)容/縮容、下線等等，實(shí)現(xiàn)兩套無疑非常浪費(fèi)資源，也增加了維護(hù)成本，對于產(chǎn)品和開發(fā)者來說干的事情是一樣的，所以我們用kubernetes實(shí)現(xiàn)了所有公共部分，包括：統(tǒng)一元數(shù)據(jù)、統(tǒng)一運(yùn)維操作、統(tǒng)一資源抽象。在產(chǎn)品層和運(yùn)維方式上，提供兩種控制面。 在我們進(jìn)行技術(shù)架構(gòu)演技的過程中，會面臨新老系統(tǒng)并存的問題，老（遺留）系統(tǒng)的架構(gòu)技術(shù)棧老舊，改造、重構(gòu)成本較大，我們通過Mesh的方式統(tǒng)一解決這個問題。新系統(tǒng)，Mesh是Pod里的Sidecar，但老系統(tǒng)因?yàn)橐话闱闆r下是沒有運(yùn)行在kubernetes上，所以不支持Pod和Sidecar的運(yùn)維模式，需要用Java Agent的模式來管理Mesh進(jìn)程，使得Mesh能夠幫助老架構(gòu)下的應(yīng)用完成服務(wù)化改造，并支持新老架構(gòu)下服務(wù)的統(tǒng)一管理。

海管家 · 新老架構(gòu)平滑遷移示意圖

海管家 SaaS 研發(fā)團(tuán)隊(duì)意識到，隨著業(yè)務(wù)發(fā)展的向好，這些挑戰(zhàn)也會也越來越大。在業(yè)務(wù)快速發(fā)展中，既要保證好已有業(yè)務(wù)的穩(wěn)定性，又要快速地迭代新功能，并且需要保證開發(fā)的效率并不會隨著業(yè)務(wù)增長而大幅降低，在新的微服務(wù)體系下，我們的業(yè)務(wù)開發(fā)人員更加專注在業(yè)務(wù)本身，從繁雜的技術(shù)棧中脫離出來，也就能解決兩大關(guān)鍵性的問題：系統(tǒng)穩(wěn)定性、研發(fā)效率。

3.3 微服務(wù)玩法探索

3.3.1 環(huán)境隔離

在實(shí)際的開發(fā)過程中，一個微服務(wù)架構(gòu)系統(tǒng)下的不同微服務(wù)可能是由多個團(tuán)隊(duì)進(jìn)行開發(fā)與維護(hù)的，每個團(tuán)隊(duì)只需關(guān)注所屬的一個或多個微服務(wù)，而各個團(tuán)隊(duì)維護(hù)的微服務(wù)之間可能存在相互調(diào)用關(guān)系。如果一個團(tuán)隊(duì)在開發(fā)其所屬的微服務(wù)，調(diào)試的時候需要驗(yàn)證完整的微服務(wù)調(diào)用鏈路。此時需要依賴其他團(tuán)隊(duì)的微服務(wù)，如何部署開發(fā)聯(lián)調(diào)環(huán)境就會遇到以下問題：

1.如果所有團(tuán)隊(duì)都使用同一套開發(fā)聯(lián)調(diào)環(huán)境，那么一個團(tuán)隊(duì)的測試微服務(wù)實(shí)例無法正常運(yùn)行時，會影響其他依賴該微服務(wù)的應(yīng)用也無法正常運(yùn)行。

2.如果每個團(tuán)隊(duì)有單獨(dú)的一套開發(fā)聯(lián)調(diào)環(huán)境，那么每個團(tuán)隊(duì)不僅需要維護(hù)自己環(huán)境的微服務(wù)應(yīng)用，還需要維護(hù)其他團(tuán)隊(duì)環(huán)境的自身所屬微服務(wù)應(yīng)用，效率大大降低。同時，每個團(tuán)隊(duì)都需要部署完整的一套微服務(wù)架構(gòu)應(yīng)用，成本也隨著團(tuán)隊(duì)數(shù)的增加而大大上升。

此時可以使用測試環(huán)境路由的架構(gòu)來幫助部署一套運(yùn)維簡單且成本較低開發(fā)聯(lián)調(diào)環(huán)境。測試環(huán)境路由是一種基于服務(wù)路由的環(huán)境治理策略，核心是維護(hù)一個穩(wěn)定的基線環(huán)境作為基礎(chǔ)環(huán)境，測試環(huán)境僅需要部署需要變更的微服務(wù)。多測試環(huán)境有兩個基礎(chǔ)概念，如下所示：

1.基線環(huán)境（Baseline Environment）: 完整穩(wěn)定的基礎(chǔ)環(huán)境，是作為同類型下其他環(huán)境流量通路的一個兜底可用環(huán)境，用戶應(yīng)該盡量保證基線環(huán)境的完整性、穩(wěn)定性。

2.測試環(huán)境（Feature Environment）: 一種臨時環(huán)境，僅可能為開發(fā)/測試環(huán)境類型，測試環(huán)境不需要部署全鏈路完整的服務(wù)，而是僅部署本次有變更的服務(wù)，其他服務(wù)通過服務(wù)路由的方式復(fù)用基線環(huán)境服務(wù)資源。

部署完成多測試環(huán)境后，開發(fā)者可以通過一定的路由規(guī)則方式，將測試請求打到不同的測試環(huán)境，如果測試環(huán)境沒有相應(yīng)的微服務(wù)處理鏈路上的請求，那么會降級到基線環(huán)境處理。因此，開發(fā)者需要將開發(fā)新測試的微服務(wù)部署到對應(yīng)的測試環(huán)境，而不需要更新或不屬于開發(fā)者管理的微服務(wù)則復(fù)用基線環(huán)境的服務(wù)，完成對應(yīng)測試環(huán)境的測試。

雖然測試環(huán)境路由是一個相對成熟的開發(fā)測試環(huán)境解決方案，但是能夠開箱即用的生產(chǎn)開發(fā)框架卻不多，往往需要開發(fā)者二次開發(fā)相應(yīng)的功能。因此需要一個相對完善的解決方案來幫助實(shí)現(xiàn)測試環(huán)境路由，簡化開發(fā)難度并提升開發(fā)效率。

基于上述的想法，海管家有十幾條產(chǎn)品線，并且產(chǎn)品線之間存在著錯綜復(fù)雜的關(guān)聯(lián)，并線開發(fā)、聯(lián)調(diào)等問題一直被產(chǎn)研團(tuán)隊(duì)吐槽和詬病。

基于北極星微服務(wù)引擎的能力，結(jié)合Spring Cloud Tencent 的開發(fā)框架，與社區(qū)進(jìn)行合作開發(fā)以下的方案，測試環(huán)境路由的樣例實(shí)現(xiàn)以下圖為例，一共有兩個測試環(huán)境以及一個基線環(huán)境。流量從端到端會依次經(jīng)過以下組件：App（前端） -> 網(wǎng)關(guān) -> 通行證中心 -> 訂單交易中心 -> 支付結(jié)算中心。

海管家 · 測試環(huán)境路由示意圖

為了達(dá)到測試環(huán)境路由的能力，開發(fā)工作需要做三件事情：

1.服務(wù)實(shí)例染色（標(biāo)識實(shí)例屬于哪個測試環(huán)境）

2.流量染色（標(biāo)識請求應(yīng)該被轉(zhuǎn)發(fā)到哪個測試環(huán)境）

3.服務(wù)路由

a.網(wǎng)關(guān)根據(jù)請求的目標(biāo)測試環(huán)境標(biāo)簽轉(zhuǎn)發(fā)到對應(yīng)的目標(biāo)測試環(huán)境的用戶中心。

b.服務(wù)調(diào)用時，優(yōu)先轉(zhuǎn)發(fā)到同測試環(huán)境下的目標(biāo)服務(wù)實(shí)例，如果同測試環(huán)境下沒有服務(wù)實(shí)例則轉(zhuǎn)發(fā)到基線環(huán)境。

其中在流量染色的環(huán)節(jié)，我們結(jié)合著Spring Cloud Tencent的開發(fā)組件的能力，使用客戶端染色 + 網(wǎng)關(guān)動態(tài)染色。

l客戶端染色 （推薦）

如下圖所示，在客戶端發(fā)出的 HTTP 請求里，新增X-Polaris-Metadata-Transitive-featureenv=v2請求頭即可實(shí)現(xiàn)染色。該方式是讓開發(fā)者在請求創(chuàng)建的時候根據(jù)業(yè)務(wù)邏輯進(jìn)行流量染色。

海管家 · 客戶端染色示意圖

l網(wǎng)關(guān)動態(tài)染色（推薦）

動態(tài)染色是開發(fā)者配置一定的染色規(guī)則，讓流量經(jīng)過網(wǎng)關(guān)時自動染色，使用起來相當(dāng)方便。例如把區(qū)域編號 area_code=shanghai 用戶的請求都轉(zhuǎn)發(fā)到 feature env v2 環(huán)境，把區(qū)域編號 area_code=beijing 的用戶的請求都轉(zhuǎn)發(fā)到 feature env v3環(huán)境。只需要配置一條染色規(guī)則即可實(shí)現(xiàn)。

海管家 · 網(wǎng)關(guān)動態(tài)染色示意圖

3.3.2 灰度發(fā)布

隨著業(yè)務(wù)的發(fā)展、客戶需求的增多、行業(yè)應(yīng)用場景的多樣化，產(chǎn)線平均每天幾十次發(fā)布。為了不影響白天業(yè)務(wù)高峰以及用戶群體的特殊性（面對B端的SaaS系統(tǒng)），每次較大發(fā)版只能選擇在凌晨業(yè)務(wù)低峰期進(jìn)行，想象一下如果產(chǎn)品、研發(fā)、運(yùn)維人員、中臺支持人員每次都集中在晚上發(fā)布，太不人性化（移動互聯(lián)網(wǎng)的時代，誰還玩停機(jī)維護(hù)那一套呢？）；如果晚上選擇較少的人參與發(fā)布，那么當(dāng)出問題的時候會『耽誤救治』的最佳時機(jī)，故障責(zé)任也不好劃分。

北極星，在灰度發(fā)布這方面給我們提供了很大的支持和幫助，能夠滿足海管家現(xiàn)階段灰度發(fā)布的場景：

l用戶體驗(yàn)不能中斷的業(yè)務(wù)

l微服務(wù)業(yè)務(wù)的存在關(guān)聯(lián)關(guān)系的多個微服務(wù)的特性變更

可以基于域名分離的方式實(shí)現(xiàn)全鏈路灰度，通過不同的域名區(qū)分灰度環(huán)境和穩(wěn)定環(huán)境。前端客戶的請求通過灰度域名訪問到灰度版本的服務(wù)，通過穩(wěn)定域名訪問到穩(wěn)定版本的服務(wù)。

海管家 · 灰度發(fā)布示意圖

灰度請求通過灰度域名接入到網(wǎng)關(guān)，網(wǎng)關(guān)通過域名識別到灰度請求后，將請求優(yōu)先路由到灰度版本的服務(wù)，并通過請求頭的方式進(jìn)行灰度染色。后續(xù)微服務(wù)之間，服務(wù)框架通過請求頭識別到灰度請求，會優(yōu)先將請求路由到灰度版本服務(wù)，如果尋址不到灰度版本，則路由到穩(wěn)定版本服務(wù)。

對于全鏈路灰度發(fā)布，我們不僅需要將流量進(jìn)行灰度，還需要將后端的數(shù)據(jù)庫、緩存、消息隊(duì)列等等基礎(chǔ)服務(wù)也支持灰度，這里還需要跟北極星社區(qū)進(jìn)行更加深度的合作和開發(fā)。

四、關(guān)于未來

『看的遠(yuǎn)，走的穩(wěn)』，即看得遠(yuǎn)，映射到平臺化；走的穩(wěn)，映射到系統(tǒng)重構(gòu)，已然成為海管家的重要技術(shù)戰(zhàn)略。我們將繼續(xù)進(jìn)行云原生架構(gòu)升級探索，持續(xù)提高SaaS業(yè)務(wù)系統(tǒng)的穩(wěn)定性和敏捷性，隨著對云原生架構(gòu)的理解的深入，我們將繼續(xù)與騰訊云、北極星團(tuán)隊(duì)進(jìn)一步的探索和研究，給我們的客戶創(chuàng)造更多的價(jià)值。

審核編輯 ：李倩