雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
2019 年 12 月，申通技術總架構師醉易在接受媒體採訪時表示申通現有的技術架構無法滿足快速增長的業務需求，“從內部看，基於傳統架構的數據孤島效應明顯導致信息不能共享，業務模式創新受阻，從外部看，包裹流轉如何藉助數據技術和 IoT 等技術提升效率日益成爲核心議題。”爲了補齊這些技術短板，申通做出了一個決定：全面上雲！
申通是第一個全面上雲的快遞企業，轉眼半年過去了，上雲的進程如何了？上雲之後的效果如何？…爲了搞清楚這些問題，我們採訪了申通上雲的負責人、菜鳥梧桐項目技術專家周金龍。
申通上雲的進程如何？
與其它行業相比，快遞公司業務系統中最核心的兩個數據要素是訂單和掃描軌跡，幾乎所有的實操型系統都需要依賴着這兩種數據，而圍繞訂單與掃描的系統自然就成爲了核心系統。申通上雲的策略也是先從這兩類核心系統入手，先將核心應用和數據遷移到雲上，然後再逐步將其它依賴系統遷移上雲，從而完成全部系統上雲。
2019 年 5 月初，申通開始和阿里雲團隊溝通遷移上雲的需求，預計今年 9 月會關停所有本地數據庫，完成整個上雲項目。
據悉，申通上雲項目的挑戰在於既要去 Oracle，又要完成上雲。如何把成千上萬行代碼的存儲過程全部理解並重新使用 Java 代碼完成；面對日均上億增量數據的系統，如何在不影響業務的情況下將系統遷移上雲.
揭祕申通上雲的關鍵階段
從 2019 年 5 月到至今，申通整個上雲過程可以劃分爲四個關鍵階段：
第一階段：核心系統上雲，構建 DevOps 平臺及監控系統
2019 年 5 月到 11 月，申通從零開始搭建了混合雲網絡架構，並基於 Kubernetes 搭建了 DevOps 平臺及監控體系，同時，完成了核心系統的遷移上雲。這一階段遷移上雲的系統包括訂單系統、巴槍系統和時效系統，它們的共同特點是數據量巨大，對性能和穩定性的要求苛刻。
第二階段：備戰雙十一，全鏈路壓測
爲了備戰 2019 年的雙十一購物節，申通項目引進了全鏈路壓測平臺，全覆蓋了 17 條 A 機鏈路。據悉，在大促前的 40 天內一直不間斷地對系統進行全鏈路壓測，對 AB 級鏈路中超過 25 個系統的應急預案進行了多次全民壓測，預演了雙十一期間可能出現的所有問題。
2019 年雙十一，申通第一次將核心系統運行在公有云上，併成功經受住了這麼大流量的考驗。
第三階段：全站上雲
雙十一的成功給予了申通很大的信心，也就有了文章開頭提到的，申通技術總架構師醉易在 2019 年 12 月宣佈全面上雲。
除了業務系統上雲，申通還搭建了自動化測試平臺和成本管控系統，通過自動化測試平臺可以極大提升系統上雲的效率，不用擔心因爲代碼質量問題導致上雲故障；通過成本管控系統可以有效發現預算費用發生在哪，更有針對性地優化架構，降低雲成本。
據悉，今年 618 申通全部鏈路都會運行在公有云上。
第四階段：關停存量服務器及下線數據庫
當所有的應用及數據都遷移上雲之後，還有一件很重要的事情就是關停現有的存量應用服務器並下線 Oracle 數據庫。
據悉，到 2020 年 9 月，申通會關停全部的雲下數據庫，徹底完成上雲項目。
整體來看，申通上雲項目包括兩個比較關鍵的路徑，一是構建雲上基礎架構和雲原生技術體系，二是將具體的系統遷移上雲。
爲了使得 IT 系統能夠專注在業務上，申通構建了雲上基礎架構和一套雲原生體系，包括了混合雲的網絡規劃設計、K8S 集羣的規劃設計、微服務的調用規範、PAAS 層的一些規範設計等等。
而具體的系統上雲步驟又可分爲兩個部分：
- 改動較小的系統上雲：這部分的工作量主要集中在去 Oracle，通常這類系統是在代碼改造之後，在 PaaS 平臺完成功能的全量業務迴歸、上線前壓測，如果確定功能與性能沒有問題，就可以順利切換上雲。
- 改動較大的系統上雲：這類系統往往需要結合業務做重構，申通的做法是基於雲組件重新進行技術選型，應用了目前比較成熟的阿里雲組件，例如 HBase、RDS、Flink 等等，開發人員只需集中於業務適配改造，無需關注底層組件的搭建調優等。
申通電子面單系統的雲原生改造
申通全量系統都是基於阿里雲組件構建設計的，包括 RocketMQ，ES，Redis 等常用中間件，PolarDB，RDS、DRDS 等雲原生數據庫。除了雲原生組件之外，申通也完成了應用的容器化改造，全量 Java 應用運行在容器中，採用 Kubernetes 作爲業務的基礎設施，利用 Kubernetes 中的組件來解決服務發現、負載均衡、流量接入等問題。
接下來，我們以電子面單系統爲例來看一下申通是如何進行雲原生改造的。
據瞭解，原先的申通電子面單系統共包括近百個應用、數百個實例、數十個存儲過程及觸發器。整個系統的業務實現基本是靠存儲過程、觸發器，非常難維護。
電子面單系統的雲下架構
2019 年 11 月，電子面單系統開始遷移上雲，技術團隊重構了整個系統，將與面單庫存相關的核心功能做了業務抽象層，定義了關鍵能力：庫存查詢、庫存發放、面單獲取等，將業務邏輯放到了代碼中。出於存量數據記錄、增量數據存儲以及業務查詢的需要，電子面單系統還採用了 DRDS+RDS 架構進行分庫分表。
電子面單系統的雲上架構
經過兩個月的代碼開發和功能測試，申通電子面單系統完成了雲原生改造，應用容器數量降到了十幾個實例，應用也收斂到了個位數，整體系統的維護成本大大降低。
成本與穩定性是申通上雲的重點
通常企業上雲會關注三個方面：研發效率、成本和穩定性，而申通主要關注的是後兩個方面，如何通過技術降低成本，如何保證上雲之後的穩定性？
周金龍表示：“從現在的日賬單來看，排名靠前的是大數據平臺，以其中的一個 Project 爲例，之前每天的費用大概在 5000 左右，現在通過技術降本，每天只需要 200 元。”
針對雲上系統的穩定性，技術團隊也採取了多種措施來保障：
- 代碼質量：通過分析歷史故障，技術團隊發現大量的故障都是因爲代碼缺陷或者業務沒有迴歸全導致的。所以在代碼質量治理方面做了很多功課，例如在持續集成環節強制跑系統的業務用例、核心系統發佈之前必須做 CR 等等；
- 容量問題：在應對大促以及運營高峯時，將鏈路壓測作爲常態化，通過壓測獲得較爲準確的容量數據，並提前做好資源準備；
- 數據庫治理：主要是解決慢 SQL 的問題，技術團隊研發了一款慢 SQL 分析及預檢工具，在提交代碼之後，就可以分析出可能存在的慢 SQL，提前發現問題；
- 強化監控，針對核心系統做全景監控，儘可能覆蓋到基礎架構、依賴的中間件等等。
當然，申通上雲也經歷了很多“故事”，周金龍和我們分享了與容器服務、數據同步相關的兩個“小插曲”。
第一個是容器服務對應的安全組必須是企業安全組，因爲普通安全組會有 2000 個 POD 的上限，一旦集羣中的容器超過了上限，就無法創建；第二個是數據在從 RDS 向 Oracle 數據回寫時會遇到 NOT NULL 問題，應用程序在雲上寫了一個空字符串到 RDS 裏面，結果數據寫不回 Oracle，導致兩邊數據不一致。這個問題是 RDS 跟 Oracle 在處理空字符串上的處理方式不一致導致的。
出現問題並不可怕，有時甚至會是一件好事，因爲這些趟過的坑最終會成爲可借鑑的經驗，成爲上雲的最佳實踐。
在回顧整個申通上雲項目時，周金龍表示最重要的是做好這四件事情：研發層面，幫助研發同學提升從代碼構建到代碼交付的速度；代碼質量層面，保證上線的代碼儘可能少出 Bug，最好是在測試環節就可以把代碼問題發現並解決掉；穩定性層面，保證線上發生的事情可以快速發現、快速定位、快速恢復；成本層面，確保上雲不會給企業帶來成本壓力。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK