來源 | [阿里巴巴雲原生公眾號](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496552&idx=1&sn=1d1e08268cb92d5d976df99a9f97e508&chksm=fae6f8a7cd9171b15dcd542f52c1411c0d2ff98da9bdbbed2afd02110ce8f19586e61f48ddb2&token=645909615&lang=zh_CN#rd)

作者 | 溪恆、遙方

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

![最開始.jpg](https://ucc.alicdn.com/pic/developer-ecology/825ef20c64644da19d96a54dd5406068.jpg)

申通是目前國內最大的物流公司之一，為了解決 “雙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. 雲原生技術框架設計

![1.png](https://ucc.alicdn.com/pic/developer-ecology/695dc2b6e6ec48a1bc9831716d81d77f.png)
整體架構

**架構闡述：**

- 基礎設施

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

- 流量接入

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

## 3. 平臺選擇

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/57e6614bb92c4ccabf6bb1812e9006a9.png)

平臺特點：

- 測試、整合、預發、生產統一環境，打通 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 平臺裡面，每個應用歷史版本對應的映象版本都儲存到系統中，可以基於這份配置快速構建一套業務生產環境。

資料遷移示意圖：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/100d07892206452eac94c3900a143911.png)

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

## 3. 服務整合

以雲原生 PaaS 示意：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/432f10c9c06844669fd652a3a9bc28ec.png)

### 服務整合闡述

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

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

## 4. 服務高可用

![5.png](https://ucc.alicdn.com/pic/developer-ecology/7662dcae2d0043f3afafeee1cce17d9f.png)
ACK 叢集多層級高可用示意圖

架構說明：

- 支援多可用區部署架構，由使用者自定義分配比例
- 容器叢集內故障遷移
- AZ 故障整體容器遷移

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

## 5. 監控

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/75ced0e4211b4dc498c7010f3137bdb1.png)
監控採集示意圖

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

# 技術/應用服務創新點

## 1. 從虛擬機器到 Kubernetes

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

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

優勢：

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

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

![7.png](https://ucc.alicdn.com/pic/developer-ecology/afe5a740fc5a49209a7bdce40affcad9.png)
架構示意圖

### 1）三套接入環境

- 公網接入：適合於跟外部客戶對接，透過統一的證書解除安裝，收斂公網 IP
- 辦公網接入：適合於有敏感介面的對接，只允許指定源 IP 的請求，透過網路 ACL 讓整個應用訪問更安全。
- 內網接入：適合於業務之間及混合雲架構下 IDC 的業務呼叫雲上應用，內部呼叫效能更高也更安全。

### 2）三套業務環境

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

# 應用效益

## 1. 成本方面

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

## 2. 穩定性方面

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

## 3. 效率方面

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

## 4. 賦能業務

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

# 總結和後續展望

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

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

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

## 1. 實時的彈性排程

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

## 2. 智慧運維和安全生產

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

## 3. 服務網格

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

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

相關文章

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

相關文章

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