本文由字節跳動張華挺分享，原題“你不知道的前端音視頻知識”，下文有修訂和重新排版。

1、前言

本文回顧了Web端音視頻的發展歷程，同時還介紹了視頻的編碼、幀率、比特率等概念，提到了Canvas作為視頻播放的替代方案，以及FFmpeg在音視頻處理中的重要作用等知識。

2、遠古時期的HTML

Web端音視頻的發展史得從刀耕火種的年代——早期 HTML說起。

在早期的 HTML，由于帶寬、技術等各種因素限制，網頁主要以簡單的靜態內容為主，只支持一些文字圖片內容和簡單的排版，不支持在線觀看音視頻。

圖為 1994 年的 Yahoo!：

3、 Flash的興起與淘汰

20 世紀初，隨著互聯網的發展，各種 Web 應用和門戶網站不斷出現，人們渴望在網頁上看到更加豐富多彩的內容，比如視頻、動畫等等，于是 Flash 進入了人們的視野。

彼時的 Flash 沒有像現在大家印象中的那么臃腫，剛誕生的 Flash 小巧、高效、跨平臺，同時憑借幾十 K 的體積做出放大也不會失真的各種矢量彩色動畫，在還是撥號上網，帶寬條件受限，加載一個在線視頻需要好幾分鐘的年代脫穎而出，甚至可以做出各種令人沉迷的 Flash 小游戲。

Flash 塑造了很多經典的小游戲角色，火柴人就是其中之一：

Flash 的興起，得益于當時 HTML 對于媒體文件支持的匱乏。Flash 以插件的形式，干著平臺才需要負擔的繁重工作，并得益于 Adobe 的大力推廣，Flash 先后增加了對 Javascrip、HTML、XML 的支持，并增強了影音方面的功能。同時由于 Flash 跨平臺的特性，非常容易被移植，市面上稍微高端點的設備，也得乖乖地給 Adobe 交授權費。

然而 2007 年推出的 iPhone 并不買賬，他們以增加續航、安全為由拋棄了 Flash，很多人一開始對此嗤之以鼻，但事實證明蘋果對此確實有遠見，大量低質量的 Flash 使當時續航本就有限的移動設備更加不堪重負。2012 年，Android 也宣布不再支持 Flash，Flash 在移動市場不再有立足之地。

在桌面市場上，Flash 的日子也并不好過。Chrome 從的 Chrome 42 開始，就已經強制把 Flash 裝入沙箱，以 PPAPI 的形式運行；而從 Chromium 版本號 88 開始，已經徹底不再支持 Flash 技術了。微軟的 Edge 瀏覽器也同步不支持 Flash。Chrome 的前輩 Firefox 更加激進，從 2016 年就已經默認禁止 Flash 運行了。

至于 Flash 為什么走向了淘汰，除了它的效率變低，不安全因素過多，穩定性不足外，還有一個重要原因：Web 音視頻解決方案有了更好的替代品—— HTML5。

4、HTML5的到來

其實，對于 HTML5 是否可以真正替代 Flash，尤大在 2011 年已經給出了預言：

事實正如預言所預料，HTML5 在 2008 年發布后，經過不斷改進完善，基本上能包辦 Flash 所有能干的事情了。HTML5 引入了許多新特性和新功能，其中就包含了 video 和 audio 標簽，也就是對音視頻的支持。使用了支持 HTML5 標準的網絡瀏覽器訪問 HTML5 站點，用戶無需在電腦上安裝 Flash 插件就可以在線觀看視頻，擺脫了對 Flash 的依賴。

2021 年 1 月 20 日，chrome 88 正式發布，徹底的禁止使用 Flash。自此，Flash 算是徹底退出了歷史舞臺。

5、到底什么是視頻

視頻，其實就是一系列連續播放的圖片，如果一秒鐘播放 24 張圖片，那么人眼看到的就不再是一張張獨立的圖片，而是動起來的畫面。

其中一張圖片稱為一幀，1s 播放的圖片數稱為幀率。由于人類眼睛的特殊生理結構，如果所看畫面之幀率高于每秒約 10-12 幀的時候，就會認為是連貫的；當看到幀率為 24 fps 以上時，大腦會認為這是流暢播放的視頻。所以一般有聲電影的拍攝及播放幀率大約為每秒 24 幀，歐美、日本那邊由于電視制式不同，大約為 30 幀。

關于視頻及視頻編碼相關的入門文章可以繼續詳讀以下資料：

• 《零基礎，史上最通俗視頻編碼技術入門》
• 《一文讀懂視頻的顏色模型轉換和色域轉換》
• 《愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現在和將來》

6、電影的幀率與游戲的幀率

為什么 24 幀的電影比 30 幀的游戲要流暢許多？這其中的原因就在于，電影和游戲的圖像生成原理不同。

