本文由騰訊技術(shù)團(tuán)隊(duì)羅國(guó)佳分享，原題“微信讀書(shū)后臺(tái)架構(gòu)演進(jìn)之路”，下文有修訂和重新排版。

1、前言

今年是微信讀書(shū)上線10周年，后臺(tái)技術(shù)架構(gòu)也伴隨著微信讀書(shū)的成長(zhǎng)經(jīng)歷了多次迭代與升級(jí)。每一次的組件升級(jí)與架構(gòu)突破，在一個(gè)運(yùn)行了10年的系統(tǒng)上落地都不是一件容易的事情，需要破釜沉舟的決心與膽大心細(xì)的業(yè)務(wù)聯(lián)動(dòng)。

微信讀書(shū)經(jīng)過(guò)了多年的發(fā)展，贏得了良好的用戶(hù)口碑，后臺(tái)系統(tǒng)的服務(wù)質(zhì)量直接影響著用戶(hù)的體驗(yàn)。團(tuán)隊(duì)多年來(lái)始終保持著“小而美”的基因，快速試錯(cuò)與迭代成為常態(tài)。后臺(tái)團(tuán)隊(duì)在日常業(yè)務(wù)開(kāi)發(fā)的同時(shí)，需要主動(dòng)尋求更多架構(gòu)上的突破，提升后臺(tái)服務(wù)的可用性、擴(kuò)展性，以不斷適應(yīng)業(yè)務(wù)與團(tuán)隊(duì)的變化。

2、整體架構(gòu)設(shè)計(jì)

微信讀書(shū)是獨(dú)立于微信的App，且由于歷史原因，開(kāi)發(fā)及運(yùn)維環(huán)境均存在一定的差異與隔離。因此，微信讀書(shū)的后臺(tái)服務(wù)實(shí)現(xiàn)了從接入層到存儲(chǔ)層的一整套完整架構(gòu)。

架構(gòu)上分解為典型的接入層、邏輯層和存儲(chǔ)層：

1）接入層：按業(yè)務(wù)劃分為多個(gè)CGI服務(wù)，實(shí)現(xiàn)了資源隔離。在CGI層面還實(shí)現(xiàn)了如路由、頻控、接入層緩存、長(zhǎng)連接等。

2）邏輯層：采用WRMesh框架構(gòu)建了多個(gè)微服務(wù)，這些微服務(wù)按業(yè)務(wù)場(chǎng)景進(jìn)行劃分，實(shí)現(xiàn)了不同模塊間的解耦?？蚣芤蔡峁┝巳鏡PC、路由發(fā)現(xiàn)、過(guò)載保護(hù)、限流頻控、監(jiān)控上報(bào)等能力。

3）存儲(chǔ)層：主要采用PaxosStore存儲(chǔ)用戶(hù)數(shù)據(jù)，分為K-V和K-Table兩種類(lèi)型，具備高可用、強(qiáng)一致的特性，針對(duì)String和Table兩種類(lèi)型定制了緩存中間件，以適配某些業(yè)務(wù)場(chǎng)景下對(duì)訪問(wèn)存儲(chǔ)的性能要求。BookStore提供書(shū)籍的存儲(chǔ)服務(wù)，滿足讀書(shū)場(chǎng)景下對(duì)書(shū)籍的拆章、修改、下載等需要。此外，也不同程度地使用了騰訊云的PaaS存儲(chǔ)服務(wù)，以靈活滿足更多場(chǎng)景需要。

具體的業(yè)務(wù)邏輯不再贅述，下面簡(jiǎn)單介紹下微信讀書(shū)近幾年在后臺(tái)架構(gòu)上的一些演進(jìn)。

3、異構(gòu)服務(wù)間調(diào)用：RPC框架

