一、前言

海管家是一家業務和服務遍布全球的國際物流 ToB SaaS 公司。

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

目前海管家主要以貨代操作系統和國際物流數據服務平臺作為服務底座，形成了以可視化、電子單證發送、SaaS貨代操作系統、跨境業務系統、獲客和IM工具為主的SaaS產品矩陣，并提供在線報關、線上代訂艙（E-BOOKING）等公共物流服務。

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

云計算是 SaaS 發展的根基。在云原生帶來的全云開發新趨勢下，下一代 SaaS 技術方向將向何處演進？本文將通過海管家物流SaaS基于容器服務和北極星（Polaris Mesh）[1][2]的實踐案例，分享以 Kubernetes 為基礎的云原生架構如何助力海管家物流 SaaS 實現更加穩定、可靠的服務，并進一步幫助企業優化資源和人力成本。

二、業務增長與研發效能的挑戰

可以預想的，隨著海管家 SaaS 業務的上線，注冊認證用戶呈現出了爆發式的增長，用戶的使用場景也不斷擴大。在這個過程中，SaaS 的用戶使用體驗變得愈發重要，如何在用戶規模高速增長的同時可以保證 SaaS 的穩定性、敏捷性， SaaS 的微服務開發效率如何保證，這些都給研發團隊帶來了一定的挑戰。

2.1 業務迭代實效變慢、開發效率變低

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

海管家 · 開發架構演進示意圖

2.2 業務架構與技術架構能力不匹配

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

海管家 · 業務架構示意圖 在市場需求的快速變化下，產品功能創新和迭代效率問題也是對技術架構的一大挑戰。

三、微服務治理探索的實踐歷程

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

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

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

海管家 · 新老架構平滑遷移示意圖

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

3.3 微服務玩法探索

3.3.1 環境隔離

在實際的開發過程中，一個微服務架構系統下的不同微服務可能是由多個團隊進行開發與維護的，每個團隊只需關注所屬的一個或多個微服務，而各個團隊維護的微服務之間可能存在相互調用關系。如果一個團隊在開發其所屬的微服務，調試的時候需要驗證完整的微服務調用鏈路。此時需要依賴其他團隊的微服務，如何部署開發聯調環境就會遇到以下問題：

1.如果所有團隊都使用同一套開發聯調環境，那么一個團隊的測試微服務實例無法正常運行時，會影響其他依賴該微服務的應用也無法正常運行。

2.如果每個團隊有單獨的一套開發聯調環境，那么每個團隊不僅需要維護自己環境的微服務應用，還需要維護其他團隊環境的自身所屬微服務應用，效率大大降低。同時，每個團隊都需要部署完整的一套微服務架構應用，成本也隨著團隊數的增加而大大上升。

此時可以使用測試環境路由的架構來幫助部署一套運維簡單且成本較低開發聯調環境。測試環境路由是一種基于服務路由的環境治理策略，核心是維護一個穩定的基線環境作為基礎環境，測試環境僅需要部署需要變更的微服務。多測試環境有兩個基礎概念，如下所示：

1.基線環境（Baseline Environment）: 完整穩定的基礎環境，是作為同類型下其他環境流量通路的一個兜底可用環境，用戶應該盡量保證基線環境的完整性、穩定性。

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

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

雖然測試環境路由是一個相對成熟的開發測試環境解決方案，但是能夠開箱即用的生產開發框架卻不多，往往需要開發者二次開發相應的功能。因此需要一個相對完善的解決方案來幫助實現測試環境路由，簡化開發難度并提升開發效率。

基于上述的想法，海管家有十幾條產品線，并且產品線之間存在著錯綜復雜的關聯，并線開發、聯調等問題一直被產研團隊吐槽和詬病。

基于北極星微服務引擎的能力，結合Spring Cloud Tencent 的開發框架，與社區進行合作開發以下的方案，測試環境路由的樣例實現以下圖為例，一共有兩個測試環境以及一個基線環境。流量從端到端會依次經過以下組件：App（前端） -> 網關 -> 通行證中心 -> 訂單交易中心 -> 支付結算中心。

海管家 · 測試環境路由示意圖

為了達到測試環境路由的能力，開發工作需要做三件事情：

1.服務實例染色（標識實例屬于哪個測試環境）

2.流量染色（標識請求應該被轉發到哪個測試環境）

3.服務路由

a.網關根據請求的目標測試環境標簽轉發到對應的目標測試環境的用戶中心。

b.服務調用時，優先轉發到同測試環境下的目標服務實例，如果同測試環境下沒有服務實例則轉發到基線環境。

其中在流量染色的環節，我們結合著Spring Cloud Tencent的開發組件的能力，使用客戶端染色 + 網關動態染色。

l客戶端染色 （推薦）

如下圖所示，在客戶端發出的 HTTP 請求里，新增X-Polaris-Metadata-Transitive-featureenv=v2請求頭即可實現染色。該方式是讓開發者在請求創建的時候根據業務邏輯進行流量染色。

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

l網關動態染色（推薦）

動態染色是開發者配置一定的染色規則，讓流量經過網關時自動染色，使用起來相當方便。例如把區域編號 area_code=shanghai 用戶的請求都轉發到 feature env v2 環境，把區域編號 area_code=beijing 的用戶的請求都轉發到 feature env v3環境。只需要配置一條染色規則即可實現。

海管家 · 網關動態染色示意圖

3.3.2 灰度發布

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

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

l用戶體驗不能中斷的業務

l微服務業務的存在關聯關系的多個微服務的特性變更

可以基于域名分離的方式實現全鏈路灰度，通過不同的域名區分灰度環境和穩定環境。前端客戶的請求通過灰度域名訪問到灰度版本的服務，通過穩定域名訪問到穩定版本的服務。

海管家 · 灰度發布示意圖

灰度請求通過灰度域名接入到網關，網關通過域名識別到灰度請求后，將請求優先路由到灰度版本的服務，并通過請求頭的方式進行灰度染色。后續微服務之間，服務框架通過請求頭識別到灰度請求，會優先將請求路由到灰度版本服務，如果尋址不到灰度版本，則路由到穩定版本服務。

對于全鏈路灰度發布，我們不僅需要將流量進行灰度，還需要將后端的數據庫、緩存、消息隊列等等基礎服務也支持灰度，這里還需要跟北極星社區進行更加深度的合作和開發。

四、關于未來

『看的遠，走的穩』，即看得遠，映射到平臺化；走的穩，映射到系統重構，已然成為海管家的重要技術戰略。我們將繼續進行云原生架構升級探索，持續提高SaaS業務系統的穩定性和敏捷性，隨著對云原生架構的理解的深入，我們將繼續與騰訊云、北極星團隊進一步的探索和研究，給我們的客戶創造更多的價值。

審核編輯 ：李倩