電影的 24 fps，是每 1/24 秒拍攝一副畫面，如果你玩過相機的手動設置，你應該知道如果以 1/24 秒的快門速度拍攝一個運動的物體會“糊”掉，而正是這樣“糊”掉的畫面連起來才讓我們的眼睛看上去很“流暢”。

而游戲畫面不是按 1/24 秒快門拍出來的，而是每一幅畫面都是獨立渲染出來的，之所以跑成 24fps 是因為顯卡處理能力不夠而“丟棄”了其中的一些畫面，這樣一來每兩幅畫面之間就不連續了，自然看上去會“卡”。

舉個例子：一個圓從左上角移動到右下角，如果是電影，第一幀與第二幀可能是類似下圖這樣的。

如果是游戲畫面，第一幀與第二幀會類似下面這兩張圖：

此外，幀與幀之間間隔恒定：人眼對于動態視頻的捕捉是非常敏感的，電影幀率是固定不變，肉眼很難察覺出異常。

而游戲的幀率卻是很容易變化的——如果手動鎖定幀數，顯卡會默認渲染最高幀率。

玩家觸發的很多劇情往往伴隨劇烈的畫面變動，這時顯卡的幀率就會出現下降，前后不一致的幀率很容易被肉眼捕捉，這時我們就會覺得，游戲變“卡”了。

7、視頻的編碼

7.1 概述

視頻是由圖片構成的，圖片是由像素構成的，假設尺寸為 1980*1080。每個像素由 RGB 構成，每個 8 位，共 24 位。

假設幀率是 24，那么每秒鐘的視頻的尺寸如下：

一分鐘視頻的尺寸就是 9237888000 Bytes 已經是 8.8 個 G 了。可以看到，如果是不對視頻做任何處理，是非常不方便對于視頻做傳輸與存儲的，所以需要對視頻進行壓縮，也就是編碼。

7.2 視頻編碼

視頻圖像數據有很強的相關性，也就是說有大量的冗余信息。其中冗余信息可分為空域冗余信息和時域冗余信息。壓縮技術就是將數據中的冗余信息去掉（去除數據之間的相關性），壓縮技術包含幀內圖像數據壓縮技術、幀間圖像數據壓縮技術和熵編碼壓縮技術。

經過編碼之后，視頻由一幀幀的圖片，變成了一串串讓人看不懂的二進制代碼，因為編碼的方式(算法)的不同，所以就有了編碼格式的區分。常見的編碼格式有 H.264，MPEG-4，VP8 等。

我們前端開發只需要記住一點，主流瀏覽器支持的視頻編碼格式是 H.264。

7.3 音頻編碼

CD 音質的音頻，存放一分鐘數據需要的大小為 10M，太大了，也需要壓縮（編碼）。

常見的編碼方式有：WAV、MP3 和 AAC 格式。

音頻的編碼方式不像視頻那樣那么多，而且音頻在各個瀏覽器基本上都可以播放。具體的每種編碼格式包含的音頻是怎么構成的，這里就不講了。

關于音頻及音頻編碼相關的入門文章可以繼續詳讀以下資料：

• 《如何開始音頻編解碼技術的學習》
• 《音頻基礎及編碼原理入門》
• 《詳解音頻編解碼的原理、演進和應用選型》

7.4 封裝格式

我們把視頻數據、音頻數據打包到一起，然后再添加一些基本信息，例如分辨率、時長、標題等，構成一個文件，這個文件稱為封裝格式。常見的封裝格式有 MP4、AVI、RMVB 等。

可以看出：視頻的封裝格式和視頻的編碼格式往往是無關的。一個 mp4 文件里面的視頻流編碼可以是 h264也可以是 mpeg-4。所以就會出現，同樣都是 mp4 文件，有的瀏覽器可以放，有的瀏覽器就放不了的問題，因為能不能放是由視頻碼流的編碼格式決定的。

8、視頻的碼率

碼率，也叫比特率，幀率是 1s 播放多少幀，類比一下，比特率就是 1s 的視頻有多少 bit。這個參數直接決定了視頻的大小與清晰程度。

一般網上流傳的電影 MKV（BDrip-1080P）的碼率是 10Mb/s 左右，藍光原盤是 20Mb/s 左右，這兩者都是 H.264 編碼的。另外一些 MV、PV、演示片什么的除了 H.264 編碼，可能還有 MPEG-2 編碼，碼率大小不等，像 youtube 那些在線的 1080P 的視頻，碼率可能只有 5Mb/s，而一些 MV 的碼率可以高到離譜，可以達到 110Mb/s 的，3 分多鐘的 MV 差不多有 3GB 大小。

而一般的視頻剪輯、后期軟件，在輸出序列的時候，都會有碼率這個選項。

9、視頻播放器的原理

播放視頻的基本流程是：解協議 → 解封裝 → 解碼 → 視音頻同步。如果播放本地文件則不需要解協議。

