8年服務百萬客戶，這家SaaS公司是懂雲原生的

總部位於蘇州的這家國際物流SaaS公司，已經藉助雲原生能力，實現了技術架構的全面升級。

海管家，這家創立於2015年的年輕科技公司，不到8年時間，將服務的客戶數量做到超百萬級，遍佈全球各地，成長速度讓人咂舌。

得益於公司在AI、大資料、雲端計算等技術領域的超前佈局，海管家率先在物流領域推出多個變革性產品，為港口、船公司、貨代企業、船代企業提供領先的系統解決方案和資料對接服務，在無紙化碼頭系統領域有豐富的專案經驗。

目前，海管家的產品矩陣涵蓋了視覺化、電子單證傳送、SaaS貨代作業系統、跨境業務系統、獲客和IM工具為主的綜合性SaaS服務，並提供線上報關、線上代訂艙（E-BOOKING）等公共物流服務。

那麼，海管家又是如何通過雲原生，在物流 SaaS領域實現業務創新，為客戶提供更加穩定、可靠的服務的，並進一步幫助企業優化資源和人力成本的呢？帶著這些疑問，我們深入帶你瞭解這家企業的技術變革歷程。

業務增長太快，研發效能如何解決？

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

挑戰一，業務迭代實效變慢、開發效率變低

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

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

挑戰二、業務架構與技術架構能力不匹配

還有一個，疫情物流承壓、貨代數字化成大趨勢，但數字化如何在國際物流落地，海管家提出了自己的標準。

“國際物流跨境角色多、鏈條長，一個提供國際貨代服務的 SaaS 公司如果要做數字化，一條產品線至少要提升20%到30%的效能，才可實現商業的快速複製、擴張以及落地，進而才能發展為 SaaS 公司的核心業務線。“海管家CEO金忠國表示。

而且除了效能問題，國際貨代的SaaS服務的本質其實是要解決資訊、資料和相關業務的標準化問題，而這些需要行業各相關角色的協同，單個公司靠自己無法解決標準化問題。

作為一家 SaaS 服務商，海管家選擇的發展路徑是跟著行業節奏逐點選破、連點成線，最終達到平臺的融合。

可以預計，未來國際物流SaaS平臺企業一定會以『資料服務化』、『全渠道服務化』和『新業務拓展敏捷化』的交融與創新為發展方向，這對團隊的業務架構能力與技術架構能力提出來比較高的要求。

海管家 · 業務架構示意圖

此外，在市場需求的快速變化下，產品功能創新和迭代效率問題也是對技術架構的一大挑戰。

“我們是國內第一批雲住民”

”我們從創業的一開始就基於雲原生，可以說是國內第一批雲住民，上雲用雲就和血液一樣，雲造就了我們，也發展了我們。”海管家技術負責人徐紅維告訴鵝廠技術派。

雲原生，它是先進軟體架構技術和管理方法的思想集合，通過容器、微服務、持續交付等一系列技術，實現了資訊系統由煙囪狀、重灌置和低效率的架構向分散式、小型化和自動化的新一代軟體架構的轉變。

同時，雲原生架構具備鬆耦合、分散式、高韌性三大特點，能夠以業務應用為中心，充分利用雲端計算優勢，實現敏捷交付、價值聚焦的核心目標。

“有沒有發現，上述問題及現狀的解法和雲原生架構帶來的核心能力不謀而合。”

“因此，海管家很早就篤定要將主要的業務應用，包括前端 Web 容器、閘道器、後端微服務、大資料等等通過 Kubernetes 叢集部署，以雲原生的方式幫助業務快速迭代，靈活響應商業需求。”徐紅維補充道。

微服務雖好，可不要“貪杯”哦

微服務治理平臺怎麼選

都在說微服務，但是微服務也要對症下藥。對於微服務的治理、改造，海管家的團隊更加看重的是改造的複雜度、侵入性、穩定性等方面，海管家技術團隊對目前市面上的幾款開源產品進行調研以及和相關團隊進行深入的溝通。

經過大量的預研後，最終選擇了騰訊雲北極星（Polaris Mesh），主要看重一下幾個特性：強大的控制面、無侵入、穩定性高、豐富的可觀測能力、混合雲支援、相容Kubernetes等。

基於北極星（Polaris Mesh）的服務管理、流量管理、故障容錯、配置管理和可觀測性五大功能，以及容器服務的基礎執行能力，海管家重新架構了業務的技術架構如下圖。

海管家 · 服務化架構示意圖

微服務開發框架選型，開放性、成熟度、普適性缺一不可

與容器化改造幾乎同步進行的是對微服務架構的統一。

在此之前，海管家的各個業務單元多種技術棧並存，彼此之間相互通訊複雜度高，專案成員的交接往往要耗費巨大的精力，極大程度上阻礙了業務發展的進展，因此微服務架構統一勢在必行。