微信讀書(shū)后臺(tái)微服務(wù)源于Hikit框架，采用C++開(kāi)發(fā)。該框架誕生于廣研、QQ郵箱年代，在性能、容災(zāi)、運(yùn)維、監(jiān)控層面都經(jīng)受了線上的考驗(yàn)，在微信讀書(shū)上線初期作為主要框架，支撐了后臺(tái)服務(wù)長(zhǎng)達(dá)數(shù)年。

隨著微信讀書(shū)的發(fā)展，越來(lái)越多異構(gòu)的系統(tǒng)發(fā)展起來(lái)。例如推薦算法系統(tǒng)是獨(dú)立部署在TKE上的容器服務(wù)，采用GO語(yǔ)言開(kāi)發(fā)，好處是歷史負(fù)擔(dān)少，運(yùn)維更加方便、開(kāi)發(fā)更加便捷。

兩套系統(tǒng)同時(shí)存在帶來(lái)的問(wèn)題是如何做好服務(wù)治理，推薦系統(tǒng)需要頻繁調(diào)用后臺(tái)基礎(chǔ)模塊獲取用戶(hù)數(shù)據(jù)，必須要有一套完善的路由管理、容災(zāi)機(jī)制，且考慮到是異構(gòu)服務(wù)，開(kāi)發(fā)語(yǔ)言也不相同，如果為每種語(yǔ)言都定制開(kāi)發(fā)一套服務(wù)治理框架，代價(jià)會(huì)非常高。

在這個(gè)階段，我們開(kāi)發(fā)了WRMesh框架，采用Sidecar+Business的方式解決這個(gè)問(wèn)題。

Sidecar專(zhuān)注于處理網(wǎng)絡(luò)層的邏輯，和Business業(yè)務(wù)層分開(kāi)為兩個(gè)進(jìn)程，由WRMesh腳手架生成代碼，上層業(yè)務(wù)無(wú)需感知。

Sidecar集成了Hikit框架中用于服務(wù)治理的核心邏輯：通過(guò)UnixSocket與Business進(jìn)行通信，代理Business的所有網(wǎng)絡(luò)讀寫(xiě)。當(dāng)Business進(jìn)程中需要發(fā)起網(wǎng)絡(luò)請(qǐng)求時(shí)，由WRMesh生成的Client代碼會(huì)自動(dòng)識(shí)別當(dāng)前是否在mesh環(huán)境中，并轉(zhuǎn)發(fā)請(qǐng)求給Sidecar，由Sidecar完成接下來(lái)的網(wǎng)絡(luò)處理。

因此：Business進(jìn)程可以由任意語(yǔ)言任意框架開(kāi)發(fā)，只要遵循Sidecar的通信協(xié)議，只需要薄薄的一層網(wǎng)絡(luò)協(xié)議轉(zhuǎn)換即可接入到Hikit的服務(wù)治理框架中。

另外：對(duì)于某些有特殊路由邏輯的Client，如KV訪問(wèn)、Batch請(qǐng)求等，代理轉(zhuǎn)發(fā)并不能滿足要求，因此Sidecar還提供了插件能力集成這些Client邏輯，最大限度為異構(gòu)Business業(yè)務(wù)提供原生C++的能力。

隨著WXG容器平臺(tái)P6N的建設(shè)越來(lái)越完善，許多微信的能力也是基于P6N提供，我們也在思考如何逐步遷移到P6N。由于微信讀書(shū)后臺(tái)運(yùn)維目前依賴(lài)于企微團(tuán)隊(duì)，有獨(dú)立于P6N的一套運(yùn)維體系，我們負(fù)責(zé)業(yè)務(wù)和架構(gòu)開(kāi)發(fā)。

如果要一刀切把所有后臺(tái)服務(wù)遷移至P6N，將會(huì)面臨幾個(gè)問(wèn)題：

1）框架代碼需要重新適配，開(kāi)發(fā)環(huán)境和現(xiàn)網(wǎng)環(huán)境都有巨大的改造成本。

