背景

在互聯(lián)網(wǎng)行業(yè)，線上服務(wù)的升級更新可謂家常便飯。據(jù)統(tǒng)計(jì)，在過去的一個季度中閑魚工程師們執(zhí)行了千余次發(fā)布，總計(jì)更新的代碼數(shù)量超過百萬行。

這些發(fā)布中，有一些可能只更新了幾行代碼，而有一些可能執(zhí)行了整個集群的遷移升級。而無論這些變更的影響面有多大，我們都必須保證線上服務(wù)的可用性，用戶無感知。本文將以閑魚搜索服務(wù)的遷移升級為例，向大家介紹其背后的技術(shù)方案。

閑魚搜索服務(wù)基本架構(gòu)

閑魚的底層搜索服務(wù)由查詢規(guī)劃服務(wù) Search Planner、查詢理解服務(wù) Query Planner、打分排序服務(wù) Rank Service 以及搜索引擎 Heaven Ask 3 所組成。它們之間的相互調(diào)用關(guān)系如下圖所示：

可以看到，整個搜索服務(wù)是由多個相互獨(dú)立的微服務(wù)所構(gòu)成的。不同的微服務(wù)之間相互隔離，通過預(yù)先向外暴露的接口提供服務(wù)。所有的微服務(wù)最終通過 Search Planner 收口，對外提供統(tǒng)一、完整的搜索能力。

在底層搜索服務(wù)之上，還有業(yè)務(wù)邏輯層和接入網(wǎng)關(guān)層，具體架構(gòu)在此不再贅述。用戶的搜索請求先通過網(wǎng)關(guān)層轉(zhuǎn)發(fā)給邏輯層處理，再向底層搜索服務(wù)發(fā)起搜索請求。這條請求鏈上包含數(shù)十個集群，調(diào)用深度達(dá)到兩位數(shù)，整個過程中提供服務(wù)的服務(wù)器數(shù)量可能有成百上千。

對于這樣一個復(fù)雜的系統(tǒng)，升級過程顯然無法一蹴而就。好消息是各個微服務(wù)之間合理的解耦合給升級工作帶來了很大的便利，有效避免牽一發(fā)動全身而導(dǎo)致無從下手，使我們可以分門別類地處理升級問題。

• 注1：Search Planner 是一個基于函數(shù)式、服務(wù)化、可視化、并行化開發(fā)框架所構(gòu)建的搜索服務(wù)網(wǎng)關(guān)層。

• 注2：Query Planner 的主要作用是理解用戶輸入，然后對搜索詞進(jìn)行算法優(yōu)化。最終獲得更好的搜索召回結(jié)果。

• 注3：Rank Service 是實(shí)時打分排序服務(wù)，它的作用是根據(jù)多維度的特征對搜素引擎召回的海選結(jié)果進(jìn)行算法打分。分?jǐn)?shù)越高的商品就越有機(jī)會出現(xiàn)在搜索結(jié)果的前列。

• 注4：Heaven Ask 3 （問天3）是阿里巴巴研發(fā)的一款穩(wěn)定高效、功能強(qiáng)大的搜索引擎。為阿里集團(tuán)包括淘寶、天貓?jiān)趦?nèi)的核心業(yè)務(wù)提供搜索服務(wù)支持。

保持兼容

開始升級之前，我們首先需要確認(rèn)被升級的服務(wù)是否保持了向前與向后兼容性。保持兼容不僅減少了工作量，也減少了升級所導(dǎo)致的故障風(fēng)險。

為了盡量避免升級導(dǎo)致的不兼容，我們可以總結(jié)一些開發(fā)原則：

• 遠(yuǎn)程過程調(diào)用（RPC）需要能夠忽略未知參數(shù)，并且允許缺失參數(shù)。

• 如果需要刪除已有參數(shù)，需要與所有依賴方確認(rèn)。可以先將參數(shù)標(biāo)記為 Deprecated 而不是直接移除。

• 使用參數(shù)時，區(qū)分缺省值和缺失值。

• 如果接口無法保持兼容，則創(chuàng)建新接口代替舊接口。不要破壞舊接口的兼容性。