海管家經歷了 2 年多時間完成了這一項艱鉅的工作，雖然投入精力巨大，但收益很大，在技術框架上都有統一的標準可以遵循，各團隊之間統一技術棧，研發效率成倍提升。

關係到未來多年的技術戰略，在微服務架構的選型上，開放性、成熟度、普適性標準缺一不可，考慮到海管家以 Java 為主要開發語言，Spring Cloud Tencent 就成為了微服務框架的新的選擇。同時，海管家也將自研的基於Spring Cloud + Dubbo開發標準的基礎服務框架與Spring Cloud Tencent、Polaris Mesh進行相容整合。

海管家 · 微服務開發框架SCT功能

老專案與新架構之間如何平滑演進

架構的變更需要有一個演進過程。雲原生其實源自於PaaS，所以在應用雲原生架構的時候，在PaaS層也遇到了平滑演進的問題。如何讓產品和開發者即能保留以前的習慣，同時又能去嘗試新的交付、開發方式？在傳統的模式中，大家習慣於交付程式碼包，習慣於基於虛擬機器的運維，而云原生時代以容器映象作為交付載體，而執行例項則是映象例項化容器。

無論是基於傳統架構的PaaS，還是基於kubernetes的PaaS，實現主要操作都是一樣的，包括：建站、釋出、重啟、擴容/縮容、下線等等，實現兩套無疑非常浪費資源，也增加了維護成本，對於產品和開發者來說乾的事情是一樣的。所以海管家技術團隊用kubernetes實現了所有公共部分，包括：統一元資料、統一運維操作、統一資源抽象。在產品層和運維方式上，提供兩種控制面。

在進行技術架構演技的過程中，會面臨新老系統並存的問題，老（遺留）系統的架構技術棧老舊，改造、重構成本較大，海管家通過Mesh的方式統一解決這個問題。新系統，Mesh是Pod裡的Sidecar，但老系統因為一般情況下是沒有執行在kubernetes上，所以不支援Pod和Sidecar的運維模式，需要用Java Agent的模式來管理Mesh程序，使得Mesh能夠幫助老架構下的應用完成服務化改造，並支援新老架構下服務的統一管理。

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

海管家 SaaS 研發團隊意識到，隨著業務發展的向好，這些挑戰也會也越來越大。

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

”移動網際網路時代，誰還玩停機維護那一套“

以下是我們在微服務探索過程中的一些經驗分享，希望能夠幫到正在閱讀本文的同行。

第一，環境隔離

在實際的開發過程中，一個微服務架構系統下的不同微服務可能是由多個團隊進行開發與維護的，每個團隊只需關注所屬的一個或多個微服務，而各個團隊維護的微服務之間可能存在相互呼叫關係。

如果一個團隊在開發其所屬的微服務，除錯的時候需要驗證完整的微服務呼叫鏈路，此時需要依賴其他團隊的微服務，如何部署開發聯調環境就會遇到以下問題：

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

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

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

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

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

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

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

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

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

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

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

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

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

3.  服務路由

a.  閘道器根據請求的目標測試環境標籤轉發到對應的目標測試環境的使用者中心。

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

其中在流量染色的環節，海管家結合著Spring Cloud Tencent的開發元件的能力，使用客戶端染色 + 閘道器動態染色。

● 客戶端染色 （推薦）

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

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

● 閘道器動態染色（推薦）

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

海管家 · 閘道器動態染色示意圖

第二，灰度釋出

隨著業務的發展、客戶需求的增多、行業應用場景的多樣化，產線平均每天幾十次釋出。為了不影響白天業務高峰以及使用者群體的特殊性（面對B端的SaaS系統），每次較大發版只能選擇在凌晨業務低峰期進行。

想象一下，如果產品、研發、運維人員、中臺支援人員每次都集中在晚上釋出，太不人性化。

”移動網際網路的時代，誰還玩停機維護那一套呢？“

如果晚上選擇較少的人蔘與釋出，那麼當出問題的時候會『耽誤救治』的最佳時機，故障責任也不好劃分。

北極星，在灰度釋出這方面提供了很大的支援和幫助，能夠滿足海管家現階段灰度釋出的場景：首先使用者體驗不能中斷的業務，其次微服務業務的存在關聯關係的多個微服務的特性變更。

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

海管家 · 灰度釋出示意圖

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

對於全鏈路灰度釋出，海管家不僅需要將流量進行灰度，還需要將後端的資料庫、快取、訊息佇列等等基礎服務也支援灰度，這裡還需要跟北極星社群進行更加深度的合作和開發。

看的遠，才能走的穩

“看的遠，才能走的穩。看得遠對映到平臺化，走的穩對映到系統重構，這已然成為海管家的重要技術戰略。”金忠國說。

“未來，我們將繼續進行雲原生架構升級探索，持續提高SaaS業務系統的穩定性和敏捷性，隨著對雲原生架構的理解的深入，我們將繼續與騰訊雲原生團隊進一步的探索和研究，給客戶創造更多的價值。”