2）遷移不是一蹴而就，后臺(tái)上百個(gè)服務(wù)在遷移過(guò)程中，會(huì)存在新舊服務(wù)互調(diào)的問(wèn)題，由于運(yùn)維環(huán)境不互通，微服務(wù)之間無(wú)法完成服務(wù)治理，這種互相調(diào)用最終只能通過(guò)Proxy來(lái)轉(zhuǎn)發(fā)，不僅增加了網(wǎng)絡(luò)的失敗率，時(shí)延增加，最關(guān)鍵的是這個(gè)過(guò)程會(huì)讓容災(zāi)體系大打折扣。

3）存儲(chǔ)模塊的遷移成本和風(fēng)險(xiǎn)巨大，如果不遷移存儲(chǔ)模塊只遷移了邏輯模塊，那勢(shì)必又會(huì)存在2中的問(wèn)題，這個(gè)過(guò)程很難收尾。

考慮到人力成本及投入性?xún)r(jià)比，我們最終采用了折衷的方案：

1）一方面：我們保留了依賴(lài)于企微的運(yùn)維環(huán)境，保障絕大多數(shù)現(xiàn)成服務(wù)的穩(wěn)定運(yùn)行。

2）另一面：對(duì)于微信P6N中的服務(wù)，我們搭建了比較完善的Proxy層，例如Svrkit代理、WQueue代理等，兩套架構(gòu)可以方便進(jìn)行互通，最大限度的在原有基礎(chǔ)上接入微信的新能力。

目前，微信讀書(shū)已順利接入如WQueue、FKVOL、SimOL、TFCC等眾多微信的能力。

4、書(shū)籍?dāng)?shù)據(jù)中臺(tái)的演進(jìn)

4.1 技術(shù)背景

書(shū)籍是微信讀書(shū)的內(nèi)容根基，書(shū)籍?dāng)?shù)量的多少、書(shū)籍質(zhì)量的好壞，很大程度上決定了用戶(hù)是否選擇微信讀書(shū)作為閱讀App。

過(guò)去：我們依托閱文集團(tuán)提供電子書(shū)資源，免去了書(shū)籍上架前繁瑣的處理流程，包括排版、審校、元信息管理、更新管理等，后臺(tái)服務(wù)只需要對(duì)接閱文API即可方便獲取書(shū)籍?dāng)?shù)據(jù)，我們只需要關(guān)注書(shū)籍在平臺(tái)的存儲(chǔ)管理和分發(fā)流轉(zhuǎn)即可。

近幾年：電子書(shū)行業(yè)的大環(huán)境發(fā)生變化，一方面，用戶(hù)對(duì)書(shū)籍品類(lèi)多樣性、內(nèi)容質(zhì)量有更高的訴求，另一方面，平臺(tái)對(duì)成本、版權(quán)等行業(yè)因素也更為敏感。因此，我們也在積極探索自簽版權(quán)，甚至是自出品的模式，嘗試走更多不一樣的道路。從后臺(tái)角度而言，從過(guò)去單一依賴(lài)閱文集團(tuán)API的模式，慢慢轉(zhuǎn)為開(kāi)放更多的書(shū)籍管理接口，形成書(shū)籍?dāng)?shù)據(jù)中臺(tái)模式，為上層運(yùn)營(yíng)同學(xué)搭建內(nèi)容管理平臺(tái)，讓更多人可以方便參與到電子書(shū)的制作、排版、上下架、運(yùn)營(yíng)管理當(dāng)中。

以EPUB為例，從內(nèi)容產(chǎn)出到上架到微信讀書(shū)，大致經(jīng)歷以下階段：

1）排版審校：這個(gè)階段多為人工或者部分機(jī)器自動(dòng)化介入。

