去哪兒網業務大規模容器化最佳實踐

作者：鄒晟，去哪兒網基礎架構團隊高級 DevOps 工程師，現主要負責 CI/CD 平臺開發與維護，云原生技術研究與實作，同時也是 KubeSphere Talented Speaker，
陳靖賢，去哪兒網 DevOps 產品經理，目前主要負責在去哪兒傳播 DevOps 文化，調查、匯入和開發流程、工具、平臺的最佳實踐，幫助公司以更快的速度交付軟體，降低風險，降低運營成本

近幾年隨著云原生技術的成熟，Qunar 為了實作整個技術體系的演進，Qunar 在 2021 年向云原生邁出了第一步 -- 容器化 ， 落地程序包括了價值評估、基礎設施建設，CI/CD 流程改造、中間件的適配、可觀測性工具、應用自動化遷移等，遷移程序涉及到了 3000 個應用左右，涉及千人級研發團隊，是一個難度非常大的系統工程，這篇文章會講述遷移程序涉及到的 CI/CD 模型改造、自動化應用容器化改造等最佳實踐，

背景

容器化落地前的業務痛點

在容器化落地之前，我們經常會聽到來自不同角色的各種各樣的抱怨與吐槽：

• 領導層的聲音：服務器資源和維護成本太高了，我們必須降低成本！
• OPS 的聲音：有一臺宿主故障了，需要把上邊的服務趕快恢復！
• QA 的聲音：測驗環境好好的，為啥上線失敗了？
• 研發人員的聲音：業務高峰來啦，資源不夠用啦！趕快去擴容！哎! 擴容太慢了，

造成這些問題的因素主要包含：資源利用率、服務無法自愈、測驗環境與線上環境不一致，運行環境缺少彈性能力，

企業所面臨的商業環境是復雜多變的，當今環境的競爭例外激烈，而且不再是大魚吃小魚，而是快魚吃慢魚，通用電氣前 CEO Jack Welch 曾經說過：“如果外部變化的速度超過內部變化的速度，終結就不遠了”，我們的企業如何能在這樣的環境中存活發展呢？各個企業都在不斷的探索和實踐中前行，今年來，云原生技術日趨成熟，已經被廣大企業廣泛接受并采用，云原生技術可以幫助企業降低成本，加快業務迭代，對賦能企業的產業升級提供強有力的技術支撐，容器化作為云原生技術之一，成為 Qunar 擁抱云原生進行技術升級的重要一環，

容器化落地程序的挑戰與應對

全司范圍內進行容器化全面落地并不是一件容易的事，我們面臨了重重困難，但是我們為了最終目標的達成，想盡一切辦法去一一化解，

首先，涉及部門多: 容器化遷移涉及 OPS、基礎架構、資料組等基礎設施部門以及 20+業務部門，這么多的部門達成對目標的一致認同，并保持行動的協調一致是非常不容容易的，好在我們這個專案得到了公司高層的認可，并將此作為 2021 年的企業級目標，在企業級目標的引領下，各個部門協同一致，通力配合保障了專案的成功，

其次， 改造范圍大：由于歷史原因，我們的服務多是有狀態的，從中間件、發布系統到網路、存盤、日志收集、監控告警以及業務服務本身等等各個環節對機器名、IP、本地存盤等狀態有著強依賴，而容器本身是無狀態的，這就意味著我們需要從基礎設施、發布、運維的工具、平臺進行整體改造，針對這重重問題，我們進行了一一列舉，逐個擊破，最終滿足容器化遷移的條件，

再次，業務遷移成本高：本次遷移涉及應用數量大概有 3000 多個，遷移程序需要對應用進行升級改造、測驗回歸及上線，這個程序將花費大量人力，如何降低業務的遷移成本呢？我們支持將大部分的適配作業在中間件層進行統一支持，然后支持在業務代碼中進行中間件的自動升級，自動進行容器化遷移，通過持續交付流水線對遷移程序中的變更進行自動化的測驗與驗證，經過容器與虛機灰度混部觀察等手段大大降低了業務人工遷移的成本，

最后，學習成本高：我們的研發團隊有千人級的規模，對于新技術的引入與升級，研發同學需要花費額外的成本進行學習和使用，為了降低大家的學習成本，我們通過平臺工具屏蔽差異性操作以及技術細節，通過可視化配置、引導式操作，優化持續交付流程等方式來降低業務的學習成本，

容器化后的收益

經過 2021 年一年時間，我們完成了容器化基礎設施建設，工具平臺的升級改造以及 90%應用的容器化遷移(應用總數 3000+)，從效果資料來看，容器化虛擬比例從 1：17 提升到 1：30， 資源利用率提升 76%；宿主運維時間之前以天為單位，容器化以后變成了分鐘級，運維效率提升了 400 倍；由于容器化啟動時間的縮短以及部署策略的優化，應用的交付速度提升 40%；K8S 集群提供了服務自愈能力，應用運行程序中平均自愈次數達到 2000 次/月；另外，容器化落地也為公司進行下一步云原生技術的深入推廣與落地奠定了基礎，

持續交付

專案研發流程

