作者：溪恆、遙方
一年一度的“雙11”大促中，交易額每年都在刷新，承接這些交易商品的快遞包裹的數量也在成倍增長。這些快速的增長對物流系統帶來了巨大的挑戰，讓物流管理更加敏捷來應對“雙11”成為了必須解決的問題。
申通是目前國內最大的物流公司之一，為了解決“雙11”的技術挑戰，申通在物流場景引入IOT、大數據和AI等先進和創建的技術手段，通過不斷的技術快速迭代，使得物流資源得到有效的配置，推動了物流行業的發展。
快速的技術迭代帶來了對IT基礎設施的挑戰，申通近年來全面將傳統應用切換使用雲原生架構，通過雲原生架構實現應用的快速迭代、穩定的高可用、資源的動態擴縮容來支撐起快速的技術創新。
上雲前，申通使用線下機房作為計算及數據存儲平臺，一到雙11資源需求就膨脹，大促之後則閒置浪費；上雲和雲原生化後，幾乎全部的資源都是按量購買，使用雲原生技術快速擴縮容，雙十一前快速擴容，雙11釋放，真正做到了開箱即用，不產生一天浪費。與去年雙11當天相比，今年11月1到3日，在業務量大幅提升的情況下，IT投入反而降低了30%。上雲的成效顯著。
申通雲原生化架構的背景
目前申通正在把業務從IDC機房往雲上搬遷，核心業務系統目前已經在雲上完成流量承接。原有IDC系統幫助申通早期業務快速發展，但也暴露了不少問題，傳統IOE架構，各系統架構的不規範，穩定性，研發效率等都限制了業務發展需求。
隨著雲計算在國內的越發成熟，更多的企業在把自己核心系統往雲上搬，享受雲計算帶來的技術紅利。在跟阿里雲多次技術交流之後最終確定阿里云為唯一合作伙伴，為申通提供穩定的計算、數據處理平臺。
採用雲原生應用架構的訴求/驅動力
快遞公司是非常典型的雲邊一體架構，實操環節很重。大量的業務邏輯下沉到邊緣，所以申通在上雲改造過程中，也在嘗試做雲邊一體化的架構升級。 通過雲邊一體，可以讓開發在同一個平臺上面完成雲上業務及邊緣側的業務開發。同時快遞公司還有典型的大數據處理場景，全網每天會新增幾億條掃描數據，需要對這些數據進行實時分析，對數據的處理要求非常高。
之前使用線下機房做為計算及數據存儲平臺的方式，使申通在業務增長過程中遇到了一些瓶頸，比如軟件交付週期過長、大促保障對資源的要求、系統穩定性挑戰等等。而云原生技術就是來解決傳統應用升級緩慢、架構臃腫、不能快速迭代等方面的問題。正是看中了雲原生技術能夠給我們帶來的價值才驅使我們轉為使用公有云作為主要計算資源。
站在企業的角度來看，在這樣一個快速多變的時代，雲原生給我們帶來的價值也正是企業最需要的：
唯快不破。這裡的“快”有兩層含義，一是業務應用快速上線，通過雲原生技術可以做到快速上線部署；二是在業務爆發式增長的時候，對資源的需求要做到開箱即用。
穩中求變。業務穩定性永遠是第一位。通過監控埋點，業務日誌收集，鏈路監控等手段保證了在快速迭代過程中業務系統的穩定性。
節省資源。通過對計算資源的水位監測，結合業務的峰值情況，當發現資源利用率偏低採用降配規格及數量，降低整個資源的費用。相比於一次性投入租建機房及相應的維護費用，使用公有云成本投入更低。
開拓創新。採用微服務架構，將之前臃腫的架構進行合理拆分，再結合容器編排的能力做到持續交付。讓企業成功轉型成為一家DevOps驅動的公司。
申通雲原生架構歷程
雲原生化技術改造：
原架構是基於Vmware+Oracle數據庫的架構，通過上阿里雲全面轉型基於Kubernetes的雲原生架構體系。應用服務架構重構主要分兩部分：
1、程序代碼改造升級。
應用容器化
跟虛擬機比起來，容器能同時提供效率和速度的提升，讓其更適合微服務場景。所以我們引入容器技術。通過應用容器化解決了環境不一致的問題，保證應用在開發、測試、生產環境的一致性。
微服務改造
原先很多業務是基於Oracle的存儲過程及觸發器完成的，系統之間的服務依賴也是走的數據庫OGG同步完成。帶來的問題就是系統非常難維護，也非常不穩定。通過引入Kubernetes的服務發現來做微服務方案，按業務域進行拆分，讓整個系統更易於維護。
2、引入雲原生數據庫方案
通過引入OLTP跟OLAP型數據庫，將在線數據與離線分析邏輯拆到兩種數據庫中，取代之前完全依賴Oracle。特別是在處理歷史數據查詢場景下解決了Oracle支持不了的業務需求。
雲原生技術框架設計：
**整體架構：
**
架構闡述
1、基礎設施
全部的計算資源取自阿里雲的神龍裸金屬服務器，Kubernetes搭配神龍服務器能夠獲得更佳性能及更合理的資源利用率，雲上資源可以按量付費，特別適合大促場景，大促結束之後資源使用完釋放。相比於線下自建機房和常備機器，雲上資源操作更方便，管理成本也更低。
2、流量接入
共有2套流量接入，一套是面向公網請求，另外一套是服務內部調用。域名解析採用雲DNS及PrivateZone。藉助Kubernetes的Ingress能力來做統一的域名轉發，這樣可以節省公網SLB的數量便於運維管理。
平臺選擇：
整體的雲原生PaaS平臺基於阿里雲容器服務Kubernetes 版（ACK）打造：
平臺特點：
1、測試、集成、預發、生產統一環境，打通DevOps閉環
2、天生資源隔離，機器資源利用率高
3、流量接入可實現精細化管理
4、集成了日誌、鏈路診斷、Metrics平臺
5、統一APIServer接口和擴展，天生支持多雲跟混合雲部署
應用服務層設計
每個應用都在Kubernetes上面創建單獨的一個NameSpace，應用跟應用之間是資源隔離。通過定義各個應用的配置Yaml模板，當應用在部署的時候直接編輯其中的鏡像版本即可快速完成版本升級，當需要回滾的時候直接在本地啟動歷史版本的鏡像快速回滾。
運維管理
線上Kubernetes集群都是採用了阿里雲託管版容器服務，免去了運維Master節點的工作，只需要制定Worker節點上線及下線流程即可。同時上面跑的業務系統均通過我們的PaaS平臺完成業務日誌搜索，按照業務需求投交擴容任務，系統自動完成擴容操作。降低了直接操作Kubernetes集群帶來的風險。
申通雲原生應用服務特點
API接口：
我們的應用場景主要有2塊：
1、封裝Kubernetes管控API
包括創建StatefulSet、修改資源屬性、創建Service資源等等，通過封裝這些管控API方便通過一站式的PaaS平臺來管理在線應用。
2、雲原生業務系統
我們雲上的業務系統封裝了各類雲資源的API，比如：封裝SLS的API、將在線數據寫入SLS再跟Maxcompute或Flink集成。封裝OSS的API，方便在應用程序中將文件上傳。
應用和數據遷移:
我們雲上的業務系統及業務中間件都是通過鏡像的方式部署，應用的服務通過Service發現，全部在線應用對應的Pod及Service配置均保存PaaS平臺裡面，每個應用歷史版本對應的鏡像版本都保存到系統中，可以基於這份配置快速構建一套業務生產環境。
數據遷移示意圖:
通過DTS工具將業務系統的數據從IDC存儲及增量遷移到雲上。在線數據穩定地存儲在雲原生的數據庫上面，如OLTP類型的RDS、PolarDB支撐高併發的實時處理，OLAP類型的ADB支持海量數據分析。同時對於小文件存儲保存在OSS上面。引入NAS做共享存儲介質，通過Volume直接掛載到神龍節點來實現應用數據共享。
服務集成:
以雲原生PaaS示意:
服務集成闡述
持續集成通過Git做版本控制，利用雲效的持續集成功能實現了雲原生應用的構建、編譯及鏡像上傳，全部的業務鏡像均保存在雲端的鏡像服務倉庫。底層是Kubernetes集群作為整個業務的計算資源。其他集成的服務包括：
1> 日誌服務，通過集成日誌服務方便研發人員方便定位業務及異常日誌。
2> 雲監控，通過集成監控能力，方便運維研發人員快速發現故障
3> 服務接入，通過集成統一的接入，整個應用流量可做到精細化管理
4> 彈性伸縮，藉助ESS的能力對資源進行動態編排，結合業務高低峰值做到資源利用率最大化。
服務高可用:
ACK集群多層級高可用示意圖
架構說明：
• 支持多可用區部署架構，由用戶自定義分配比例
• 容器集群內故障遷移
• AZ故障整體容器遷移
Kubernetes集群通過控制應用的副本數來保證集群的高可用。當某個Pod節點出現當機故障時，通過副本數的保持可以快速在其他worker節點上再啟新的Pod。
監控
主動發現業務故障，通過引入監控體系主動發現業務問題，快速解決故障。
監控採集示意圖：
在同一個POD裡面部署了兩個容器，一個是業務容器，一個是Logtail容器。應用只需要按照運維定的目錄將業務日誌打進去，即可完成監控數據採集。
技術/應用服務創新點
從虛擬機到kubernetes
相比於通過虛擬機來運維應用， Kubernetes可以將各類資源定義成描述文件，整個應用環境通過容器的方式統一，避免環境不一致的風險。通過修改副本數即可輕鬆完成應用容器的擴縮容操作。
基於Terway讓Pod和ECS網絡處於同等地位
優勢：
1> 不依賴VPC路由表，就能打通網絡，節點規模不受路由表Quota限制
2> 不需要額外為Pod規劃Overlay的網段
3> 混合雲專線打通也無需額外配置路由
4> 可以直接將POD掛到SLB後端
5> 性能高，相比於社區的Flannel提升至少20%
定義三套接入環境及三套業務環境
架構示意圖
三套接入環境
公網接入：適合於跟外部客戶對接，通過統一的證書卸載，收斂公網IP
辦公網接入：適合於有敏感接口的對接，只允許指定源IP的請求，通過網絡ACL讓整個應用訪問更安全。
內網接入：適合於業務之間及混合雲架構下IDC的業務調用雲上應用，內部調用性能更高也更安全。
三套業務環境
測試環境：全部的雲資源都是給測試環境使用，可以採用低配資源來滿足功能迴歸測試
預發環境：準上線環境，連接生產環境的資源進行發佈前最後一次功能驗證
生產環境：實際運行環境，接收真實流量處理業務請求
應用效益
成本方面：
使用公有云作為計算平臺，可以讓企業不必因為業務突發增長的需求，而一次性投入大量資金成本用於採購服務器及擴充機櫃。在公共雲上可以做到隨用隨付，對於一些創新業務想做技術調研是非常方便。用完即銷燬，按量付費。另外雲產品都是免運維自行託管在雲端，可以節省人工運維成本，讓企業更專注於做核心業務。
穩定性方面：
雲上產品都是提供至少5個9以上的SLA服務，而自建的話穩定性差不少。另外有些開源的軟件可能還存在部分功能上的bug影響了業務。另外在數據安全方面雲上數據可以做到異地備份，阿里雲數據類產品的歸檔高可靠、低成本、安全性、存儲無限等特點，讓企業數據更安全。
效率方面：
藉助跟雲產品的深度集成，方便研發一站式完成研發、運維工作。從業務需求立項到拉分支開發，再到測試環境功能迴歸驗證，再部署到預發驗證及最後上線，整個持續集成可以做到分鐘級。排查問題方面，研發直接選擇所負責的應用通過集成的SLS日誌控制檯快速檢索程序的異常日誌，定位問題。免去了登錄機器查日誌的麻煩。
賦能業務：
雲上組件有300多種，涵蓋了計算、AI、大數據、IOT等等諸多領域，這樣可以節省業務創新帶來的技術成本。
總結和後續展望：
目前申通已經使用雲原生技術快速的將基礎設施遷移到雲上，使用雲原生技術解決了雙十一成本預算問題，服務監控問題，服務接入和負載均衡等問題，讓雙十一的快遞高峰能夠更低成本、更穩的方式應對。
對於類似於申通這樣的傳統企業數字化轉型和上雲來說，使用雲原生技術內置的彈性、監控、負載均衡和服務發現等能力，可以大幅降低企業研發和運維人員的遷雲的成本，讓企業的研發和運維人員只需要關心業務研發和遷移，而無需管理大量的基礎設施遷移成本。可以說是企業上雲的最佳路徑。
將來申通還在持續的利用最新的雲原生技術繼續優化基礎設施和業務系統，下一步將會結合雲原生技術進一步的降低成本和提升業務穩定性：
實時的彈性調度：
申通的快遞業務是非常典型週期性業務，使用雲原生技術的實時的彈性調度能力可以讓每天的業務高低峰都能自動彈性伸縮。可能再節省一大筆的資源成本。
智能運維和安全生產：
結合雲原生的細粒度的監控能力，結合AIOPS技術，對系統和業務的指標做到自動分析診斷，從而讓異常事件做到及時發現和處理。
服務網格：
引入服務網格來優化目前的微服務架構，統一微服務調用的協議，實現全鏈路追蹤和監控，提升研發和運維的效率。