2）上架預(yù)處理：這個(gè)階段需要?jiǎng)?chuàng)建書(shū)籍信息，配置各種運(yùn)營(yíng)策略，當(dāng)這本書(shū)是重排版上架時(shí)，內(nèi)容發(fā)生改變，由于現(xiàn)網(wǎng)已經(jīng)存在用戶(hù)的劃線筆記、進(jìn)度等數(shù)據(jù)，需要有完善指標(biāo)評(píng)估是否適合覆蓋上架，當(dāng)上架時(shí)，需要對(duì)用戶(hù)數(shù)據(jù)進(jìn)行修復(fù)，避免發(fā)生錯(cuò)位情況，嚴(yán)重影響用戶(hù)體驗(yàn)。

3）EPUB解析：當(dāng)書(shū)籍上架后，由于EPUB是單一文件，不適合解析和管理分發(fā)，因此后臺(tái)會(huì)把源文件解析成自有格式，包括EPUB拆章、圖文分離、樣式分離、按章生成離線包等等。

4）生成BookInfo和BookData并落盤(pán)：EPUB文件經(jīng)過(guò)解析后，BookInfo和BookData會(huì)存儲(chǔ)到自建的StoreSvr服務(wù)上，StoreSvr針對(duì)書(shū)籍存儲(chǔ)、下載等場(chǎng)景進(jìn)行了很多優(yōu)化，具備高可用、低時(shí)延的特點(diǎn)，提供了書(shū)籍信息獲取、按章下載等核心接口。

4.2 建設(shè)數(shù)據(jù)中臺(tái)

回到最初的目標(biāo)，我們希望把更多的書(shū)籍管理能力開(kāi)放出來(lái)，對(duì)上層屏蔽電子書(shū)底層的后臺(tái)邏輯，讓運(yùn)營(yíng)同學(xué)可以更專(zhuān)注于書(shū)籍的管理。

因此，我們構(gòu)建了如下書(shū)籍?dāng)?shù)據(jù)中臺(tái)：

后臺(tái)服務(wù)拆分開(kāi)StoreAPI和StoreSvr：

1）StoreAPI：提供書(shū)籍管理的接口，由運(yùn)營(yíng)同學(xué)搭建的內(nèi)容平臺(tái)與StoreAPI交互，完成書(shū)籍的管理工作；

2）StoreSvr：一方面接受StoreAPI的請(qǐng)求，更新書(shū)籍?dāng)?shù)據(jù)，另一方面為現(xiàn)網(wǎng)用戶(hù)提供高可用的服務(wù)。

StoreAPI提供了如下接口能力：

• 1）書(shū)籍id分配、上下架；
• 2）書(shū)籍信息創(chuàng)建、修改；
• 3）書(shū)籍內(nèi)容修改、連載更新、訂閱推送；
• 4）運(yùn)營(yíng)策略管理。

此外：如上所述，劃線位置和閱讀進(jìn)度等核心UGC數(shù)據(jù)由于是按文件偏移記錄，當(dāng)書(shū)籍文件替換后，這些數(shù)據(jù)會(huì)發(fā)生錯(cuò)位，如果不能及時(shí)修復(fù)，將對(duì)用戶(hù)體驗(yàn)造成巨大影響。尤其在一些熱門(mén)書(shū)籍里，單本書(shū)里與位置相關(guān)的UGC數(shù)據(jù)往往能達(dá)到億級(jí)別，由于文件替換后位置的偏移具有隨機(jī)性，并不能采用簡(jiǎn)單的映射方式解決，在過(guò)去，我們開(kāi)發(fā)了專(zhuān)門(mén)的修復(fù)服務(wù)來(lái)完成這個(gè)事情，針對(duì)每一個(gè)UGC內(nèi)容，采用全文模糊查找的方式重新計(jì)算新的偏移，并更新的UGC正排、書(shū)籍倒排等多個(gè)存儲(chǔ)中。

但隨著用戶(hù)數(shù)據(jù)越來(lái)越多，書(shū)籍替換頻率越來(lái)越頻繁，修復(fù)不及時(shí)或者失敗的問(wèn)題逐漸暴露出來(lái)：