Qunar 采用了業務驅動的價值流與以應用為中心的持續交付作業流的雙流模型，企業以業務價值交付為目標，在交付程序中，各個階段的交付物會在多個角色中的流轉，在流轉程序中難免會出現不同程度的浪費，為了有效對價值交付的效率進行有效度量與優化提升，我們不僅僅需要關注開發程序中的效率提升，還需要關注開發前的效率提升，我們將持續交付作業流的流轉與價值流的流動進行聯通，希望可以實作從專案域、開發域、測驗域到運維域的流程自動流轉的，但是在容器化之前，由于環境不一致、各階段配置的不一致性等原因，導致交付程序中，交付流程在各階段間流轉時不可避免的存在人工干預的情況，容器化之后，我們參照云原生的 OAM 模型，對應用進行了規范化定義，建立應用畫像，統一術語，消除資料孤島，使流程可以順暢高速流轉，

應用畫像

針對上面專案的流程流轉，最重要的一個連接器就是 App code, 因此我們也針對它做了抽象，畫像定義:

開發人員在面對開發、測驗和生產等復雜的環境時、需要撰寫和維護多分應用部署組態檔；運維人員需要理解和對接不同的平臺，管理差異巨大的運維能力和運維流程，

參照云原生中的開發應用模型原則，我們通過建立應用畫像，指定應用的標準化定義，我們開發和運維人員通過標準的應用描述進行協作，輕松實作應用的“一鍵部署”、“模塊化運維”，無須糾結于服務的開通配置和接入作業，提升應用交付與運維的效率和體驗，

借助應用的規范化，將應用平臺進行統一化與規范化，我們將原來的以資源為中心，轉變為以應用為中心，平臺架構如下:

多云協同

基礎設施資源層: 底層資源既支持 KVM 也支持容器，這些資源都是跨機房部署，同時為了讓底層資源更具彈性，我們對接了公有云，

平臺層: 基于 K8s、KubeSphere 多集群管理、Service Mesh、Serverless 等云原生技術來提高技術先進性和技術的架構演進，

資源調度:

• 會考慮節點的親和性: 機器配置， 普通磁盤、SSD， 千兆網卡、萬兆網卡
• 容量預估：發布前預計算, 如果資源不足，禁止發布
• 機器負載：盡可能讓集群所有節點負載均衡

雙 Deployment 發布

優點：

1. 降低了操作復雜度， 操作只包含 create, scale, delete， 而單個 Deployment 更新程序可能會有更新程序失敗，卡在中間狀態， 升級和回滾都無法進行的時候
2. 支持分批操作， 發布流程更可控
3. 更新 Deployment label 變為可能

缺點：

• 需要記錄和控制 Deployment 狀態，操作相對于單 Deployment 會相對復雜一些

業務應用自動遷移方案

這次容器化需要遷移 3000+ 的應用，為了減少開發測驗人員的遷移成本，我們提供了一個自動升級 Java SDK、自動遷移容器的方案，

自動遷移方案:

1. 前置校驗

   • 驗證是否參考了自動升級的 SDK
   • 編譯階段驗證是否有不適合容器化場景使用的 Java 方法
     比如驗證是否呼叫了依賴 hostname 的方法，如果有的化會提前提示容器發布失敗， 因為容器場景 ip 變化是常態，hostname 也是經常變化的，過去業務線依賴 hostname 做業務邏輯區分的會有問題

2. 測驗環境驗證

   自動升級 SDK 后在測驗環境發布并驗證應用的容器化升級是否 ok

3. 線上環境驗證

   • 灰度發布到線上，暫時不接入流量
   • 通知應用 owner 做自動化測驗
   • 驗證沒問題，則接入線上流量

4. 混合部署

   • 線上容器和 KVM 同時部署，流量比例根據實體比例調配
   • 關注指標與告警

5. 容器接入全部流量

   容器全量部署，KVM 容量全部摘除 （KVM 會保留幾天觀察）

6. 觀察

   關注容器全量后的業務監控指標，如果發現例外及時遷回 KVM

7. KVM 回收

   為了快速騰出資源到 K8s 集群，我們會在規定期限內通知應用的 owner 回識訓器, 如果超過規定時間(7 天)，遺留的 KVM 資源回被強制回收

自動升級 SDK 流程

tcdev bom 是公司統一管理二方包和三方包依賴的公共基礎組建，絕大多數的 Java 應用都會使用這個組建，因此我們的升級 SDK 方案就是在編譯程序自動檢測并升級 tcdev 版本，

升級 SDK 的前置條件

升級步驟

事后復盤的時候，很多業務同學也都反饋這個自助升級遷移的方式為他們節省了大量時間，價值非常明顯，得到了大家的認可，

總結

在云原生轉型的程序中，如何讓業務更順暢的享受到云原生的紅利是非常有挑戰的，希望這篇文章能給剛步入云原生的同學帶來一些啟發，云原生的路上，我們一起共勉！

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：華為云企業級Redis：助力VMALL打造先進特征平臺

下一篇：LINE拉群軟體，如何開發？小投大創，教你玩轉自動化