解協議的作用，就是將流媒體協議的數據，解析為標準的相應的封裝格式數據。視音頻在網絡上傳播的時候，常常采用各種流媒體協議，例如 HTTP、RTMP或是 MMS 等等。這些協議在傳輸視音頻數據的同時，也會傳輸一些信令數據。這些信令數據包括對播放的控制（播放、暫停、停止），或者對網絡狀態的描述等。解協議的過程中會去除掉信令數據而只保留視音頻數據。

解封裝的作用，就是將輸入的封裝格式的數據，分離成為音頻流壓縮編碼數據和視頻流壓縮編碼數據。封裝格式種類很多，例如 MP4、MKV、RMVB、TS、FLV、AVI 等等，它的作用就是將已經壓縮編碼的視頻數據和音頻數據按照一定的格式放到一起。例如，FLV 格式的數據，經過解封裝操作后，輸出 H.264 編碼的視頻碼流和 AAC 編碼的音頻碼流。

解碼的作用，就是將視頻/音頻壓縮編碼數據，解碼成為非壓縮的視頻/音頻原始數據。音頻的壓縮編碼標準包含 AAC、MP3、AC-3 等等，視頻的壓縮編碼標準則包含 H.264、MPEG2、VC-1 等等。解碼是整個系統中最重要也是最復雜的一個環節。通過解碼，壓縮編碼的視頻數據輸出成為非壓縮的顏色數據，例如 YUV420P、RGB 等等；壓縮編碼的音頻數據輸出成為非壓縮的音頻抽樣數據，例如 PCM 數據。

視音頻同步的作用，就是根據解封裝模塊處理過程中獲取到的參數信息，同步解碼出來的視頻和音頻數據，并將視頻音頻數據送至系統的顯卡和聲卡播放出來。

10、HTML5的canvas播放視頻

如果我們碰到一些特殊機型或者特殊情況 HTML5 的 video 解決方案不是很好處理，也可以采用 Canvas 去播放這個視頻。

使用 Canvas 播放視頻主要是利用 ctx.drawImage(video, x, y, width, height) 來對視頻當前幀的圖像進行繪制，其中 video 參數就是頁面中的 video 對象。所以如果我們按照特定的頻率不斷獲取 video 當前畫面，并渲染到 Canvas 畫布上，就可以實現使用 Canvas 播放視頻的功能。

<video id="video" controls="controls" style="display: none;">

    <source src="https://xxx.com/vid_159411468092581" />

</video>

<canvas  id="myCanvas" width="460" height="270" style="border: 1px solid blue;" ></canvas>

<div>

    <button id="playBtn">播放</button>

    <button id="pauseBtn">暫停</button>

</div>

 

const video = document.querySelector("#video");

const canvas = document.querySelector("#myCanvas");

const playBtn = document.querySelector("#playBtn");

const pauseBtn = document.querySelector("#pauseBtn");

const context = canvas.getContext("2d");

let timerId = null;

function draw() {

    if (video.paused || video.ended) return;

    context.clearRect(0, 0, canvas.width, canvas.height);

    context.drawImage(video, 0, 0, canvas.width, canvas.height);

    timerId = setTimeout(draw, 0);

}

playBtn.addEventListener("click", () => {

    if (!video.paused) return;

    video.play();

    draw();

});

pauseBtn.addEventListener("click", () => {

    if (video.paused) return;

    video.pause();

    clearTimeout(timerId);

});

事實上，市面上已經有不少 Canvas 播放視頻的解決方案，比較出名的是這個 JSMpeg。它和 PIXI 一樣，可以選擇 WebGL 渲染視頻也可以直接用 Canvas 渲染視頻。

JSMpeg 是沒有 npm 包的，但是社區上有開發者基于 JSMpeg 封裝了一個 npm 包：https://github.com/cycjimmy/jsmpeg-player。

在官網上是這么介紹的：

JSMpeg is a Video Player written in JavaScript. It consists of an MPEG-TS Demuxer, WebAssembly MPEG1 Video & MP2 Audio Decoders, WebGL & Canvas2D Renderers and WebAudio Sound Output. JSMpeg can load static files via Ajax and allows low latency streaming (~50ms) via WebSocktes.

由于它所支持的編碼格式不是常規的 H.264，而是比較老的 MPEG1，并且解封裝器為 MPEG-TS。所以一般我們使用它去渲染視頻的格式為 TS。TS 是日本高清攝像機拍攝下進行的封裝格式，全稱為 MPEG2-TS。它的特點就是要求從視頻流的任一片段開始都是可以獨立解碼的。

TS 文件通常作為多個文件保存在 DVD 上，雖然它可以在高清攝像機、藍光 DVD 中無需借助其他軟件就能直接打開，但是 TS 視頻文件與大多數的媒體播放器、便攜式播放器或視頻編輯工具都不兼容，所以這個時候，FFmpeg 就可以出場了。

