如果說，快遞行業上半場的競爭拼的是規模、服務乃至價格，進入下半場，快遞企業們還需要比拼硬核的技術實力。
隨着雲計算的快速發展和成熟，越來越多的企業正在把自己的核心繫統向雲上遷移，從而享受雲計算帶來的技術紅利。IDC 發佈的《全球雲計算IT基礎設施市場預測報告》顯示：2019年全球雲上的IT基礎設施佔比超過傳統數據中心，成爲市場主導者。在技術層面，雲計算在成本、穩定、安全和效率層面已經遠超傳統IT。對於企業而言，上雲後綜合成本下降一半，穩定性有 10 倍以上提升，安全性更是提升50倍。這些信號都在標誌着以雲計算爲基礎的數字化時代全面到來。
申通快遞創建於 1993 年，是國內較早經營快遞業務的民營快遞品牌。與很多同行一樣，早期的信息系統建設也採用外包承接的方式運作。2016 年年底，申通快遞正式登陸深交所。作爲快遞行業巨頭之一，申通上市的目的，除了要把業務規模做大外，很重要的一點是要在技術上下功夫，打造公司核心的競爭力，構建行業的高生態壁壘，抵抗“外敵”入侵。
2019 年年底，申通選擇全面遷移至阿里雲，也因此成爲業內首個全面上雲的快遞企業。這次全面上雲，不只是變革基礎架構，更是對研發模式的一次重要變革。今年 6 月，申通通用雲原生計算平臺被雲原生開源產業聯盟、 CNCF 基金會聯合選爲“ 2020 年度雲原生應用十大優秀案例”之一，以下是關於申通快遞核心業務系統雲原生化上雲的詳解。
爲什麼要用雲原生應用架構？
快遞公司是非常典型的雲邊一體架構，實操環節很重。大量的業務邏輯下沉到邊緣，所以申通在上雲改造過程中，也在嘗試做雲邊一體化的架構升級。通過雲邊一體，可以讓開發在同一個平臺上面完成雲上業務及邊緣側的業務開發。同時快遞公司還有典型的大數據處理場景，全網每天會新增幾億條掃描數據，需要對這些數據進行實時分析，對數據的處理要求非常高。
申通以前使用線下機房作爲計算及數據存儲平臺，隨着業務量的快速增長，原有的IT系統遇到了一些瓶頸，比如軟件交付週期過長，大促保障對資源的要求高、系統穩定性差等。從申通內部看，基於傳統 IOE 架構構建的系統無法支撐業務高速增長後的數據量膨脹，受限於容量訂單系統，只能保留 3~6 個月的信息查詢，且無法對歷史包裹進行在線搜索，相關應用都會受阻。從外部看，包裹流轉如何藉助數據技術和IoT等技術來提升效率日益成爲快遞行業的競爭焦點。
雲原生技術天然適合解決傳統應用升級緩慢、架構臃腫、不能快速迭代等問題。具體來看，雲原生有四點優勢是企業迫切需要的，一是速度快，通過雲原生技術可以做到業務快速上線部署，這就在市場需求多變的競爭中搶得了先機；另外，在業務爆發式增長的時候，雲原生可以對資源的需求做到開箱即用。
二是提升業務的穩定性。通過監控埋點、業務日誌收集、鏈路監控等手段可以保證業務系統在快速迭代過程中保持穩定性。依賴 Kubernetes 爲核心的數據中心，通過應用編排、業務故障自愈的能力讓整個系統更穩定。
三是節省資源。通過對計算資源的水位監測，結合業務的峯值情況，當發現資源利用率偏低時，採用降配規格及數量，降低整個資源的費用。相比於一次性投入租建機房及相應的維護費用，使用公有云成本投入更低。利用公有云低成本的硬件、無需關注基礎設施、零交付週期的優勢，結合容器技術可以做到業務實時按需動態伸縮資源。
四是採用微服務架構，將之前臃腫的架構進行合理拆分，再結合容器編排的能力做到持續交付，可以讓企業成功轉型成爲一家 Devops 驅動的公司。
正是看中了雲原生技術爲企業帶來的優勢，最終申通選擇核心系統以雲原生化的方式上雲。
申通雲原生應用架構設計路線
申通原來的IT架構是基於 VMware+Oracle 數據庫的架構，與阿里雲原生團隊溝通後，決定採用基於 Kubernetes 的雲原生架構體系。對應用服務架構進行，主要做了程序代碼改造升級和引入雲原生數據庫。
1. 程序代碼改造升級
申通程序代碼改造升級主要兩部分升級，一是應用容器化，跟虛擬機比起來，容器可以同時提升效率和速度，讓其更適合微服務場景。引入容器技術，解決了環境不一致的問題，保證應用在開發、測試、生產環境的一致性。二是微服務改造，原來，申通的很多業務是基於 Oracle 的存儲過程及觸發器完成，系統之間的服務依賴也是依靠數據庫 OGG 同步完成。這麼做帶來的問題就是系統維護非常困難，穩定性非常差。通過引入 Kubernetes 的服務發現來做微服務方案，按業務域進行拆分，使整個系統更易於維護。
2. 引入雲原生數據庫方案
通過引入 OLTP 和 OLAP 型數據庫，將在線數據與離線分析邏輯拆到兩種數據庫中，不再完全依賴 Oracle 。這就解決了在歷史數據查詢場景下 Oracle 支持不了的業務需求。綜合考慮申通業務和技術特點，最終選擇了阿里雲 ACK+ 神龍+雲數據庫的雲原生解決方案，實現核心應用搬遷上阿里雲。申通雲原生應用技術框架如下圖所示。
在基礎設施層面，全部的計算資源取自阿里雲的神龍裸金屬服務器，相比於 ECS ， Kubernetes 搭配神龍服務器能夠獲得更佳的性能及更合理的資源利用率。特別適合大促場景，雲上資源可以按量付費，大促結束之後資源使用完就釋放。相比於線下自建機房和常備機器，雲上資源操作更方便，管理成本也更低。
在流量接入層面，共有2套流量接入，一套是面向公網請求，另外一套是服務內部調用。域名解析採用雲 DNS 及 PrivateZone 。藉助 Kubernetes 的 Ingress 能力來做統一的域名轉發，這樣可以節省公網SLB的數量便於運維管理。
在平臺層，申通基於 Kubernetes 打造的雲原生 PaaS 平臺如下圖所示。
該平臺的特點如下：
測試、集成、預發、生產統一環境，打通 DevOps 閉環。
天生資源隔離，機器資源利用率高。
流量接入可實現精細化管理。
集成了日誌、鏈路診斷、Metrics 平臺。
統一 ApiServer 接口和擴展，天生支持多雲跟混合雲部署
在應用服務層，每個應用都在 Kubernetes 上面創建單獨的一個 Namespace ，應用跟應用之間資源隔離。通過定義各個應用的配置 YAML 模板，當應用在部署的時候直接編輯其中的鏡像版本即可快速完成版本升級，當需要回滾的時候直接在本地啓動歷史版本的鏡像就能快速回滾。
在運維管理上，線上 Kubernetes 集羣都是採用了阿里雲託管版容器服務，免去了運維 Master 節點的工作，只需要制定 Worker 節點上線及下線流程即可。同時上面跑的業務系統均通過 PaaS 平臺完成業務日誌搜索，按照業務需求投交擴容任務，系統自動完成擴容操作，降低了直接操作 Kubernetes 集羣帶來的風險。
雲原生應用服務特點
1. API 接口化
API 接口化應用場景主要有兩個，一是封裝Kubernetes管控API：包括創建 StatefulSet ，修改資源屬性，創建Service資源等，通過封裝這些管控 API ，可以通過一站式的 PaaS 平臺來管理在線應用。二是雲原生業務系統，雲上的業務系統封裝了各類雲資源的 API ，如封裝 SLS 的 API ，將在線數據寫入 SLS 再跟 Maxcompute 或 Flink 集成。封裝 OSS 的 API ，方便在應用程序中將文件上傳。
2. 應用和數據遷移
雲上的業務系統及業務中間件都是通過鏡像的方式部署，應用的服務通過 Service 發現，全部的在線應用（300+）對應的 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 。通過引入監控體系主動發現業務問題，快速解決故障。監控採集示意如下圖所示：
在同一個 Pod 裏面部署了兩個容器，一個是業務容器，一個是 Logtail 容器。應用只需要按照運維定的目錄將業務日誌打進去，即可完成監控數據採集。
技術創新點
1. 從虛擬機到 Kubernetes
相比於通過虛擬機來運維應用，Kubernetes 可以將各類資源定義成描述文件，整個應用環境通過容器的方式統一，避免環境不一致的風險。通過修改副本數即可輕鬆完成應用容器的擴縮容操作。Kubernetes 提供了一個非常容易的機制來幫助用戶打包應用，並且能快速部署到任意一個環境中，實現快速擴容、縮容的目的。
2. 從單體應用到微服務
單體架構，系統與系統之間是緊耦合模式。隨着代碼庫的不斷加大，添加或者改變單體應用程序的功能就變得越來越複雜。而微服務架構是松耦合狀態，每一個團隊做一個服務，每個服務執行一個功能，系統與系統之間是相互獨立的狀態，可以讓不同的團隊開發不同的服務，通過輕量級的API調用來實現服務與服務之間的串聯。對某個服務進行擴展，只擴展單個系統就能實現，修改代碼也不影響其他應用。
3. 基於 Terway 讓 Pod 和 ECS 網絡處於同等地位
優勢：不依賴 VPC 路由表，就能打通網絡，節點規模不受路由表 Quota 限制；不需要額外爲 Pod 規劃 Overlay 的網段；混合雲專線打通也無需額外配置路由；可以直接將 POD 掛到 SLB 後端；性能高，相比於社區的 Flannel 提升至少 10% 。
4. 定義三套接入環境及三套業務環境
定義三套環境主要是爲了解決研發環境的問題，定義日常、預發、生產環境，方便研發做測試迴歸；定義三套業務環境主要是爲了網絡接入方便，這樣內部應用可以走內部接入，從網絡隔離上面保護系統。
三套接入環境包括公網接入、辦公網接入、內網接入。
公網接入：適合於跟外部客戶對接，通過統一的證書卸載，收斂公網IP。
辦公網接入：適合於有敏感接口的對接，只允許指定源IP的請求，通過網絡ACL讓整個應用訪問更安全。
內網接入：適合於業務之間及混合雲架構下IDC的業務調用雲上應用，內部調用性能更高也更安全。
三套業務環境包括測試環境、預發環境、生產環境。
測試環境：全部的雲資源都是給測試環境使用，可以採用低配資源來滿足功能迴歸測試。
預發環境：準上線環境，連接生產環境的資源進行發佈前最後一次功能驗證。
生產環境：實際運行環境，接收真實流量處理業務請求。
應用收益
申通通過雲原生化的方式上雲，在成本、穩定性、效率、賦能業務四個方面效果顯著。
成本方面：使用公有云作爲計算平臺，不必因爲業務突發增長的需求，而一次性投入大量資金成本用於採購服務器及擴充機櫃。在公共雲上可以做到隨用隨付，對於一些創新業務想做技術調研非常方便。用完即銷燬，按量付費。另外雲產品都是免運維自行託管在雲端，可以節省人工運維成本，讓企業更專注於做核心業務。
穩定性方面：雲上產品都是提供至少 5 個 9 以上的 SLA 服務，而自建的話穩定性差不少。另外有些開源的軟件可能還存在部分功能上的bug影響了業務。另外在數據安全方面雲上數據可以做到異地備份，阿里雲數據類產品的歸檔具有高可靠、低成本、安全性、存儲無限等特點，讓企業數據更安全。
效率方面：藉助跟雲產品的深度集成，方便研發人員完成一站式研發、運維工作。從業務需求立項到拉分支開發，再到測試環境功能迴歸驗證，再部署到預發驗證及最後上線，整個持續集成可以做到分鐘級。排查問題方面，研發直接選擇所負責的應用通過集成的 SLS 日誌控制檯快速檢索程序的異常日誌，定位問題。免去了登錄機器查日誌的麻煩。
賦能業務：雲上組件有 300 多種，涵蓋了計算、AI 、大數據、IoT 等諸多領域，可以節省業務創新帶來的技術成本。目前，申通每天處理訂單量在千萬級別，處理物流軌跡在億級別，每天產生的數據量在 1T ，使用 1300+ 個計算節點來實時處理業務。
結束語
企業上雲已經是大勢所趨。申通核心系統雲原生化上雲，系統穩定性大幅提升，對於用戶的體驗也更好了，之前很多業務功能無法實現，現在基本都可以支持。全面上雲，除了業務上的價值，還推動了申通內部的技術體系創新，雲服務讓 DevOps 一體化的良性循環成爲可能，運維團隊未來除了承擔線上保障的責任，還會將更多精力投入到研發支撐工具的創新上。
雲原生被企業接受之後，落地的過程仍然要面臨一些挑戰。但是雲原生技術帶來的資源成本降低、研發運維效率提升等巨大價值，會驅動企業迎接這些挑戰。雲原生已經成爲釋放雲價值的最短路徑，使用雲原生上雲，基於容器和服務網格等標準界面和混合雲方案，將極大的降低遷雲複雜度，使企業可以更快遷移到雲上標準服務。通過雲原生上雲，最大化使用雲的能力，高效的社會分工，使企業聚焦於自身業務發展，相信將成爲企業的共識。