微信讀書十周年，后臺架構(gòu)的技術(shù)演進和實踐總結(jié)

Posted on 2025-06-20 15:26 Jack Jiang 閱讀(42) 評論(0) 編輯收藏

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

1、前言

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

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

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

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

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

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

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

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

2）邏輯層：采用WRMesh框架構(gòu)建了多個微服務(wù)，這些微服務(wù)按業(yè)務(wù)場景進行劃分，實現(xiàn)了不同模塊間的解耦。框架也提供了如RPC、路由發(fā)現(xiàn)、過載保護、限流頻控、監(jiān)控上報等能力。

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

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

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

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

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

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

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

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

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

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

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

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

如果要一刀切把所有后臺服務(wù)遷移至P6N，將會面臨幾個問題：

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

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

3）存儲模塊的遷移成本和風(fēng)險巨大，如果不遷移存儲模塊只遷移了邏輯模塊，那勢必又會存在2中的問題，這個過程很難收尾。

考慮到人力成本及投入性價比，我們最終采用了折衷的方案：

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

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

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

4、書籍?dāng)?shù)據(jù)中臺的演進

4.1 技術(shù)背景

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

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

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

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

1）排版審校：這個階段多為人工或者部分機器自動化介入。

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

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

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

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

回到最初的目標(biāo)，我們希望把更多的書籍管理能力開放出來，對上層屏蔽電子書底層的后臺邏輯，讓運營同學(xué)可以更專注于書籍的管理。

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

后臺服務(wù)拆分開StoreAPI和StoreSvr：

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

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

StoreAPI提供了如下接口能力：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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