• 1）修復(fù)量大導(dǎo)致修復(fù)不及時(shí)。過(guò)去的修復(fù)服務(wù)雖然是多機(jī)部署，但處理單本書(shū)仍只是集中在一臺(tái)機(jī)器上，單機(jī)性能有限；
• 2）修復(fù)任務(wù)缺乏落盤(pán)管理，修復(fù)服務(wù)一旦重啟，任務(wù)丟失。

針對(duì)上面的問(wèn)題：我們重新設(shè)計(jì)了修復(fù)服務(wù)，目標(biāo)是最大限度縮短修復(fù)時(shí)間，并且讓整個(gè)過(guò)程是可靠的。

為此，我們先首手考慮業(yè)務(wù)流程，我們發(fā)現(xiàn)在書(shū)籍上架前，運(yùn)營(yíng)同學(xué)本來(lái)就需要依賴(lài)UGC的修復(fù)情況做前置判斷是否覆蓋上架，這個(gè)過(guò)程中雖然是對(duì)UGC抽樣評(píng)估，如果能對(duì)這個(gè)修復(fù)映射結(jié)果進(jìn)行緩存，在正式替換文件后，也能一定程度提升修復(fù)速度。

在核心修復(fù)流程中，我們進(jìn)行了較大的重構(gòu)，把單本書(shū)的修復(fù)任務(wù)拆解成多個(gè)子任務(wù)，存儲(chǔ)在Chubby上，多機(jī)器搶鎖共同消費(fèi)這些任務(wù)，由于任務(wù)有落盤(pán)，在服務(wù)上線重啟過(guò)程中，也能馬上恢復(fù)。修復(fù)過(guò)程涉及大量的KV寫(xiě)入，并發(fā)太高時(shí)容易命中單key的限頻或者版本沖突，我們?yōu)榇碎_(kāi)發(fā)了針對(duì)K-Str和K-Table的寫(xiě)入中間件，可以在內(nèi)存中聚合一批請(qǐng)求進(jìn)行批量合并寫(xiě)入，緩解KV層面的失敗。

目前，微信讀書(shū)已通過(guò)內(nèi)容平臺(tái)完成了多家版權(quán)方自簽，并在探索自出品等內(nèi)容創(chuàng)作新形式。

5、賬號(hào)系統(tǒng)的高可用性重構(gòu)

賬號(hào)是微信讀書(shū)后臺(tái)系統(tǒng)的基石，承擔(dān)了登錄、會(huì)話密鑰生成與派發(fā)、用戶(hù)資料管理等核心功能，所有的用戶(hù)請(qǐng)求都需經(jīng)過(guò)賬號(hào)系統(tǒng)進(jìn)行鑒權(quán)驗(yàn)證用戶(hù)身份，但凡有一點(diǎn)系統(tǒng)抖動(dòng)都會(huì)影響到整個(gè)App的正常使用，嚴(yán)重者還會(huì)導(dǎo)致賬號(hào)被踢出無(wú)法再次登錄。

賬號(hào)系統(tǒng)的架構(gòu)在微信讀書(shū)誕生之初便一直沿用，同一個(gè)號(hào)段的賬號(hào)服務(wù)AccountSvr和MySQL部署在同一臺(tái)機(jī)器上，備機(jī)采用主從同步的方式獲取數(shù)據(jù)，當(dāng)主機(jī)不可用時(shí)，備機(jī)承擔(dān)了所有讀請(qǐng)求。

在某些場(chǎng)景下，為了能使訪問(wèn)備機(jī)時(shí)也具備一定的寫(xiě)入能力，曾經(jīng)魔改過(guò)主備邏輯，但一切都顯得治標(biāo)不治本，且引入了更復(fù)雜的系統(tǒng)特性，整個(gè)架構(gòu)略顯混亂。在機(jī)器裁撤、數(shù)據(jù)擴(kuò)容過(guò)程中，曾造成過(guò)幾次嚴(yán)重故障，導(dǎo)致App不可用，嚴(yán)重影響用戶(hù)體驗(yàn)。究其原因，是因?yàn)楫?dāng)時(shí)基礎(chǔ)設(shè)施還不完善，缺少高性能高可靠的強(qiáng)一致存儲(chǔ)，MySQL也是手動(dòng)搭建的，運(yùn)維成本和風(fēng)險(xiǎn)都非常高。

