随着雲計算的快速發展和成熟，越來越多的企業正在把自己的核心系統向雲上遷移，進而享受雲計算帶來的技術紅利。IDC釋出的《全球雲計算IT基礎設施市場預測報告》顯示：2019年全球雲上的IT基礎設施占比超過傳統資料中心，成為市場主導者。在技術層面，雲計算在成本、穩定、安全和效率層面已經遠超傳統IT。對于企業而言，上雲後綜合成本下降一半，穩定性有10倍以上提升，安全性更是提升50倍。這些信号都在标志着以雲計算為基礎的數字化時代全面到來。
申通快遞建立于1993年，是國内較早經營快遞業務的民營快遞品牌。與很多同行一樣，早期的資訊系統建設也采用外包承接的方式運作。2016年年底，申通快遞正式登陸深交所。作為快遞行業巨頭之一，申通上市的目的，除了要把業務規模做大外，很重要的一點是要在技術上下功夫，打造公司核心的競争力，建構行業的高生态壁壘，抵抗“外敵”入侵。
2019年年底，申通選擇全面遷移至阿裡雲，也是以成為業内首個全面上雲的快遞企業。這次全面上雲，不隻是變革基礎架構，更是對研發模式的一次重要變革。今年6月，申通通用雲原生計算平台被雲原生開源産業聯盟、CNCF基金會聯合選為“2020年度雲原生應用十大優秀案例”之一。以下是關于申通快遞核心業務系統雲原生化上雲的詳解，
1、為什麼要用雲原生應用架構？
快遞公司是非常典型的雲邊一體架構，實操環節很重。大量的業務邏輯下沉到邊緣，是以申通在上雲改造過程中，也在嘗試做雲邊一體化的架構更新。 通過雲邊一體，可以讓開發在同一個平台上面完成雲上業務及邊緣側的業務開發。同時快遞公司還有典型的大資料處理場景，全網每天會新增幾億條掃描資料，需要對這些資料進行實時分析，對資料的處理要求非常高。
申通以前使用線下機房作為計算及資料存儲平台，随着業務量的快速增長，原有的IT系統遇到了一些瓶頸，比如軟體傳遞周期過長，大促保障對資源的要求高、系統穩定性差等。從申通内部看，基于傳統IOE架構建構的系統無法支撐業務高速增長後的資料量膨脹，受限于容量訂單系統，隻能保留3~6個月的資訊查詢，且無法對曆史包裹進行線上搜尋，相關應用都會受阻。從外部看，包裹流轉如何借助資料技術和IoT等技術來提升效率日益成為快遞行業的競争焦點。
雲原生技術天然适合解決傳統應用更新緩慢、架構臃腫、不能快速疊代等問題。具體來看，雲原生有四點優勢是企業迫切需要的，一是速度快，通過雲原生技術可以做到業務快速上線部署，這就在市場需求多變的競争中搶得了先機；另外，在業務爆發式增長的時候，雲原生可以對資源的需求做到開箱即用。
二是提升業務的穩定性。通過監控埋點、業務日志收集、鍊路監控等手段可以保證業務系統在快速疊代過程中保持穩定性。依賴Kubernetes為核心的資料中心，通過應用編排、業務故障自愈的能力讓整個系統更穩定。
三是節省資源。通過對計算資源的水位監測，結合業務的峰值情況，當發現資源使用率偏低時，采用降配規格及數量，降低整個資源的費用。相比于一次性投入租建機房及相應的維護費用，使用公有雲成本投入更低。利用公有雲低成本的硬體、無需關注基礎設施、零傳遞周期的優勢，結合容器技術可以做到業務實時按需動态伸縮資源。
四是采用微服務架構，将之前臃腫的架構進行合理拆分，再結合容器編排的能力做到持續傳遞，可以讓企業成功轉型成為一家Devops驅動的公司。
正是看中了雲原生技術為企業帶來的優勢，最終申通選擇核心系統以雲原生化的方式上雲。
2、申通雲原生應用架構設計路線
申通原來的IT架構是基于VMware+Oracle資料庫的架構，與阿裡雲原生團隊溝通後，決定采用基于Kubernetes的雲原生架構體系。對應用服務架構進行，主要做了程式代碼改造更新和引入雲原生資料庫。
程式代碼改造更新
申通程式代碼改造更新主要兩部分更新，一是應用容器化，跟虛拟機比起來，容器可以同時提升效率和速度，讓其更适合微服務場景。引入容器技術，解決了環境不一緻的問題，保證應用在開發、測試、生産環境的一緻性。二是微服務改造，原來，申通的很多業務是基于Oracle的存儲過程及觸發器完成，系統之間的服務依賴也是依靠資料庫OGG同步完成。這麼做帶來的問題就是系統維護非常困難，穩定性非常差。通過引入Kubernetes的服務發現來做微服務方案，按業務域進行拆分，使整個系統更易于維護。
引入雲原生資料庫方案
通過引入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一體化的良性循環成為可能，運維團隊未來除了承擔線上保障的責任，還會将更多精力投入到研發支撐工具的創新上。
雲原生被企業接受之後，落地的過程仍然要面臨一些挑戰。但是雲原生技術帶來的資源成本降低、研發運維效率提升等巨大價值，會驅動企業迎接這些挑戰。
雲原生已經成為釋放雲價值的最短路徑，使用雲原生上雲，基于容器和服務網格等标準界面和混合雲方案，将極大的降低遷雲複雜度，使企業可以更快遷移到雲上标準服務。通過雲原生上雲，最大化使用雲的能力，高效的社會分工，使企業聚焦于自身業務發展，相信将成為企業的共識。
日前，在2020阿裡雲合作夥伴峰會上，阿裡巴巴合夥人、阿裡雲智能基礎産品事業部進階研究員蔣江偉發表了《深耕“被內建”，共建新生态》主題演講，他在演講中提到，阿裡雲将繼續深耕“被內建”戰略，做強生态，未來一年投入20億專項資金，助力50家夥伴雲上營收過億，并啟動“雲原生合作夥伴計劃”：重點扶持100個頭部夥伴，賦能10000家合作夥伴，50萬開發者，幫助合作夥伴進行雲原生技術更新，助力合作夥伴數字化轉型。
随着全面上雲及業務的飛速發展，申通在雲原生領域需要有更多的人才加入，幫助申通在下一代研發體系更新、安全生産、業務成本等領域實作更多的創新。如果你想加入申通雲原生技術團隊，歡迎履歷投遞至：[email protected]。