在升級時，先升級那些沒有外部依賴的服務(wù)。等到被依賴方升級完畢之后，再去升級依賴方。確定了每一個服務(wù)的升級順序之后，我們再根據(jù)服務(wù)的實(shí)際情況確定升級方案。

無狀態(tài)服務(wù)升級

正式進(jìn)入升級流程，我們首先關(guān)注搜索鏈路中的被設(shè)計(jì)成無狀態(tài)服務(wù)的部分，例如用于處理業(yè)務(wù)邏輯的 Java 微服務(wù)、用于處理查詢邏輯的 Search Planner 等。它們的共同特點(diǎn)是，每個請求處理完畢之后，關(guān)于該次請求的資源即被釋放。不同的請求之間沒有相互依賴和時序要求。同一個無狀態(tài)服務(wù)內(nèi)不同的機(jī)器節(jié)點(diǎn)是完全等價的。

無狀態(tài)服務(wù)的特點(diǎn)使得它們很容易通過水平擴(kuò)展來動態(tài)擴(kuò)縮容。因此在保證兼容的前提下，它們的升級流程相對通用并且簡單：

1. 根據(jù)服務(wù)最小可用度決定分批數(shù)。

2. 選取一批待更新的容器，停止服務(wù)。

3. 批量升級容器、更新鏡像。

4. 等待這一批容器全部恢復(fù)服務(wù)后，繼續(xù)更新下一批容器。

一般來說我們可以通過把狀態(tài)存儲在消息隊(duì)列、緩存、數(shù)據(jù)庫或者其它外部中間件中來達(dá)成服務(wù)的無狀態(tài)。把服務(wù)設(shè)計(jì)成無狀態(tài)的好處顯而易見：升級時不需要分配額外的機(jī)器資源，升級速度快，變更代價小，因而可以支持頻繁的迭代更新。但是，這種設(shè)計(jì)也給狀態(tài)訪問和更新帶來了額外的開銷，在某些性能敏感的場合可能是不適用的。

有狀態(tài)服務(wù)升級

我們繼續(xù)關(guān)注有狀態(tài)的部分。有狀態(tài)服務(wù)升級的麻煩之處在于，狀態(tài)的存儲、恢復(fù)、轉(zhuǎn)移往往由服務(wù)根據(jù)實(shí)際情況單獨(dú)設(shè)計(jì)（或者根本沒有設(shè)計(jì)），因而升級較為困難。我們可以簡單列舉一些相對通用的有狀態(tài)服務(wù)升級可選方案。

• 接入層網(wǎng)關(guān)提供熱更新的能力（例如 Nginx），把狀態(tài)的保持隔離在接入層內(nèi)部。適合需要長時間保持狀態(tài)的場景。

• 漸進(jìn)更新，新請求逐步切換到新服務(wù)上處理，舊服務(wù)處理完存量請求后銷毀。適合短時間保持狀態(tài)的場景（例如游戲服務(wù)、實(shí)時音視頻通訊服務(wù)）。

• 創(chuàng)建全新的服務(wù)副本，通過數(shù)據(jù)雙寫保持新舊服務(wù)狀態(tài)一致，逐步用新服務(wù)取代舊服務(wù)。

在閑魚搜索的架構(gòu)中，搜索引擎本身提供的雖然是無狀態(tài)服務(wù)，但是引擎內(nèi)部保存了用于處理索引分區(qū)，增量進(jìn)度的各種狀態(tài)。最終使用的升級方案如下：

1. 使用新版本鏡像創(chuàng)建一個完全獨(dú)立的新引擎。

2. 新舊引擎全量數(shù)據(jù)同步。

3. 增量數(shù)據(jù)同時向新舊引擎發(fā)送。

4. 新引擎上線，逐步擴(kuò)大承接流量的比例。

5. 舊引擎不再承接流量后下線。

