數字化轉型的雲遷移之路，永輝超市歷時2年的經驗總結｜ArchSummit

「來源： ｜InfoQ ID：infoqchina」

作者 | 李忠良

數字化轉型並非一蹴而就的事情，對於企業來說，它是一場馬拉松，而在這場競賽中，很多前行者的經驗值得借鑑。為了讓大家對數字化轉型有更多的瞭解，我們邀請了永輝超市高階架構師張明來為大家分享永輝超市的混合雲建設與運維，在正式分享前，我們採訪了張明，本文為其採訪整理，期待對你有所啟發。

InfoQ：我們先從您目前正在做的事聊起， 您目前主要負責什麼呢？

張明：

我近期主要負責參與混合雲建設的方案制定與落地推動。

比如，升級私有云機房基礎設施架構。為了使私有云上的資源容量可滿足增量需求、且持續穩定地提供優質服務，需要持續不斷地利用科學的技術能力進行提效降本。

同時打通與公有云的通訊、接入彈性計算能力、相關雲元件 / 雲能力、自建 DevOps 的多雲支撐等也是目前很重要的一部分工作。

當然在升級過程中也是需要結合業務實際部署與用量情況，選擇高性價比、技術成熟、且適應自身系統生態的元件進行升級接入。

當然，還有一件很重要的事——推進多資料中心間的應用多活。

我們的系統要做到 7x24 不間斷的提供服務，在私有云與公有云的互動、網路元件安全、業務流量出入口、應用計算節點、中介軟體、資料庫、基礎設施等方面都有需要針對性地改造，改造升級後透過故障的演練來驗證多活的有效性，保障在 Iaas 出現不可控故障中，服務仍能正常為線上 App 與線下門店系統提供服務。

InfoQ：在您看來，是什麼樣的考量讓永輝決定進行雲遷移？

張明：

從 2020 年下半年開始，永輝雲創新零售的系統與永輝超市集團的供應鏈系統不斷融合，高速推進永輝集團的數字化轉型。在業務系統全鏈路融合打通的過程中，系統間互動逐漸頻繁起來，同時系統對於基礎設施架構的要求越來越高。

永輝雲創的新零售系統，從 2015 年在北京的 UCLOUD 公有云機房，而永輝超市集團的核心機房分佈在上海的騰訊 TCE 機房與福州自建 IDC。

所以在永輝集團這樣複雜的多雲多地，且流量跨華北、華東、華南多地域的 IT 架構下，C 端的交易鏈路、履約鏈路、B 端的供應鏈鏈路等核心鏈路在融合過程中產生大量跨地域請求，當存在迴圈呼叫時，鏈路延遲要求我們不得不進行技術改造。

而且由於是多雲架構，跨地域機房 VPC 劃分最早也是沒有合理規劃，存在內網 IP 衝突需 NAT 轉換才可互通，通訊層面難度加大，同時業務系統在使用遠距離對等連線專線中質量穩定性問題不斷浮現、運維需要基於多套雲介面完善自身 DevOps 系統，相容多雲環境，在這樣跨地域架構惡劣的情況下，很多底層運維的工作量是雙倍甚至三倍更多，難以高效完成數字化轉型過程中的業務融合改造。

2021 年初，永輝高層為了提升數字化轉型的效率與速度、為了提升系統鏈路響應質量、縮減多雲架構下的基建成本開銷，讓業務鏈路可在同城閉環的混合雲架構升級提上了議程，同時年初將 UCLOUD 上所有資源全量遷移至騰訊 TCE 上海機房的雲遷移專案也立項了。

InfoQ：雲遷移過程肯定不是一蹴而就的，可否按階段來分享一下？

張明：

我完整地負責與經歷了整個雲遷移的過程，最關鍵的階段其實也就是半年左右，大致可以拆解為下面七個部分：

評估遷移必要性。

很多事情可能是真的是要做了才知道會遇到什麼問題。

永輝系統整合過程中浮現出大量的框架不同、SDK 元件用法不同等技術棧不一致的情況，導致研發效率低下。

同時微服務 RPC 請求跨機房、MQ 訊息訂閱跨地域、異地部署多套 CICD 系統、基建監控系統有多套，這些各類系統層面阻塞數字化程序的問題逐漸暴露。而遇到的問題是不是可以透過雲遷移才能解決，還需要帶動大家一起透過評審來得到答案。