11、視頻操作神器——FFmpeg

FFmpeg是一個開源的軟件，我們直接用 homebrew 就可以安裝：

1brew install ffmpeg

如果我們想轉換為 jsmpeg 所需的 ts 格式視頻，可以執行：

$ ffmpeg -i input.mp4 -f mpegts \

         -codec:v mpeg1video -s 640x360 -b:v 1500k -r 25 -bf 0 \

         -codec:a mp2 -ar 44100 -ac 1 -b:a 64k \

         output.ts

• 1）i：指定輸入文件，這里指定為 input.mp4；
• 2）f 指明輸出文件的封裝格式，這里為 jsmpeg 所需的 mpegts；
• 3）codec:v 指明輸出文件的視頻編碼，這里指明為 jsmpeg 所需的 mpeg1video；
• 4）s 設置視頻分辨率，參數格式為w*h或w×h；
• 5）b:v 設置視頻碼率，一般如果想得到高清的效果，至少需要 4000k 以上，如果對視頻體積有要求，可以視情況小一點；
• 6）r 設置幀率（fps），一般都為 25；
• 7）bf bframe 數目控制，一般為 0。

B 幀法（B frame）是雙向預測的幀間壓縮算法。當把一幀壓縮成 B 幀時，它根據相鄰的前一幀、本幀以及后一幀數據的不同點來壓縮本幀，也即僅記錄本幀與前后幀的差值。

• 1）codec:a 指明輸出文件的音頻編碼；
• 2）ar 設置音頻編碼采樣率，單位kHz，一般網上的音頻，大多為 44100；

音頻采樣率是指錄音設備在單位時間內對模擬信號采樣的多少，采樣頻率越高，機械波的波形就越真實越自然；

• 3）ac 設置音頻編碼聲道數；
• 4）b:a 設置音頻碼率；

音頻碼率，指一個音頻流中每秒鐘能通過的數據量，碼率越大的話，音質越好。

• 最后一個參數即為輸出文件位置與名稱和后綴格式。

FFmpeg 是一個非常強大的音視頻轉換工具，不僅可以視頻轉換，還可以視頻尺寸裁剪、視頻時長裁剪、視頻拼接等等功能，目前很多在線視頻剪輯工具基本是基于 FFmpeg 開發的。

12、音視頻的一些資源推薦

國內學習音視頻相關的開發，繞不過的一個大神是雷霄驊，大佬已經去世了，但是留下的文章永垂不朽。本文也是參考了雷霄驊的部分博客，如果感興趣，可以從這篇文章看起：《視音頻編解碼技術零基礎學習方法》。

對于直播 webrtc 感興趣的，也可以看一下 Real time communication with WebRTC，國內慕課網上李超老師也有不錯的教程。

對 ffmpeg 感興趣的，可以看一下這里：https://github.com/leandromoreira/ffmpeg-libav-tutorial。

13、參考資料

[1] 即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型

[2] 即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門

[3] 即時通訊音視頻開發（二十）：一文讀懂視頻的顏色模型轉換和色域轉換

[4] 實時語音聊天中的音頻處理與編碼壓縮技術簡述

[5] 網易視頻云技術分享：音頻處理與壓縮技術快速入門

[6] 福利貼：最全實時音視頻開發要用到的開源工程匯總

[7] 理解實時音視頻聊天中的延時問題一篇就夠

[8] 寫給小白的實時音視頻技術入門提綱

[9] 愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現在和將來

[10] 零基礎入門：實時音視頻技術基礎知識全面盤點

[11] 實時音視頻面視必備：快速掌握11個視頻技術相關的基礎概念

[12] 實時音視頻開發理論必備：如何省流量？視頻高度壓縮背后的預測技術

[13] 視頻直播技術干貨(十三)：B站實時視頻直播技術實踐和音視頻知識入門

[14] 零基礎入門：基于開源WebRTC，從0到1實現實時音視頻聊天功能

[15] 實時音視頻入門學習：開源工程WebRTC的技術原理和使用淺析

[16] 零基礎快速入門WebRTC：基本概念、關鍵技術、與WebSocket的區別等

（本文已同步發布于：http://www.52im.net/thread-4840-1-1.html）

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

1、前言

今年是微信讀書上線10周年，后臺技術架構也伴隨著微信讀書的成長經歷了多次迭代與升級。每一次的組件升級與架構突破，在一個運行了10年的系統上落地都不是一件容易的事情，需要破釜沉舟的決心與膽大心細的業務聯動。

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

2、整體架構設計

微信讀書是獨立于微信的App，且由于歷史原因，開發及運維環境均存在一定的差異與隔離。因此，微信讀書的后臺服務實現了從接入層到存儲層的一整套完整架構。

