一年一度的 “雙11” 大促中，交易額每年都在刷新，承接這些交易商品的快遞包裹的數量也在成倍增長。這些快速的增長對物流系統帶來了巨大的挑戰，讓物流管理更加敏捷來應對 “雙11” 成為了必須解決的問題。

申通是目前國內最大的物流公司之一，為了解決 “雙11” 的技術挑戰，申通在物流場景引入 IOT、大數據和 AI 等先進和創建的技術手段，通過不斷的技術快速迭代，使得物流資源得到有效的配置，推動了物流行業的發展。

快速的技術迭代帶來了對 IT 基礎設施的挑戰，申通近年來全面將傳統應用切換使用雲原生架構，通過雲原生架構實現應用的快速迭代、穩定的高可用、資源的動態擴縮容來支撐起快速的技術創新。

上雲前，申通使用線下機房作為計算及數據存儲平臺，一到 雙11 資源需求就膨脹，大促之後則閒置浪費；上雲和雲原生化後，幾乎全部的資源都是按量購買，使用雲原生技術快速擴縮容，雙11 前快速擴容，雙11 釋放，真正做到了開箱即用，不產生一天浪費。與去年 雙11 當天相比，今年 11 月 1 到 3 日，在業務量大幅提升的情況下，IT 投入反而降低了 30%。上雲的成效顯著。 

申通雲原生化架構的背景

目前申通正在把業務從 IDC 機房往雲上搬遷，核心業務系統目前已經在雲上完成流量承接。原有 IDC 系統幫助申通早期業務快速發展，但也暴露了不少問題，傳統 IOE 架構，各系統架構的不規範，穩定性，研發效率等都限制了業務發展需求。

隨著雲計算在國內的越發成熟，更多的企業在把自己核心系統往雲上搬，享受雲計算帶來的技術紅利。在跟阿里雲多次技術交流之後最終確定阿里云為唯一合作伙伴，為申通提供穩定的計算、數據處理平臺。

採用雲原生應用架構的訴求/驅動力

快遞公司是非常典型的雲邊一體架構，實操環節很重。大量的業務邏輯下沉到邊緣，所以申通在上雲改造過程中，也在嘗試做雲邊一體化的架構升級。通過雲邊一體，可以讓開發在同一個平臺上面完成雲上業務及邊緣側的業務開發。同時快遞公司還有典型的大數據處理場景，全網每天會新增幾億條掃描數據，需要對這些數據進行實時分析，對數據的處理要求非常高。

之前使用線下機房作為計算及數據存儲平臺的方式，使申通在業務增長過程中遇到了一些瓶頸，比如軟件交付週期過長、大促保障對資源的要求、系統穩定性挑戰等等。而云原生技術就是來解決傳統應用升級緩慢、架構臃腫、不能快速迭代等方面的問題。正是看中了雲原生技術能夠給我們帶來的價值才驅使我們轉為使用公有云作為主要計算資源。

站在企業的角度來看，在這樣一個快速多變的時代，雲原生給我們帶來的價值也正是企業最需要的：

• 唯快不破。這裡的“快”有兩層含義，一是業務應用快速上線，通過雲原生技術可以做到快速上線部署；二是在業務爆發式增長的時候，對資源的需求要做到開箱即用。
• 穩中求變。業務穩定性永遠是第一位。通過監控埋點，業務日誌收集，鏈路監控等手段保證了在快速迭代過程中業務系統的穩定性。
• 節省資源。通過對計算資源的水位監測，結合業務的峰值情況，當發現資源利用率偏低採用降配規格及數量，降低整個資源的費用。相比於一次性投入租建機房及相應的維護費用，使用公有云成本投入更低。
• 開拓創新。採用微服務架構，將之前臃腫的架構進行合理拆分，再結合容器編排的能力做到持續交付。讓企業成功轉型成為一家 DevOps 驅動的公司。

申通雲原生架構歷程

1. 雲原生化技術改造

原架構是基於 Vmware+Oracle 數據庫的架構，通過上阿里雲全面轉型基於 Kubernetes 的雲原生架構體系。應用服務架構重構主要分兩部分：

1）程序代碼改造升級

• 應用容器化

跟虛擬機比起來，容器能同時提供效率和速度的提升，讓其更適合微服務場景。所以我們引入容器技術。通過應用容器化解決了環境不一致的問題，保證應用在開發、測試、生產環境的一致性。

• 微服務改造

原先很多業務是基於 Oracle 的存儲過程及觸發器完成的，系統之間的服務依賴也是走的數據庫 OGG 同步完成。帶來的問題就是系統非常難維護，也非常不穩定。通過引入 Kubernetes 的服務發現來做微服務方案，按業務域進行拆分，讓整個系統更易於維護。

2）引入雲原生數據庫方案

