閒魚應用遷移實踐

語言: CN / TW / HK

作者:閒魚技術——九七

1. 背景

idlecenter是閒魚服務端元老級應用,在2013年6月idlecenter寫下了第一行程式碼,隨後陪伴閒魚走過了8年的時間。

隨著閒魚業務規模的不斷龐大,業務複雜度的不斷增加,idlecenter逐漸暴露出一些問題:

•應用的垂直業務邊界劃分和架構分層不清晰,不同領域的業務程式碼都在idlecenter上迭代,業務程式碼深度耦合•新的業務不斷疊加,老的業務不能及時清理下線,應用規模不斷膨脹

直接引發的影響有:

•研發效率低:多個團隊幾十個研發共同維護上百個業務,每次釋出都會有十幾個分支,每增加一個分支,都會面臨程式碼衝突的風險。據統計一次應用釋出構建加部署需要半個小時,分支衝突解決需要二十分鐘,嚴重影響開發效率。

長遠影響:

•穩定性:業務不能隔離,核心業務與非核心業務都在一個應用上,相互干擾,穩定性不能保障。例如一個非核心業務把資源池打滿,就會導致核心服務不能提供服務,引發線上故障•業務垂直化衝突:閒魚在業務規模快速發展的過程也會進行人員與組織架構的調整。而idlecenter作為一個單體應用,應用架構和人員結構不同態。導致許可權不能收口,規範不能拉齊。隨著沒有規範的業務程式碼不斷迭代,應用的維護成本指數級的增加。

為了解決idlecenter的各種問題,我們從7月份開始對idlecenter進行拆分遷移。到目前我們idlecenter整體遷移進度過半,人力投入成本不到20d,遷移零故障。

本文把我們這次遷移的思路和實踐經驗沉澱下來,希望能為做應用遷移的同學提供一些思路。

遷移總體分為兩個部分:

開發期的程式碼遷移

執行期的流量遷移

2. 程式碼遷移

在開發期的程式碼遷移環節,我們需要思考的問題是:

•程式碼哪些要遷?•怎麼遷?

這裡我們沉澱了關於程式碼遷移的普適性原則:

•明確遷移的邊界,這裡的邊界包含兩個部分:遷移方案的侷限性、遷移粒度

•明確遷移方案的侷限性,明確支援遷移的服務與不支援遷移的服務。例如在我們這次遷移過程中,明確了對消費端服務RPC框架版本的要求,明確了不支援訊息的遷移。在做遷移服務梳理的時候,我們就需要初步識別並擇出這部分邊界外的服務,在程式碼遷移過程中,也要留意是否有遺漏的沒有排除乾淨的服務。•明確遷移粒度,固定遷移的粒度後能夠將應用垂直進行拆解,合理規劃應用拆分後的邊界。例如在我們方案中,遷移明確的以RPC服務為粒度,做遷移梳理時每個遷移模組的都是一個垂直的RPC服務,每個RPC服務的歸屬領域清晰,同時遷移方案調研時能明確的從RPC服務出發,來輸出一個橫向解決所有RPC服務遷移的解決方案。

•關注拆分本身,遷移過程保持新老應用程式碼的一致性,需要做到:

•不做程式碼重構。程式碼遷移過程也是一次程式碼review過程,中間或許會發現以前寫的程式碼不優雅不簡潔,或有設計缺陷,這時我們應該做的是保持程式碼的一致性。線上執行的程式碼往往有QA的測試用例與迴歸驗證覆蓋,保證風險收斂在可控的範圍內。而遷移過程的每一行程式碼變更,都有可能成為逃逸在測試用例與迴歸驗證外的“地雷”。•不夾帶私貨。這與不做程式碼重構略有重疊,說的是程式碼遷移過程要乾淨,杜絕在程式碼遷移過程中順帶實現額外的業務邏輯,做“功能拓展”。

•要遷的乾淨,程式碼遷移不僅包含應用內的程式碼,還需要關注應用外的與應用繫結的配置與邏輯:

•中介軟體相關配置:例如應用上的RPC框架配置,資料庫中介軟體配置,開關配置,配置中心的配置等都需要關注是否和應用繫結,在程式碼遷移的時候也要將相關配置遷出•中臺相關配置:例如閒魚可能依賴了關鍵詞過濾中臺,將程式碼遷移過程,也需要遷移中臺相關配置,為新應用配置中臺許可權。

3. 流量遷移

在執行期的流量遷移環節,我們主要考慮的兩個問題是:

•遷移成本:idlecenter中的服務依賴拓撲復雜。推動一個服務遷移可能牽涉到多個上游消費端服務,需要多個團隊人員的配合,需要極高的時間與人力成本。如何減少遷移的成本。•穩定性:流量遷移就是高速公路上邊跑邊換引擎,我們需要如何保障流量遷移過程的穩定性。