架構上分解為典型的接入層、邏輯層和存儲層：

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

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

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

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

3、異構服務間調用：RPC框架

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

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

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

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

Sidecar專注于處理網絡層的邏輯，和Business業務層分開為兩個進程，由WRMesh腳手架生成代碼，上層業務無需感知。

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

因此：Business進程可以由任意語言任意框架開發，只要遵循Sidecar的通信協議，只需要薄薄的一層網絡協議轉換即可接入到Hikit的服務治理框架中。

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

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

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

1）框架代碼需要重新適配，開發環境和現網環境都有巨大的改造成本。

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

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

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

1）一方面：我們保留了依賴于企微的運維環境，保障絕大多數現成服務的穩定運行。

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

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

4、書籍數據中臺的演進

4.1 技術背景

書籍是微信讀書的內容根基，書籍數量的多少、書籍質量的好壞，很大程度上決定了用戶是否選擇微信讀書作為閱讀App。

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

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

以EPUB為例，從內容產出到上架到微信讀書，大致經歷以下階段：

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

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

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

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

4.2 建設數據中臺

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

因此，我們構建了如下書籍數據中臺：

后臺服務拆分開StoreAPI和StoreSvr：

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

2）StoreSvr：一方面接受StoreAPI的請求，更新書籍數據，另一方面為現網用戶提供高可用的服務。

StoreAPI提供了如下接口能力：

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

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

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

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

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

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

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

目前，微信讀書已通過內容平臺完成了多家版權方自簽，并在探索自出品等內容創作新形式。

5、賬號系統的高可用性重構

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

賬號系統的架構在微信讀書誕生之初便一直沿用，同一個號段的賬號服務AccountSvr和MySQL部署在同一臺機器上，備機采用主從同步的方式獲取數據，當主機不可用時，備機承擔了所有讀請求。

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

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

這里涉及到的挑戰點如下：

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

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

同時，我們為整個遷移過程制定了周密的方案，把每一步進行了分解，且要求每個環節可灰度可回退，同時要做好數據的一致性檢查。

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

6、內容召回系統的架構設計

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

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

基于微信讀書構建RAG召回系統，核心挑戰如下：

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

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

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

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

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

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

7、寫在最后

雖然微信讀書已經發展了十個年頭，但我們的腳步從未停止。

在日常業務開發之余，我們也從未停止思考如何讓系統能走得更遠、更穩健，抓住每一個可能的優化點，隨時做好準備，迎接下一個精彩的十年。

8、相關資料

[1] 騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面

[2] 快速理解高性能HTTP服務端的負載均衡技術原理

[3] 子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐

[4] 知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路

[5] 新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐

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

[7] 阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路

[8] 達達O2O后臺架構演進實踐：從0到4000高并發請求背后的努力

[9] 優秀后端架構師必會知識：史上最全MySQL大表優化方案總結

[10] 小米技術分享：解密小米搶購系統千萬高并發架構的演進和實踐

[11] 一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等

[12] 通俗易懂：如何設計能支撐百萬并發的數據庫架構？

[13] 多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了

[14] 從新手到架構師，一篇就夠：從100到1000萬高并發的架構演進之路

[15] 美團技術分享：深度解密美團的分布式ID生成算法

[16] 12306搶票帶來的啟示：看我如何用Go實現百萬QPS的秒殺系統(含源碼)

9、微信團隊的其它精華文章

微信后臺基于時間序的海量數據冷熱分級架構設計實踐

微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路

微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享

微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案

一份微信后臺技術架構的總結性筆記

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

微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結

IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現

微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考

IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總

微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路

企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等

IM全文檢索技術專題(四)：微信iOS端的最新全文檢索技術優化實踐

微信團隊分享：微信后臺在海量并發請求下是如何做到不崩潰的

微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等

微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計

企業微信針對百萬級組織架構的客戶端性能優化實踐

揭秘企業微信是如何支持超大規模IM組織架構的——技術解讀四維關系鏈

微信團隊分享：詳解iOS版微信視頻號直播中因幀率異常導致的功耗問題

微信團隊分享：微信后端海量數據查詢從1000ms降到100ms的技術實踐

大型IM工程重構實踐：企業微信Android端的重構之路

IM技術干貨：假如你來設計微信的群聊，你該怎么設計？

微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎

微信后團隊分享：微信后臺基于Ray的分布式AI計算技術實踐

一年擼完百萬行代碼，企業微信的全新鴻蒙NEXT客戶端架構演進之路

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

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

1、前言

今年是微信讀書上線10周年，后臺技術架構也伴隨著微信讀書的成長經歷了多次迭代與升級。每一次的組件升級與架構突破，在一個運行了10年的系統上落地都不是一件容易的事情，需要破釜沉舟的決心與膽大心細的業務聯動。

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

2、整體架構設計