通過引入 OLTP 跟 OLAP 型數據庫，將在線數據與離線分析邏輯拆到兩種數據庫中，取代之前完全依賴 Oracle。特別是在處理歷史數據查詢場景下解決了 Oracle 支持不了的業務需求。

2. 雲原生技術框架設計

整體架構

架構闡述：

• 基礎設施

全部的計算資源取自阿里雲的神龍裸金屬服務器，Kubernetes 搭配神龍服務器能夠獲得更佳性能及更合理的資源利用率，雲上資源可以按量付費，特別適合大促場景，大促結束之後資源使用完釋放。相比於線下自建機房和常備機器，雲上資源操作更方便，管理成本也更低。

• 流量接入 

共有 2 套流量接入，一套是面向公網請求，另外一套是服務內部調用。域名解析採用雲 DNS 及 PrivateZone。藉助 Kubernetes 的 Ingress 能力來做統一的域名轉發，這樣可以節省公網 SLB 的數量便於運維管理。

3. 平臺選擇

整體的雲原生 PaaS 平臺基於阿里雲容器服務 Kubernetes 版（ACK）打造：

平臺特點：

• 測試、集成、預發、生產統一環境，打通 DevOps 閉環
• 天生資源隔離，機器資源利用率高
• 流量接入可實現精細化管理
• 集成了日誌、鏈路診斷、Metrics 平臺
• 統一 APIServer 接口和擴展，天生支持多雲跟混合雲部署

4. 應用服務層設計

每個應用都在 Kubernetes 上面創建單獨的一個 NameSpace，應用跟應用之間是資源隔離。通過定義各個應用的配置 Yaml 模板，當應用在部署的時候直接編輯其中的鏡像版本即可快速完成版本升級，當需要回滾的時候直接在本地啟動歷史版本的鏡像快速回滾。

5. 運維管理

線上 Kubernetes 集群都是採用了阿里雲託管版容器服務，免去了運維 Master 節點的工作，只需要制定 Worker 節點上線及下線流程即可。同時上面跑的業務系統均通過我們的 PaaS 平臺完成業務日誌搜索，按照業務需求投交擴容任務，系統自動完成擴容操作。降低了直接操作 Kubernetes 集群帶來的風險。

申通雲原生應用服務特點

1. API 接口

我們的應用場景主要有 2 塊：

• 封裝 Kubernetes 管控 API

包括創建 StatefulSet、修改資源屬性、創建 Service 資源等等，通過封裝這些管控 API 方便通過一站式的 PaaS 平臺來管理在線應用。

• 雲原生業務系統

我們雲上的業務系統封裝了各類雲資源的 API，比如：封裝 SLS 的 API、將在線數據寫入 SLS 再跟 Maxcompute 或 Flink 集成。封裝 OSS 的 API，方便在應用程序中將文件上傳。

2. 應用和數據遷移

我們雲上的業務系統及業務中間件都是通過鏡像的方式部署，應用的服務通過 Service 發現，全部在線應用對應的 Pod 及 Service 配置均保存 PaaS 平臺裡面，每個應用歷史版本對應的鏡像版本都保存到系統中，可以基於這份配置快速構建一套業務生產環境。

數據遷移示意圖：

通過 DTS 工具將業務系統的數據從 IDC 存儲及增量遷移到雲上。在線數據穩定地存儲在雲原生的數據庫上面，如 OLTP 類型的 RDS、PolarDB 支撐高併發的實時處理，OLAP 類型的 ADB 支持海量數據分析。同時對於小文件存儲保存在 OSS 上面。引入 NAS 做共享存儲介質，通過 Volume 直接掛載到神龍節點來實現應用數據共享。

3. 服務集成

以雲原生 PaaS 示意：

服務集成闡述

持續集成通過 Git 做版本控制，利用雲效的持續集成功能實現了雲原生應用的構建、編譯及鏡像上傳，全部的業務鏡像均保存在雲端的鏡像服務倉庫。底層是 Kubernetes 集群作為整個業務的計算資源。其他集成的服務包括：

• 日誌服務，通過集成日誌服務方便研發人員方便定位業務及異常日誌。
• 雲監控，通過集成監控能力，方便運維研發人員快速發現故障。
• 服務接入，通過集成統一的接入，整個應用流量可做到精細化管理。
• 彈性伸縮，藉助 ESS 的能力對資源進行動態編排，結合業務高低峰值做到資源利用率最大化。

4. 服務高可用

ACK 集群多層級高可用示意圖

架構說明：

• 支持多可用區部署架構，由用戶自定義分配比例
• 容器集群內故障遷移
• AZ 故障整體容器遷移

Kubernetes集群通過控制應用的副本數來保證集群的高可用。當某個 Pod 節點出現當機故障時，通過副本數的保持可以快速在其他 worker 節點上再啟新的 Pod。

5. 監控

主動發現業務故障，通過引入監控體系主動發現業務問題，快速解決故障。