3.1. 遷移方案

太高昂的遷移成本會為遷移專案的推進增加很多阻力,因此在方案調研階段,需要關注遷移成本問題。 我們在方案調研階段明確了目標:

•遷移過程流量可控,具備灰度切流的能力,這是流量遷移穩定性的基礎•遷移不需要改造服務消費方程式碼。改造成本儘可能低•遷移過程能夠對服務消費方透明,可以在服務消費方無感知的情況下完成平滑遷移

最終我們設計了基於HSF路由功能的平遷方案。

HSF全稱High-Speed Service Framework, 是一個集團內的RPC框架。直接對標的產品是Dubbo。其執行機制總體如下:

引用自hsf-guide文件

涉及核心元件:

•註冊中心:用於服務註冊發現•規則中心:可以配置和推送服務治理規則。應用開發人員可以在控制檯編輯儲存規則,規則中心中介軟體會推送到所有指定服務端。

我們方案複用了HSF框架中的服務呼叫路由規則能力。通過路由規則介入服務消費方的選址邏輯,完成服務提供方的流量遷移。

基於HSF的平遷方案,我們實現了:

•服務消費方零改造成本。•遷移過程對服務消費方透明。

最終體現在人力成本上的結果是:遷移成本降到最低,一個人一個星期可以完成一個服務的遷移上線。

解決了遷移成本的問題後,我們需要解決遷移最重要的問題:穩定性保障。

3.2 穩定性建設

關於流量遷移過程的穩定性,我們的思路是複用集團內部沉澱的安全生產方法論——安全生產三板斧:可灰度、可觀測、可回滾。圍繞安全生產三板斧構建穩定性體系。

可灰度實際就是對HSF平遷方案的灰度能力做驗證,確保應用在平遷過程中流量分佈能符合預期。我們需要考慮的問題有:

•灰度能力:HSF平遷方案是否具備灰度能力•流量傾斜驗證:HSF路由規則是否會導致流量傾斜。邏輯機房之間的流量,邏輯機房內機器的流量是否均勻分佈。•RT影響驗證:HSF路由規則額外帶來的路由選址環節,帶來的RT影響有多少,是否在可接受範圍內•切流流量無損驗證:調整灰度權重過程中,是否能平滑,是否會導致流量損失

其次,我們需要驗證HSF平遷方案的可回滾能力:

•回滾能力:HSF平遷方案是否具備回滾能力•回滾生效時間:HSF平遷方案回滾生效時間

針對以上待驗證點,我們在測試環境做方案POC驗證,輸出了《HSF平遷方案可行性報告》。簡單總結驗證結果:

•方案具備灰度能力、回滾能力•RT影響在3ms以內,可以忽略不計•機房間,機房內流量均勻分佈,不會帶來切流流量損失或導致流量傾斜問題•路由回滾生效時間在1s以內

可灰度與可回滾能力解決了釋出過程中影響面可控的問題。而可觀測性是我們穩定性保障的最後一道屏障。可觀測性是否準確細緻決定了我們灰度平遷過程能否平穩落地。

在我們實踐中可觀測性建設分為兩個部分:

•從監控告警出發,我們需要case by case梳理業務背景,針對性的配置監控告警,例如對於敏感詞過濾服務,我們不僅需要關注它的呼叫成功率,也要關注服務的敏感詞命中率。除了業務層面的監控,我們再配合配置資源層面的監控,例如流量分佈、QPS、CPU記憶體使用率,來整體的把握服務健康狀態•新服務釋出上線後,我們需要QA介入對服務進行迴歸驗證。平遷服務我們關注的是新老服務提供的程式碼邏輯是否是一致的。為此我們接入了集團內的鳳凰迴歸平臺,鳳凰能夠錄製線上流量,並在指定的灰度機器上回放,能快速驗證新老應用服務邏輯是否保持一致。

在穩定性體系的建設下,我們最終實現了遷移零故障的成績。

4. 最後

最後,要做好應用遷移還有非常重要的一點:做好checklist。提前制定好遷移步驟,切流放量節奏;每次放量時能對影響面有大概量級的評估,在上線前能在測試環境完整演練一遍流程。 這裡我列出我們遷移過程的checklist模板:

•遷移確認

•RPC框架版本、與路由規則互斥的其他規則•中介軟體配置、中臺配置遷出確認•新應用許可權確認

•消費端服務消費場景

•消費場景、QPS量級

•資源評估•監控告警配置•迴歸策略•應急預案•釋出流程

•切流時間、切流權重•影響請求量•切流路由規則