微信讀書是獨立于微信的App，且由于歷史原因，開發及運維環境均存在一定的差異與隔離。因此，微信讀書的后臺服務實現了從接入層到存儲層的一整套完整架構。

架構上分解為典型的接入層、邏輯層和存儲層：

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

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

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

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

3、異構服務間調用：RPC框架

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

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

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

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

Sidecar專注于處理網絡層的邏輯，和Business業務層分開為兩個進程，由WRMesh腳手架生成代碼，上層業務無需感知。

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

因此：Business進程可以由任意語言任意框架開發，只要遵循Sidecar的通信協議，只需要薄薄的一層網絡協議轉換即可接入到Hikit的服務治理框架中。

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

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

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

1）框架代碼需要重新適配，開發環境和現網環境都有巨大的改造成本。

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

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

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

1）一方面：我們保留了依賴于企微的運維環境，保障絕大多數現成服務的穩定運行。

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

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

4、書籍數據中臺的演進

4.1 技術背景

書籍是微信讀書的內容根基，書籍數量的多少、書籍質量的好壞，很大程度上決定了用戶是否選擇微信讀書作為閱讀App。

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

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

以EPUB為例，從內容產出到上架到微信讀書，大致經歷以下階段：

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

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

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

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

4.2 建設數據中臺

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

因此，我們構建了如下書籍數據中臺：

后臺服務拆分開StoreAPI和StoreSvr：

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

2）StoreSvr：一方面接受StoreAPI的請求，更新書籍數據，另一方面為現網用戶提供高可用的服務。

StoreAPI提供了如下接口能力：

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

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

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

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

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

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

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

目前，微信讀書已通過內容平臺完成了多家版權方自簽，并在探索自出品等內容創作新形式。

5、賬號系統的高可用性重構

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

賬號系統的架構在微信讀書誕生之初便一直沿用，同一個號段的賬號服務AccountSvr和MySQL部署在同一臺機器上，備機采用主從同步的方式獲取數據，當主機不可用時，備機承擔了所有讀請求。

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

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

這里涉及到的挑戰點如下：

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

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

同時，我們為整個遷移過程制定了周密的方案，把每一步進行了分解，且要求每個環節可灰度可回退，同時要做好數據的一致性檢查。

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

6、內容召回系統的架構設計

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

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

基于微信讀書構建RAG召回系統，核心挑戰如下：

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

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

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

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

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

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

7、寫在最后

雖然微信讀書已經發展了十個年頭，但我們的腳步從未停止。

在日常業務開發之余，我們也從未停止思考如何讓系統能走得更遠、更穩健，抓住每一個可能的優化點，隨時做好準備，迎接下一個精彩的十年。

8、相關資料

[1] 騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面

[2] 快速理解高性能HTTP服務端的負載均衡技術原理

[3] 子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐

[4] 知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路

[5] 新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐

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

[7] 阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路

[8] 達達O2O后臺架構演進實踐：從0到4000高并發請求背后的努力

[9] 優秀后端架構師必會知識：史上最全MySQL大表優化方案總結

[10] 小米技術分享：解密小米搶購系統千萬高并發架構的演進和實踐

[11] 一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等

[12] 通俗易懂：如何設計能支撐百萬并發的數據庫架構？

[13] 多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了

[14] 從新手到架構師，一篇就夠：從100到1000萬高并發的架構演進之路

[15] 美團技術分享：深度解密美團的分布式ID生成算法

[16] 12306搶票帶來的啟示：看我如何用Go實現百萬QPS的秒殺系統(含源碼)

9、微信團隊的其它精華文章

微信后臺基于時間序的海量數據冷熱分級架構設計實踐

微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路

微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享

微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案

一份微信后臺技術架構的總結性筆記

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

微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結

IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現

微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考

IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總

微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路

企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等

IM全文檢索技術專題(四)：微信iOS端的最新全文檢索技術優化實踐

微信團隊分享：微信后臺在海量并發請求下是如何做到不崩潰的

微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等

微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計

企業微信針對百萬級組織架構的客戶端性能優化實踐

揭秘企業微信是如何支持超大規模IM組織架構的——技術解讀四維關系鏈

微信團隊分享：詳解iOS版微信視頻號直播中因幀率異常導致的功耗問題

微信團隊分享：微信后端海量數據查詢從1000ms降到100ms的技術實踐

大型IM工程重構實踐：企業微信Android端的重構之路

IM技術干貨：假如你來設計微信的群聊，你該怎么設計？

微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎

微信后團隊分享：微信后臺基于Ray的分布式AI計算技術實踐

一年擼完百萬行代碼，企業微信的全新鴻蒙NEXT客戶端架構演進之路

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

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

1、前言

今年是微信讀書上線10周年，后臺技術架構也伴隨著微信讀書的成長經歷了多次迭代與升級。每一次的組件升級與架構突破，在一個運行了10年的系統上落地都不是一件容易的事情，需要破釜沉舟的決心與膽大心細的業務聯動。

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