和無狀態(tài)服務(wù)的升級相比，這種方式不僅額外使用了一倍的機(jī)器資源，而且每次升級都需要做一次復(fù)雜而繁瑣的服務(wù)配置。如果服務(wù)本身不是無狀態(tài)的，還需要自行編碼實(shí)現(xiàn)切流邏輯，保證同一個用戶的請求能夠落到同一個集群上。整體升級成本較為昂貴，只適合更新頻率非常低的服務(wù)。如果服務(wù)的更新頻率較高，則應(yīng)該根據(jù)服務(wù)的實(shí)際情況設(shè)計(jì)實(shí)現(xiàn)升級成本更低的方案。

服務(wù)發(fā)現(xiàn)

在升級過程中，服務(wù)發(fā)現(xiàn)機(jī)制承擔(dān)著重要作用。它為我們提供了以下功能：

• 保證分布式一致性

• 服務(wù)優(yōu)雅上下線

• 負(fù)載均衡

• 流量調(diào)控與請求降級

• 同機(jī)房優(yōu)先調(diào)度

• 跨機(jī)房容災(zāi)調(diào)度

服務(wù)發(fā)現(xiàn)是流量調(diào)控的總閥門。一個成熟穩(wěn)定的服務(wù)發(fā)現(xiàn)機(jī)制不僅可以有效避免發(fā)布導(dǎo)致的請求成功率抖動，也為發(fā)生異常時快速回滾止血提供了保證。

風(fēng)險防控

對搜索鏈路的每一個集群按照依賴順序進(jìn)行服務(wù)升級、掛載、切流無疑是高危操作，稍有不慎就可能引起線上故障。因此，我們按照阿里巴巴安全生產(chǎn)三板斧原則對升級流程進(jìn)行了梳理：

• 可監(jiān)控：重要鏈路的重要指標(biāo)均提前保證監(jiān)控覆蓋。例如請求總量，請求成功率，請求響應(yīng)時長等等。確保重大問題可以通過監(jiān)控指標(biāo)及時發(fā)現(xiàn)。

• 可灰度：任何變更都不允許未經(jīng)灰度直接全量發(fā)布到線上。對于無狀態(tài)服務(wù)，我們一般通過調(diào)整服務(wù)發(fā)現(xiàn)中的權(quán)重或者調(diào)整機(jī)器比例來完成灰度放量。對于部分不能隨機(jī)灰度的情形，我們設(shè)計(jì)了按用戶分批放量的機(jī)制。

• 可回滾：變更系統(tǒng)提供了通用的一鍵回滾能力，但并非是最快的方式。在很多情況下，我們在執(zhí)行變更前就做好了把待更新的機(jī)器或集群在服務(wù)發(fā)現(xiàn)上重新掛載或移除的準(zhǔn)備，從問題發(fā)現(xiàn)到恢復(fù)的時間基本是秒級的。

總結(jié)

綜上所述，復(fù)雜系統(tǒng)不停機(jī)升級的原則和流程可以概括如下：

1. 服務(wù)間解耦與隔離，確保單次升級的范圍和影響可控。

2. 根據(jù)兼容性和依賴關(guān)系決定服務(wù)的升級順序。

3. 根據(jù)服務(wù)是否無狀態(tài)決定升級方式。

4. 提前準(zhǔn)備好監(jiān)控和回滾方案，灰度升級。

閑魚搜索服務(wù)升級的整個執(zhí)行過程經(jīng)歷了兩個月的時間。這其中我們既保證了用戶無感知，線上服務(wù)穩(wěn)定運(yùn)行，也保證了與我們合作開發(fā)的算法團(tuán)隊(duì)以及其他工程團(tuán)隊(duì)的正常開發(fā)不受影響。

在實(shí)際執(zhí)行的過程中，我們還遇到了很多細(xì)節(jié)上的問題。例如創(chuàng)建新服務(wù)時未能提前合理預(yù)估預(yù)算需求，導(dǎo)致升級過程中不斷挪借預(yù)算，拆東墻補(bǔ)西墻。又比如異地多活部署帶來的延遲問題迫使服務(wù)保持單元化，給升級過程中的流量調(diào)控工作帶來了很多挑戰(zhàn)。這些暴露的問題也為我們繼續(xù)完善架構(gòu)和方案提供了指引。

希望本次的分享能夠給大家?guī)硪恍椭蛦l(fā)。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