申通快遞 雙11 雲原生應用實踐

來源 | 阿里巴巴雲原生公衆號

做者 | 溪恆、遙方

一年一度的 「雙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. 服務網格

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