方案成本預估。

服務容器、中介軟體、資料庫、大資料、基礎設施等各關鍵團隊都是要給出預估的資源需求的，當然我們是需要多估一點的，要把業務的增量考慮進去。最後將這些估出的資源列表與估算的機房內單核成本聯動，計算產出一份遷移成本預估報告。

高層決策遷移。

當然收集必要資訊，把資料都透明化，能有條理的解釋資料的能力是相當重要的。比如遷移前 / 遷移後的成本，雲平臺的能力比較，業務穩定性指標預估、技術改造後的預期效果等都需要展示出來。最後還是讓高層在足夠清晰資料的情況下進行最後決策拍板。

招標採購上架。

基於成本預估，匹配機種，與相關人員確定完硬體規格後，迎來的就是數月漫長的採購與上架流程。與此同時，我們利用這個空檔將騰訊 TCE、騰訊公有云、永輝內部的團隊的合作方式與工作目標都明確下來了，在這個檔期內掃除所有已知技術問題。

輸出整體方案。

多雲的基礎設施、資料庫、中介軟體、容器平臺、DevOps 平臺、APM 系統、大資料系統等等各個領域都有各自分工產出遷移方案。作為遷移負責人，協助大家在有限時間攻克疑難問題，將零碎的技術點整合成完整的遷移方案。基於完整方案，排出相關里程碑與遷移時間軸，獲得團隊的統一認可，最後將方案清晰地公示到整個研發團隊。

遷移部署割接。

我們的目的是希望系統在不宕機的前提下進行無感遷移。永輝在遷移過程中的目標雲的部署持續了有 5～6 周左右，透過灰度框架的鋪開實施，部署期間不斷透過測試驗證部署的可靠性，不會對生產環境造成影響。由於 C 端流量需要在同一機房閉環，流量割接時間點是選擇在一週的最低峰期的 1：00 後日業務相對低峰的點進行的，幾百名同事參與並看緊自己的負責模組，齊心協力進行問題排查，完成流量割接。

系統磨合。

當然要想遷移後的系統穩定執行，測試必不可少，透過各類測試可以更好地找到業務系統與基礎設施的最優配置。第一：遷移前灰度測試 / 壓力測試，透過資料保證整個團隊有信心進行線上流量的割接；第二：割接後低峰期的冒煙功能測試全綠，保證遷移的成功且測試反饋割接無需回滾；第三：大促前的壓力測試，資料證明新環境與升級後的架構是可以支撐線上流量的，將系統擴容到位；

永輝的雲遷移是在 5 月底完成的，預留了 2 周左右時間為 618 大促磨合做了充分準備，透過團隊不斷最佳化相關係統用法與配置，永輝在 618 大促期間實現了系統 0 故障。

InfoQ：雲平臺選型是怎麼考慮的？中介軟體團隊、容器團隊、基礎架構團隊在這個過程中做了哪些配合上的事情？

張明：

永輝是自建與騰訊深度合作的 TCE 私有云機房，是一套同城兩中心的高可用機房，而且具有非常好的 BGP 多線網路接入條件，根據評估，將核心業務部署在私有云上是完全可以勝任目前雲原生系統的生態需求與未來發展的。

當然要完成遷移，各個團隊針對雲平臺的選型也是做了相關的妥協改造與變更。

基礎架構團隊：

在專線建設、內網段規劃、線下門店網路路由配置等方面要根據新的基礎架構進行網路層面調整，對於機房內部的基礎架構元件比如閘道器、負載、儲存池、虛擬計算池都要進行對應的高可用建設。且上層平臺團隊在部署過程中遇到任何與雲平臺相容性相關的問題，都需要積極主動跟蹤處理。

容器團隊：

基於混合雲的架構完成了 DevOps 系統的統一收口，整合混合雲平臺多 Kubernetes 容器介面的整合，使同一套編譯的 CI 映象可秒級部署至任意機房，將混合雲的運維操作平臺標準化了。基於混合雲平臺，可共用一套 HPA/VPA 的彈性體系，也是需要在自研系統上進行功能改造的。

當然微服務基礎映象也有針對雲平臺的系統進行吞吐量與網路相關最佳化，透過不斷測試最佳化來提升底層框架的穩定性。將容器、服務框架兩部分改動聯動，可以很好地進行流量在混合雲機房內的流轉控制。

運維團隊：

在部署前需要進行流量閘道器的改造，保障部署例項可完成流量灰度隔離，與灰度測試的鏈路支撐。生產環境的遷移必須使用同等環境測試驗證，然而生產環境上高峰期進行運維動作風險相當高，所以要保障有一個安全且不會影響真實使用者的灰度環境相當重要。運維的任務相對比較重，除了高壓力下的遷移部署外，對雲上的資產盤點（包括各類系統、負載元件、安全元件、DevOps 系統等）都需要一一盤點進行文件梳理標記，明確方案，保障資源不掉隊。

中介軟體與資料庫團隊：

負責將主流中介軟體進行容器化改造並完成雲原生化部署，包括 Redis、ES、MQ 等業務常用元件與 APM 系統相關元件的改造，保障相關中介軟體可高效在雲環境內拉起叢集，達到雲原生化的運維狀態。中介軟體與資料庫的資料遷移是相當重要的部分，考慮遷移過程中的專線佔用，遷移批次分佈都要有資料支撐，而且要有嚴格的遷移方案評審與資料一致性校驗來保障資料的安全。

InfoQ：永輝超市負責雲遷移的團隊有多少人？雲遷移涉及哪些風險？

張明：

雲遷移可以說是一個研發團隊全民參與的專案，在清晰戰略的前提下，各個團隊都有需要關注與配合里程碑產出的工作專案。在一個上百人虛擬團隊規模性質、包括有多雲公司三方人員協作、且割接時間節點要求苛刻的專案中，要保障系統可不宕機完成遷移，除了規避可預見、事後覆盤得到可複用的技術風險外。將協作流程合理地公示給團隊、清晰的設定里程碑等都可幫助專案降低風險。

要說到雲遷移最大的風險可能就是割接時間點帶來的，當要求在一個較短的時間內完成繁瑣的準備工作與流量割接，步驟會更加複雜，仔細去看的話，會發現許多細分步驟下質量的風險都會凸顯出來，所以遷移過程中的關鍵性決策還是需要是冒著風險進行實施的。

InfoQ：雲遷移之後的運維保障是如何處理的？

張明：

永輝的科技服務部門具備從客戶端到 IT 系統、IT 系統到雲基建，全鏈路的運維保障分工。在智慧運維方面也自有主要鏈路上的相關運維繫統，對混合雲架構下的高效故障處理上是有一些自己的心得的。

在遵守故障定級、恢復時長的要求的前提下，運維團隊可基於監控、實時流分析、DevOps 等效率工具高效拉動問題相關人員參與故障處理，在故障中將資損降至最低。

有無法快速定位問題的情況下，需要優先使用預定步驟止血，且第一時間引入雲基礎設施相關人員可大大縮短基礎設施故障帶來的故障恢復時間。

InfoQ：您認為傳統企業進行數字化轉型是否會面臨同樣的問題？有哪些問題可能是大家都要面對的？

張明：

當傳統業務具備一定規模，上雲與遷雲是傳統企業避不開的一個高風險決策項，必須要熟悉業內最新發展，且結合自身特點，來完成雲建設的決策。總的來說高層決策將決定高度，而團隊人員的技術能力將決定達到這個高度需要的時間與投入。

嘉賓介紹：

張明：擁有 15 年以上從業經驗，現任永輝超市科技服務部架構師，負責系統架構相關規劃與實施，輸出永輝數字化轉型所需運維能力。曾就職於 TutorABC、微軟等公司。在混合雲架構、微服務 / 中介軟體、軟體架構設計、APM 等領域具有豐富經驗。

活動推薦

在 12 月 26-27 日，ArchSummit 全球架構師峰會（北京站）即將落地北京，張明講師將會分享永輝超市的混合雲建設與運維，透過本次專題你將收穫微服務、中介軟體、基礎設施元件的大規模遷移方法，以及如何在混合雲中建設高可用系統與運維應對方式，希望可以為正在進行雲建設的你帶來啟發。

同時本次會議我們也配置了

微服務治理之基礎架構、微服務治理之業務架構、架構師成長、客戶端架構設計、資料庫與儲存技術、雲原生技術應用、質效度量體系和測試平臺建設、低程式碼實踐與應用、領域驅動設計方案落地、高併發架構設計

等專題，屆時歡迎你的參與。