為了徹底解決這個(gè)歷史包袱，我們?cè)?024下定決心對(duì)其進(jìn)行重構(gòu)。重構(gòu)就意味著要拋棄現(xiàn)有MySQL這套臃腫的存儲(chǔ)方案，把數(shù)據(jù)遷移到新的存儲(chǔ)組件上。

這里涉及到的挑戰(zhàn)點(diǎn)如下：

• 1）賬號(hào)鑒權(quán)服務(wù)訪問(wèn)量巨大，遷移過(guò)程須盡量不增加系統(tǒng)負(fù)擔(dān)，且必須是在不停機(jī)的情況下進(jìn)行；
• 2）遷移過(guò)程中一旦有數(shù)據(jù)丟失或者錯(cuò)誤，會(huì)導(dǎo)致用戶(hù)資料受損，用戶(hù)登錄態(tài)丟失，App無(wú)法使用；
• 3）賬號(hào)系統(tǒng)還涉及用戶(hù)id分配和回收邏輯，在切換存儲(chǔ)時(shí)如何保證數(shù)據(jù)的一致性，不重復(fù)分配號(hào)碼。

背水一戰(zhàn)，沒(méi)有退路可言。在經(jīng)歷了多次論證后，我們決定采用Paxosmemkv作為新的存儲(chǔ)組件，全內(nèi)存、多副本、強(qiáng)一致的特性，很適合作為賬號(hào)系統(tǒng)的底層存儲(chǔ)。

同時(shí)，我們?yōu)檎麄€(gè)遷移過(guò)程制定了周密的方案，把每一步進(jìn)行了分解，且要求每個(gè)環(huán)節(jié)可灰度可回退，同時(shí)要做好數(shù)據(jù)的一致性檢查。

在完成數(shù)據(jù)遷移后，我們還需要對(duì)AccountSvr進(jìn)行重構(gòu)，拋棄按號(hào)段的賬號(hào)分配、路由、緩存邏輯，以全新的視角設(shè)計(jì)更簡(jiǎn)潔的架構(gòu)。

6、內(nèi)容召回系統(tǒng)的架構(gòu)設(shè)計(jì)

以往微信讀書(shū)的搜索僅限于基于書(shū)名、作者等維度的文本召回，通過(guò)自建的全內(nèi)存索引服務(wù)實(shí)現(xiàn)書(shū)籍的檢索。全文檢索則基于ES搭建，采用規(guī)則分段的方式建立索引，能滿足讀書(shū)大部分場(chǎng)景的需要。

在大語(yǔ)言模型迅速發(fā)展的近兩年，微信讀書(shū)作為一個(gè)龐大的內(nèi)容知識(shí)庫(kù)，具有大量的書(shū)籍原文資源。同時(shí)，用戶(hù)在微信讀書(shū)也留下了大量的文字內(nèi)容，如書(shū)評(píng)、想法等，這些內(nèi)容構(gòu)成了AI問(wèn)書(shū)的內(nèi)容基石，也是AI問(wèn)書(shū)區(qū)別于其它問(wèn)答工具的核心優(yōu)勢(shì)。

基于微信讀書(shū)構(gòu)建RAG召回系統(tǒng)，核心挑戰(zhàn)如下：

1）基于書(shū)籍原文構(gòu)建全文檢索，為了達(dá)到最好的效果，往往需要支持按語(yǔ)義進(jìn)行段落切分，在此基礎(chǔ)上構(gòu)建embedding進(jìn)行語(yǔ)義召回。微信讀書(shū)擁有百萬(wàn)級(jí)書(shū)籍原文數(shù)據(jù)，此外，對(duì)于用戶(hù)導(dǎo)入書(shū)，更是達(dá)到億級(jí)別規(guī)?！，F(xiàn)有架構(gòu)無(wú)論從成本還是耗時(shí)上都無(wú)法解決。