2、整體架構設計

微信讀書是獨立于微信的App，且由于歷史原因，開發及運維環境均存在一定的差異與隔離。因此，微信讀書的后臺服務實現了從接入層到存儲層的一整套完整架構。

架構上分解為典型的接入層、邏輯層和存儲層：

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

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

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

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

3、異構服務間調用：RPC框架

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

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

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

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

Sidecar專注于處理網絡層的邏輯，和Business業務層分開為兩個進程，由WRMesh腳手架生成代碼，上層業務無需感知。

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

因此：Business進程可以由任意語言任意框架開發，只要遵循Sidecar的通信協議，只需要薄薄的一層網絡協議轉換即可接入到Hikit的服務治理框架中。

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

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

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

1）框架代碼需要重新適配，開發環境和現網環境都有巨大的改造成本。

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

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

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

1）一方面：我們保留了依賴于企微的運維環境，保障絕大多數現成服務的穩定運行。

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

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

4、書籍數據中臺的演進

4.1 技術背景

書籍是微信讀書的內容根基，書籍數量的多少、書籍質量的好壞，很大程度上決定了用戶是否選擇微信讀書作為閱讀App。

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

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

以EPUB為例，從內容產出到上架到微信讀書，大致經歷以下階段：

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

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

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

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

4.2 建設數據中臺

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

因此，我們構建了如下書籍數據中臺：

后臺服務拆分開StoreAPI和StoreSvr：

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

2）StoreSvr：一方面接受StoreAPI的請求，更新書籍數據，另一方面為現網用戶提供高可用的服務。

StoreAPI提供了如下接口能力：

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

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

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

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

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

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

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

目前，微信讀書已通過內容平臺完成了多家版權方自簽，并在探索自出品等內容創作新形式。

5、賬號系統的高可用性重構

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

賬號系統的架構在微信讀書誕生之初便一直沿用，同一個號段的賬號服務AccountSvr和MySQL部署在同一臺機器上，備機采用主從同步的方式獲取數據，當主機不可用時，備機承擔了所有讀請求。

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

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

這里涉及到的挑戰點如下：

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

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

同時，我們為整個遷移過程制定了周密的方案，把每一步進行了分解，且要求每個環節可灰度可回退，同時要做好數據的一致性檢查。

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

6、內容召回系統的架構設計

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

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

基于微信讀書構建RAG召回系統，核心挑戰如下：

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

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

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

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

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

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

7、寫在最后

雖然微信讀書已經發展了十個年頭，但我們的腳步從未停止。

在日常業務開發之余，我們也從未停止思考如何讓系統能走得更遠、更穩健，抓住每一個可能的優化點，隨時做好準備，迎接下一個精彩的十年。

8、相關資料

[1] 騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面

[2] 快速理解高性能HTTP服務端的負載均衡技術原理

[3] 子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐

[4] 知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路

[5] 新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐

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

[7] 阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路

[8] 達達O2O后臺架構演進實踐：從0到4000高并發請求背后的努力

[9] 優秀后端架構師必會知識：史上最全MySQL大表優化方案總結

[10] 小米技術分享：解密小米搶購系統千萬高并發架構的演進和實踐

[11] 一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等

[12] 通俗易懂：如何設計能支撐百萬并發的數據庫架構？

[13] 多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了

[14] 從新手到架構師，一篇就夠：從100到1000萬高并發的架構演進之路

[15] 美團技術分享：深度解密美團的分布式ID生成算法

[16] 12306搶票帶來的啟示：看我如何用Go實現百萬QPS的秒殺系統(含源碼)

9、微信團隊的其它精華文章

微信后臺基于時間序的海量數據冷熱分級架構設計實踐

微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路

微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享

微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案

一份微信后臺技術架構的總結性筆記

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

微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結

IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現

微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考

IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總

微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路

企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等

IM全文檢索技術專題(四)：微信iOS端的最新全文檢索技術優化實踐

微信團隊分享：微信后臺在海量并發請求下是如何做到不崩潰的

微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等

微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計

企業微信針對百萬級組織架構的客戶端性能優化實踐

揭秘企業微信是如何支持超大規模IM組織架構的——技術解讀四維關系鏈

微信團隊分享：詳解iOS版微信視頻號直播中因幀率異常導致的功耗問題

微信團隊分享：微信后端海量數據查詢從1000ms降到100ms的技術實踐

大型IM工程重構實踐：企業微信Android端的重構之路

IM技術干貨：假如你來設計微信的群聊，你該怎么設計？

微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎

微信后團隊分享：微信后臺基于Ray的分布式AI計算技術實踐

一年擼完百萬行代碼，企業微信的全新鴻蒙NEXT客戶端架構演進之路

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

1、基本介紹

