一年一度的 “雙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