監控採集示意圖

在同一個 POD 裡面部署了兩個容器：一個是業務容器；一個是 Logtail 容器。應用只需要按照運維定的目錄將業務日誌打進去，即可完成監控數據採集。

技術/應用服務創新點

1. 從虛擬機到 Kubernetes

相比於通過虛擬機來運維應用，Kubernetes 可以將各類資源定義成描述文件，整個應用環境通過容器的方式統一，避免環境不一致的風險。通過修改副本數即可輕鬆完成應用容器的擴縮容操作。

2. 基於 Terway 讓 Pod 和 ECS 網絡處於同等地位

優勢：

• 不依賴 VPC 路由表，就能打通網絡，節點規模不受路由表 Quota 限制
• 不需要額外為 Pod 規劃 Overlay 的網段
• 混合雲專線打通也無需額外配置路由
• 可以直接將 POD 掛到 SLB 後端
• 性能高，相比於社區的 Flannel 提升至少 20%

3. 定義三套接入環境及三套業務環境

架構示意圖

1）三套接入環境

• 公網接入：適合於跟外部客戶對接，通過統一的證書卸載，收斂公網 IP
• 辦公網接入：適合於有敏感接口的對接，只允許指定源 IP 的請求，通過網絡 ACL 讓整個應用訪問更安全。
• 內網接入：適合於業務之間及混合雲架構下 IDC 的業務調用雲上應用，內部調用性能更高也更安全。

2）三套業務環境

• 測試環境：全部的雲資源都是給測試環境使用，可以採用低配資源來滿足功能迴歸測試。
• 預發環境：準上線環境，連接生產環境的資源進行發佈前最後一次功能驗證。
• 生產環境：實際運行環境，接收真實流量處理業務請求。

應用效益

1. 成本方面

使用公有云作為計算平臺，可以讓企業不必因為業務突發增長的需求，而一次性投入大量資金成本用於採購服務器及擴充機櫃。在公共雲上可以做到隨用隨付，對於一些創新業務想做技術調研是非常方便。用完即銷燬，按量付費。另外雲產品都是免運維自行託管在雲端，可以節省人工運維成本，讓企業更專注於做核心業務。

2. 穩定性方面

雲上產品都是提供至少 5 個 9 以上的 SLA 服務，而自建的話穩定性差不少。另外有些開源的軟件可能還存在部分功能上的 bug 影響了業務。另外在數據安全方面雲上數據可以做到異地備份，阿里雲數據類產品的歸檔高可靠、低成本、安全性、存儲無限等特點，讓企業數據更安全。

3. 效率方面

藉助跟雲產品的深度集成，方便研發一站式完成研發、運維工作。從業務需求立項到拉分支開發，再到測試環境功能迴歸驗證，再部署到預發驗證及最後上線，整個持續集成可以做到分鐘級。排查問題方面，研發直接選擇所負責的應用通過集成的 SLS 日誌控制檯快速檢索程序的異常日誌，定位問題。免去了登錄機器查日誌的麻煩。賦能業務：

4. 賦能業務

雲上組件有 300 多種，涵蓋了計算、AI、大數據、IOT 等等諸多領域，這樣可以節省業務創新帶來的技術成本。

總結和後續展望

目前申通已經使用雲原生技術快速的將基礎設施遷移到雲上，使用雲原生技術解決了雙十一成本預算問題，服務監控問題，服務接入和負載均衡等問題，讓 雙11 的快遞高峰能夠更低成本、更穩的方式應對。

對於類似於申通這樣的傳統企業數字化轉型和上雲來說，使用雲原生技術內置的彈性、監控、負載均衡和服務發現等能力，可以大幅降低企業研發和運維人員的遷雲的成本，讓企業的研發和運維人員只需要關心業務研發和遷移，而無需管理大量的基礎設施遷移成本。可以說是企業上雲的最佳路徑。

將來申通還在持續的利用最新的雲原生技術繼續優化基礎設施和業務系統，下一步將會結合雲原生技術進一步的降低成本和提升業務穩定性：

1. 實時的彈性調度

申通的快遞業務是非常典型週期性業務，使用雲原生技術的實時的彈性調度能力可以讓每天的業務高低峰都能自動彈性伸縮。可能再節省一大筆的資源成本。

2. 智能運維和安全生產

結合雲原生的細粒度的監控能力，結合 AIOPS 技術，對系統和業務的指標做到自動分析診斷，從而讓異常事件做到及時發現和處理。

3. 服務網格

引入服務網格來優化目前的微服務架構，統一微服務調用的協議，實現全鏈路追蹤和監控，提升研發和運維的效率。

作者：溪恆、遙方
文章來源：阿里巴巴雲原生公眾號
原文鏈接：https://mp.weixin.qq.com/s/AAFKr333q8-5pMcCNPh2Mg