2）為了支持更多維度的召回，需要對(duì)UGC內(nèi)容進(jìn)行召回，部分UGC內(nèi)容屬于私密信息，并不向全網(wǎng)公開(kāi)，只需要滿足用戶(hù)個(gè)人檢索即可。此時(shí)如果用常規(guī)的檢索系統(tǒng)構(gòu)建常駐索引，訪問(wèn)率太低，成本難以收斂。

為此，我們針對(duì)微信讀書(shū)不同的RAG使用場(chǎng)景，設(shè)計(jì)了如下召回架構(gòu)：

我們把數(shù)據(jù)劃分成兩類(lèi)：全局公開(kāi)可搜以及用戶(hù)個(gè)人可搜。

1）對(duì)于全局公開(kāi)可搜索的數(shù)據(jù)：如庫(kù)內(nèi)電子書(shū)的全文、書(shū)籍大綱、書(shū)評(píng)、人工知識(shí)庫(kù)等，我們構(gòu)建了一套入庫(kù)流程，能對(duì)源信息進(jìn)行語(yǔ)義分段、生成正排倒排，語(yǔ)義分段基于開(kāi)源的chunk模型進(jìn)行微調(diào)，正排基于fkv，倒排則基于ES構(gòu)建，ES提供了DiskANN方案，通過(guò)設(shè)置合理的緩存和分片，能在存儲(chǔ)成本和召回效率之間取得不錯(cuò)的平衡。對(duì)于 App 內(nèi)主搜等低時(shí)延場(chǎng)景，為了滿足多種定制化檢索需求，我們自建了基于內(nèi)存索引的Searchsvr服務(wù)，支持索引落盤(pán)，可以在毫秒級(jí)返回電子書(shū)搜索結(jié)果。

2）對(duì)于用戶(hù)個(gè)人數(shù)據(jù)：如導(dǎo)入書(shū)全文、個(gè)人想法等，特點(diǎn)是數(shù)據(jù)量大但使用頻率不高，不需要針對(duì)全網(wǎng)用戶(hù)進(jìn)行檢索，如果采用上述方案，會(huì)帶來(lái)成本災(zāi)難，性?xún)r(jià)比極低。為此，我們按用戶(hù)及物料的維度，基于USearch、Xapian等方案構(gòu)建了向量及文本索引，這些組件的優(yōu)勢(shì)在于可以把單個(gè)索引存儲(chǔ)成文件的形式，便于落盤(pán)，配合一些量化的方法，可以把大大壓縮索引大小。在構(gòu)建索引階段，按用戶(hù)+類(lèi)型構(gòu)建出不同的索引，并存儲(chǔ)在低成本的COS上，當(dāng)用戶(hù)需要檢索召回時(shí)，采用讀時(shí)加載的方式實(shí)時(shí)進(jìn)行召回，結(jié)合CFS進(jìn)行預(yù)熱可以大大提升檢索速度。當(dāng)檢索完成后，定時(shí)淘汰策略會(huì)把長(zhǎng)期不用的索引從CFS中清理，降低存儲(chǔ)成本。

7、寫(xiě)在最后

雖然微信讀書(shū)已經(jīng)發(fā)展了十個(gè)年頭，但我們的腳步從未停止。

在日常業(yè)務(wù)開(kāi)發(fā)之余，我們也從未停止思考如何讓系統(tǒng)能走得更遠(yuǎn)、更穩(wěn)健，抓住每一個(gè)可能的優(yōu)化點(diǎn)，隨時(shí)做好準(zhǔn)備，迎接下一個(gè)精彩的十年。

8、相關(guān)資料

[1] 騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面

[2] 快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理

[3] 子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐

[4] 知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路

[5] 新手入門(mén)：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐

[6] 阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史

[7] 阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路

[8] 達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力

[9] 優(yōu)秀后端架構(gòu)師必會(huì)知識(shí)：史上最全MySQL大表優(yōu)化方案總結(jié)

[10] 小米技術(shù)分享：解密小米搶購(gòu)系統(tǒng)千萬(wàn)高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐

[11] 一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類(lèi)、原理、算法、常見(jiàn)方案等

[12] 通俗易懂：如何設(shè)計(jì)能支撐百萬(wàn)并發(fā)的數(shù)據(jù)庫(kù)架構(gòu)？

[13] 多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了

[14] 從新手到架構(gòu)師，一篇就夠：從100到1000萬(wàn)高并發(fā)的架構(gòu)演進(jìn)之路

[15] 美團(tuán)技術(shù)分享：深度解密美團(tuán)的分布式ID生成算法

[16] 12306搶票帶來(lái)的啟示：看我如何用Go實(shí)現(xiàn)百萬(wàn)QPS的秒殺系統(tǒng)(含源碼)

9、微信團(tuán)隊(duì)的其它精華文章

微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐

微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路

微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級(jí)實(shí)踐分享

微信異步化改造實(shí)踐：8億月活、單機(jī)千萬(wàn)連接背后的后臺(tái)解決方案

一份微信后臺(tái)技術(shù)架構(gòu)的總結(jié)性筆記

社交軟件紅包技術(shù)解密(十三)：微信團(tuán)隊(duì)首次揭秘微信紅包算法，為何你搶到的是0.01元

微信團(tuán)隊(duì)分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實(shí)踐總結(jié)

IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)

微信團(tuán)隊(duì)分享：微信支付代碼重構(gòu)帶來(lái)的移動(dòng)端軟件架構(gòu)上的思考

IM開(kāi)發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總

微信團(tuán)隊(duì)分享：微信直播聊天室單房間1500萬(wàn)在線的消息架構(gòu)演進(jìn)之路

企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等

IM全文檢索技術(shù)專(zhuān)題(四)：微信iOS端的最新全文檢索技術(shù)優(yōu)化實(shí)踐

微信團(tuán)隊(duì)分享：微信后臺(tái)在海量并發(fā)請(qǐng)求下是如何做到不崩潰的

微信Windows端IM消息數(shù)據(jù)庫(kù)的優(yōu)化實(shí)踐：查詢(xún)慢、體積大、文件損壞等

微信技術(shù)分享：揭秘微信后臺(tái)安全特征數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)設(shè)計(jì)

企業(yè)微信針對(duì)百萬(wàn)級(jí)組織架構(gòu)的客戶(hù)端性能優(yōu)化實(shí)踐

揭秘企業(yè)微信是如何支持超大規(guī)模IM組織架構(gòu)的——技術(shù)解讀四維關(guān)系鏈

微信團(tuán)隊(duì)分享：詳解iOS版微信視頻號(hào)直播中因幀率異常導(dǎo)致的功耗問(wèn)題

微信團(tuán)隊(duì)分享：微信后端海量數(shù)據(jù)查詢(xún)從1000ms降到100ms的技術(shù)實(shí)踐

大型IM工程重構(gòu)實(shí)踐：企業(yè)微信Android端的重構(gòu)之路

IM技術(shù)干貨：假如你來(lái)設(shè)計(jì)微信的群聊，你該怎么設(shè)計(jì)？

微信團(tuán)隊(duì)分享：來(lái)看看微信十年前的IM消息收發(fā)架構(gòu)，你做到了嗎

微信后團(tuán)隊(duì)分享：微信后臺(tái)基于Ray的分布式AI計(jì)算技術(shù)實(shí)踐

一年擼完百萬(wàn)行代碼，企業(yè)微信的全新鴻蒙NEXT客戶(hù)端架構(gòu)演進(jìn)之路

（本文已同步發(fā)布于：http://www.52im.net/thread-4839-1-1.html）