RainbowChat-Web是一套基于MobileIMSDK-Web的網頁端IM系統。不同于市面上某些開源練手或淘寶售賣的demo級代碼，RainbowChat-Web的產品級代碼演化自真正運營過的商業產品，其所依賴的通信層核心SDK已在數年內經過大量客戶及其輻射的最終用戶的使用和驗證。RainbowChat-Web同時也是移動端IM應用RainbowChat的姊妹產品。

2、品質說明

? 源自真正運營的商業產品：RainbowChat-Web的技術源于真實運營的商業產品。

? 它不是個Demo：不同于市面上某些開源或淘寶售賣的demo級代碼，RainbowChat-Web的產品級代碼演化自真正運營過的商業產品，其所依賴的通信層核心SDK（即MobileIMSDK-Web）已在數年內經過大量客戶及其輻射的最終用戶的使用和驗證。

? 簡潔、精煉、優化、原生：RainbowChat-Web為了盡可能降低2次開發時的上手門檻、兼容性、可讀性、可維護性的難度，堅持不依賴任何前端框架（這些框架通常是指AngularJS、VUE、EmberJS、React等），返璞歸真，只使用原生JS+HTML+CSS（再無其它復雜性），極大降低開發者的上手難度、兼容成本，達到最簡潔、最精煉、最靈活的目標（簡潔、簡單、回歸本質的東西，才能擁最強的生命力）。

截止目前：RainbowChat-Web努力保證在各主流系統、主流瀏覽器、不同分辨率屏幕上的體驗，包括但不限于：Chrome、Safari、FireFox、Edge、360瀏覽器、世界之窗瀏覽器等▼

3、運行演示

? 運行截圖，詳見：《RainbowChat-Web前端功能截圖》
? 演示視頻，詳見：《RainbowChat-Web運行演示視頻》

4、功能簡介

1、支持文本消息、查看語音留言消息(由App產品發送)、圖片消息、大文件消息、查看短視頻消息(由App產品發送)、名片消息、位置消息、消息表情、快捷消息、消息撤回、消息轉發等；
2、支持一對一陌生人聊天模式；
3、支持一對一正式好友聊天模式；
4、支持多對多群聊聊天模式；
5、完善的群組信息管理：建群、退群、解散、轉讓、邀請、踢人、群公告等；
6、完整的注冊、登陸、密碼找回等等功能閉環；
7、個人中心功能：改基本信息、改個性簽名、改頭像、改密碼等；
8、支持查看個人相冊、個人語音介紹；
9、完整的離線消息/指令拉取機制；
10、完整的歷史消息/指令存取機制；
11、完整的好友關系管理：查找好友、發出請求、處理請求、刪除好友、好友備注等；
12、以及其它未提及的功能和特性。

5、技術亮點 

1）輕量易使用：純原生JS編寫，堅持不依賴任何前端框架（這些框架通常是指AngularJS、VUE、EmberJS、React等）；

2）模塊化設計：所有UI模塊、數據邏輯均由獨立封裝的JS對象管理，代碼規范、低耦合，有效防止代碼復雜性擴散；

3）瀏覽器跨域：所有AJAX接口均為JSONP實現，百分百支持跨域；

4）通信代碼解偶：得益于高內聚的MobileIMSDK-Web工程，實現了IM功能邏輯與網絡通信的解偶，利于持續升級、重用和維護（這是經驗不足的IM產品做不到的）；

5）支持WebSocket：并非某些產品中還在使用的過時“長輪詢”技術，真正的“即時通訊”；

6）網絡兼容性好：核心層基于MobileIMSDK-Web技術，在不支持WebSocket的情況下仍可很好地工作；

7）斷網恢復能力：擁有網絡狀況自動檢測、斷網自動治愈的能力；

8）輕松支持加密：一個參數即可開啟SSL/TLS通信加密；

9）服務端慢io解偶：IM實例本身堅持不直接進行DB等慢io的讀、寫，保證IM實時消息高吞吐和性能；

10）服務端邏輯解偶：得益于MobileIMSDK-Web工程，實現了上層邏輯與網絡通信核心的解偶，底層數據通信全部通過低偶合的回調通知來實現；

11）完善的log記錄：服務端使用log4js日志框架，確保每一關鍵步驟都有日志輸出，讓您的運行調試更為便利；

12）聊天協議兼容：實現了與RainbowChat-APP產品完全兼容的協議模型；

13）消息收發互通：實現了與RainbowChat-APP產品的無縫消息互通。

6、支持的聊天消息類型

7、好友聊天

8、群聊聊天

9、發送“群名片”消息

10、發送“位置”消息

11、“消息撤回”

12、“消息轉發”

12、“消息引用”

14、“@”功能

15、其它特性和細節

聊天區上方聊天對象信息顯示：（查看視頻）

消息送達狀態圖標顯示：（查看視頻）