背景

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

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

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

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

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

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

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

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

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

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

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

保持兼容

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

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

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

• 如果需要?jiǎng)h除已有參數(shù)，需要與所有依賴方確認(rèn)?？梢韵葘?shù)標(biāo)記為 Deprecated 而不是直接移除。

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

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

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

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

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

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

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

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

3. 批量升級(jí)容器、更新鏡像。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 保證分布式一致性

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

• 負(fù)載均衡

• 流量調(diào)控與請(qǐng)求降級(jí)

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

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

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

風(fēng)險(xiǎn)防控

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

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

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

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

總結(jié)

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

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

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

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

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

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

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

希望本次的分享能夠給大家?guī)?lái)一些幫助和啟發(fā)。

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

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