作者：鄒晟，去哪兒網基礎架構團隊高階 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 釋出！