大型互動平臺中好友動態系統架構設計與實現

劉 平，王治國，曹 剛，吳 迪，彭 升

（中國網絡電視臺，北京 100142）

0 引言

《第27次中國互聯網絡發展狀況統計報告》顯示，截至2010年12月，中國網民規模達到4.57億，較2009年底增加7330萬人；互聯網普及率攀升至34.3%，較2009年提高5.4個百分點。另外，《報告》顯示，中國網民的互聯網應用表現出商務類應用用戶規模繼續領漲、網絡娛樂漸入平穩期、社交類應用保持較快發展速度的特點[1]。

Web2.0[2]的浪潮席卷了整個互聯網，帶來了人們對互聯網應用的徹底轉變。基于六度空間理論發展起來的社會化網絡服務或社交網站（Social Network Service，SNS），是Web2.0的典型代表。SNS通過網絡服務不僅幫助人們找到朋友、合作伙伴，而且能夠實現個人數據處理、個人社會關系管理、信息共享和知識分享，最終幫助用戶利用信任關系拓展自己的社交網絡，達成更有價值的溝通和協作，從而帶來豐富的商業機會和巨大的社會價值。

從2005年開始，以Facebook為代表的SNS類網站在一夜之間火遍全球，無數類似的網站出現在互聯網上。2010年上半年，Facebook的訪問量首次超過Google，成為全球流量最大的網站。在國內，SNS也在蓬勃發展，成為過去兩年最熱門的網站類型之一。

動態（feeds）是將用戶在網站的活動進行記錄并推送到其好友主頁的功能，目前已經廣泛用于社交網站。動態功能很好地把用戶和內容結合起來，大幅提高了用戶的互動。當用戶在站內進行某些操作行為后，該用戶相關的好友會收到相應的此用戶行為的消息通知。筆者認為用戶看見好友的行為通知后很可能也跟進一個的類似或相關的行為，這就是“黏度”的體現。因此，好友動態系統是大型互動平臺的核心，承載著各個業務系統與用戶之間的互動。

本文分析了大型互動平臺中好友動態系統架構面臨的調整，確定了架構設計的模式和原則，并詳細介紹了好友動態系統架構的設計與實現。

1 架構挑戰

對于網站運營來說，以下場景在網站的整個生命周期里很有可能出現，而且一旦出現都是系統的噩夢：

1）場景一：某硬件或服務故障可能導致整個網站不可用

系統上線運營后，各項業務都逐漸進入上升軌道，活躍用戶也穩步增加，各項數據都表明網站在年輕人群中的社會影響力與日俱增，此時系統中一個機器發生宕機，開始有用戶的某些操作無響應，然后更多相關的服務獲取不到數據，最后甚至用戶根本無法登錄系統。故障已經發生，用戶已受到影響，當務之急是快速恢復機器工作，縮短故障時間。如果機器只是掉電宕機，設備并無大礙，重新啟動系統后一切恢復正常；如果磁盤等硬件發生故障，需要將應用遷移到備份服務器，快速啟動備用服務器。

如何避免單點故障或者將單點故障的影響降到最低呢？

2）場景二：新增業務規則或對以前業務規則的升級導致重新開發系統

系統經過一兩年的運營逐步趨于穩定，但產品團隊和開發團隊之間的爭論卻越來越多，產品團隊開始抱怨新的創意無法得到快速響應，開發團隊沒日沒夜加班仍然有干不完的活，對系統功能的改造總是牽一發動全身，更別說開發新的業務。

如何讓架構能夠適應未來業務的發展，為潛在的擴展點進行設計？

3）場景三：春節期間活躍用戶激增導致系統性能下降

春節前，營銷團隊在電視媒體、平面媒體、網絡媒體等進行了全方位的營銷宣傳，而且效果非常明顯，春節期間活躍用戶數快速增長，甚至超過去年整年的增長，但隨之而來的是，隨著用戶數的增長，以前沒有發現的問題開始暴露出來，運營團隊不得不每天堅守崗位，甚至采用輪班制，但網站的響應時間還是下降了，而且開始出現間隔性的中斷服務，用戶開始抱怨，開始選擇其他平臺。

如何應對潛在的用戶數激增對系統服務質量的影響？

大型互動平臺中好友動態系統的架構挑戰主要來自于設備、服務和用戶，因此假設：1）所有的硬件和服務總會有故障；2）業務規則在運營過程總會發生變化；3）用戶數會在某個時間呈現爆炸式增長。

2 架構模式和設計原則

2.1 架構模式選擇

好友動態的架構實現有兩種選擇：拉模式和推模式（見表1）。推模式，指用戶發表一條動態時，動態系統將這條動態拷貝N次分發給他的粉絲或好友；用戶讀取時，直接從“我的動態”和“好友動態”中讀取動態列表。拉模式，指當用戶查詢動態消息時，從所有好友的動態隊列中獲取動態，拿到這些動態后再做排序和合并操作；用戶發表動態時，直接發布到自己的隊列中。

表1 推模式與拉模式的比較

結合項目的實際需求，項目組認為推模式架構簡單，能夠給用戶提供更好的產品體驗，而多占用的存儲空間是可以接受的。

2.2 架構設計原則

針對好友動態系統架構面臨的調整，項目組為架構設計確定如下架構原則[3]：

1）可靠性

可靠的服務是系統的基礎，隨著系統中設備數量、服務數量的增加，服務大規模分布式部署，可靠性的成本越來越高。服務的可靠性也不再局限于設備的可靠，設計可靠的軟件架構才能從根本上提高系統可靠性。

2）可伸縮性

可伸縮性就是通過增加資源使服務容量產生線性（理想情況下）增長的能力。可伸縮應用程序的主要特點是：附加負載只需要增加資源，而不需要對應用程序本身進行大量修改。可伸縮性包括兩個方面，向上伸縮（Scale-Up）和水平伸縮（Scale-Out）。

向上伸縮指通過使用性能更好、速度更快和成本更高的硬件來實現可伸縮性。包括添加更多內存、添加更多或更快的處理器，或者只是將應用程序遷移到功能更強大的單個計算機。通常，該方法能夠在不改變源代碼的情況下增加容量。從管理角度而言，情況并未發生變化，因為要管理的仍然只是一臺計算機。

水平伸縮的實現需要使用多臺計算機，但計算機集合本質上是作為單個計算機運行的。通過使若干臺計算機專門執行常見的任務，增加了應用程序容錯。當然，從管理員的角度看，外擴使計算機的數目增多，從而提出了更大的管理挑戰。

考慮到高性能設備成本昂貴，服務器都采用普通的PC或PC服務器，可伸縮性需要更多依賴水平伸縮，即通過更多的普通設備擴展系統整體容量。

3）高并發性

系統的注冊用戶數決定了必須解決大量用戶并發訪問系統的問題，而且隨著網站整體影響力的擴展，用戶數會更大。此外，為了提供更豐富的用戶體驗，在用戶登錄網站期間會定期訪問好友動態系統，獲得更新的數據。以1000萬注冊用戶為例，10萬用戶同時在線，每個用戶10 s刷新一次動態數據，那么每秒將會有10000個并發請求，這樣的規模是傳統網絡不可比擬的，也是好友動態系統架構的重點。

4）大數據量

一個用戶的每一個操作都會以消息的形式通知給其全部數量的好友；同樣其全部好友的每一個操作也將以消息的形式通知給用戶。好友動態系統的特點決定了好友越多系統的數據量就會越大。數據顯示，在Facebook網站等級的粉絲，全球最具人氣的人物是當紅女歌星La?dy Gaga，她的注冊粉絲達到了2200萬。

5）業務規則可擴展

好友動態系統是互動平臺的核心引擎，幾乎所有應用都需要通過好友動態系統與用戶進行互動，每個應用的業務邏輯和數據標準又有很大的差異；而且為了保證消息質量，具有良好的可閱讀性必須對用戶的消息進行合并。因此需要架構設計支持靈活的業務規則。

3 架構設計

3.1 整體架構

好友動態系統整體上采用分布式系統架構方法，消息按流水線的方式進行處理，分別由轉發服務器、分發服務器和消息服務器處理，其中最重要的好友關系信息從好友關系系統獲得，并緩存在關系緩存集群中。另外，為了實現自動化運營，好友動態系統提供了服務監視系統和配置管理系統，如圖1所示。轉發服務器將客戶端發布的動態消息轉發到分發服務器；分發服務器對客戶端的消息進行預處理，并根據好友關系將動態消息推送到各個好友的消息服務器；好友關系緩存服務器為分發服務器提供好友關系緩存，提高分發服務器消息推送性能；消息服務器接收分發服務器推送的消息，對消息進行合并處理，存儲用戶的動態消息，并為用戶提供動態檢索服務。

3.2 關鍵架構點

3.2.1 水平伸縮

大型互動系統的特點是用戶基數大，而且無法預測將來的用戶數會達到什么水平，因此設計之初就考慮采用水平伸縮方案。當用戶規模增長后，不需要修改系統的源代碼，只需要增加普通的PC或PC服務器，部署更多的分布式服務，就可以擴充系統的容量，提升系統的性能。

系統的整體架構上，各個關鍵服務都支持水平伸縮，包括轉發服務器、分發服務器、消息服務器。

客戶端隨機選擇轉發服務器發布消息。當用戶數增加，要求轉發服務器集群提供更高的并發，更快的響應時間時，可以部署更多的轉發服務器，降低單個服務器的負載，提升響應時間。

用戶ID與分發服務器進行綁定，綁定的算法有靜態綁定算法、哈希求余算法、一致性哈希算法等，這些算法的復雜度依次提高，而進行依次下降，但服務器數量擴展的友好型也依次提高。根據好友動態系統用戶ID線性增長的特點，最終采用簡單有效的靜態綁定算法。轉發服務器將用戶的消息發布到該用戶綁定的分發服務器。當用戶數增加，要求分發服務器集群提供更高的并發，更快的響應時間時，可以部署更多的分發服務器，這樣單個分發服務器承載的用戶數沒有變化，響應時間也不會受到影響。

用戶ID與消息服務器進行綁定，仍然采用靜態綁定，一個消息服務器只為某個號段的用戶提供服務。當新注冊用戶增加時，最后一個服務器的壓力會不斷增加，再增加一臺服務器將新注冊的用戶號段劃分到這個服務器，從而控制最后一臺服務器的壓力；當某個號段的用戶活躍程度顯著增加時，可以將該號段重新劃分，進行負載均衡。

3.2.2 消息隊列

隊列使系統的各個模塊之間實現松耦合，將同步業務調用轉化為異步處理過程。在系統架構方面，關鍵業務模塊之間都是通過消息隊列實現異步消息處理，如圖2所示。

在此架構中，因為各個服務只關心與其交換的消息隊列，中間處理的各個服務的故障都不會影響都之前或之后的業務處理，而且服務恢復后能夠繼續提供服務。因此消息中間件的穩定性和性能是衡量中間件的關鍵指標。Kestrel是twitter開源的消息隊列中間件[4]，在twit?ter以及大量網站中經過實踐檢驗，穩定性和性能都非常不錯，內部測試也證明可以滿足項目的需求，因此項目組選擇kestrel作為消息中間件。而且Kestrel采用mem?cached兼容的協議，這也是大多消息隊列中間件支持的協議接口，即使系統運行中發現Kestrel隊列存在問題，也可以快速遷移到其他消息中間件。

各個服務模塊采用無狀態的服務模式，即服務模塊每次都根據消息隊列中的消息進行處理，這樣即使遇到一些惡意的非法消息也能夠正常處理，不會影響其他消息的處理。

此外消息隊列還有蓄洪的作用。好友動態系統中，當發生特殊事件時用戶會有一個爆發效應，比如世界杯期間活躍用戶數會有爆炸式增長。消息隊列的作用是，當洪峰到來時，快速容納大量請求，從而不影響隊列前端應用的性能，然后隊列后端的應用慢慢處理隊列中的消息。對于動態系統來說，只是延遲了動態被好友感知的時間，而且這種延遲好友是很難感知的，但對系統的負載能力的提升非常明顯。

3.2.3 緩存機制

眾所周知，內存的訪問速度遠遠高于硬盤的訪問速度，因此緩存的效果對網站的響應時間至關重要。緩存將系統中需要大量計算或頻繁訪問的資源由硬盤轉移到內存中，降低系統IO的處理的時間，從而提高訪問的響應時間。

系統架構方面緩存主要應用在分發服務器和消息服務器。

分發服務器中，每個消息的處理都需要用戶的好友關系，這些信息存儲在好友關系數據庫中，如果每次處理都直接訪問數據庫，每秒大概需要2000次并發的數據庫訪問，這樣的壓力對數據庫來說是致命的，很快就會發現已經連不上數據庫，而且查詢數據庫的響應時間也會很長。因此將好友關系加載到內存中，將極大地提升查詢性能，而且好友關系的緩存命中率也決定了分發服務器的消息處理性能。

為用戶關系緩沖設計了兩個功能模塊，緩存服務器集群和用戶關系變更通知服務。前者將好友關系數據庫中的好友信息緩存在內存中；后者在好友關系數據庫發生變更時，及時將變更的信息更新到緩存服務器集群。

消息服務器一方面接收分發服務器寫入的消息，另一方面響應客戶端的查詢消息，而且兩者都存在大量的并購，對響應時間也有一定要求，因此都設計了緩存機制。

為了提高分發服務器寫入消息的性能，消息服務器在接收消息后立即將消息寫入內部的消息緩存隊列中，而不用等待消息合并到用戶的消息隊列中。

在大量注冊用戶中，有一部分用戶比較活躍，另外一部分用戶相對沉寂，客戶端的查詢請求大并發是活躍用戶的請求，而且活躍用戶往往會連續發送多次查詢請求，因此消息服務器會緩存活躍用戶的消息隊列。對活躍用戶判斷是否準確也決定了緩存的效果，那么如何判斷活躍用戶？本文采用最近訪問作為判斷依據，即如果用戶訪問時用戶的消息隊列不在內存中，那么訪問過后將會被加載到內存中，下次訪問時直接從內存中讀取。當內存不足時，將會替換內存中最長時間未被訪問的內容。

3.2.4 數據格式

數據采用互聯網廣泛應用的JSON格式，在流水線的處理過程中數據格式也在不斷發生變化。

客戶端采用轉發服務器的數據格式發送消息，格式如圖3所示。

分發服務器將轉發服務器的數據結構轉換成分發服務器數據機構，并分發到消息服務器，格式如圖4所示。

分發服務器的消息經消息服務器處理后，轉換成消息服務器的數據格式，格式如圖5所示。

3.2.5 協議接口

各個服務模塊主要提供對動態消息讀寫、刪除接口，而且動態消息的排序、合并都按內部確定的合并規則執行。此外，服務器內部狀態的監視接口為服務器狀態監視提供了方便，控制接口則讓服務升級更加安全。

通信協議有很多選擇，如支持REST架構風格的HTTP協議、SOAP協議和memcached協議，即時通信領域的XMPP協議等，但最終本文選擇了memcached協議，其一該協議支持REST架構風格，適合于資源訪問類服務；其二該協議支持廣泛的客戶端開發語言，如Java、C＋＋、Php、Python、Perl等；其三，系統中消息隊列和內存緩存中間件支持該協議，因此采用memcached協議的開發成本和風險是最小的。

4 核心服務的設計與實現

4.1 轉發服務器

轉發服務器的主要難點在于支持大量客戶端并發訪問。Apache Mina是一個Java NIO框架，為用戶開發高性能和高擴展的網絡應用服務器帶來的方便，因此本文選擇基于Mina框架設計轉發服務器。本文的測試數據顯示，基于Mina的轉發服務器可以支持每秒1000次網絡消息處理，通過接收緩沖區大小還可以進一步提高消息的吞吐量。

4.2 分發服務器

分發服務器中最重要的設計是消息處理擴展框架，支持靈活的業務擴展。

消息的預處理框架，需要針對每種業務類型進行單獨的處理，并且要考慮以后新增業務類型或修改業務處理規則時，盡可能不影響系統其他組件。因此消息處理擴展框架基于OSGi框架進行設計。

OSGi又叫做Java語言動態模塊系統[5-6]，它為模塊化應用的開發定義了一個基礎架構。在OSGi中，軟件是以Bundle的形式發布的。一個Bundle由Java類和其他資源構成，它可為其他的Bundle提供服務，也可以導入其他Bundle中的Java包。

消息處理流程如圖6所示，各個Business Processor組織成一個處理鏈，有Message Processor Center進行調度，并根據當前Business Processor的處理返回值決定下一步調用哪個Processor，最后一個Business Processor將處理后的消息寫入輸出消息隊列。

Business Processor支持兩種范圍類型：Next、Term和ProcessorID。 當 Business Processor返 回 Next，Message Processor Center調用預定義的下一個Business Proces?sor；當 Business Processor返回 Term，Message Processor Center終止當前消息處理鏈，處理下一條消息。

消息處理過程中，Business Processor可以將消息輸出到其他系統，并不影響下一步業務的處理；也可以將消息丟棄，從而實現消息過濾器的作用。

4.3 消息服務器

4.3.1 動態消息數據庫

動態消息數據庫通過分庫來優化性能，包括緩存庫、索引庫和消息庫。

消息分發時，首先將消息分發到緩存庫，然后由消息處理進程分批處理；而在動態查詢時，首先訪問索引庫獲取用戶的消息隊列（我的動態隊列或好友動態隊列）獲取動態的索引，然后根據動態ID從消息庫中獲取動態消息，并將結果合并返回給用戶。

采用增加消息緩存庫主要出于兩方面考慮，一方面隔離了分發系統和消息服務器，分發服務器發布消息與消息服務器處理消息可以異步處理，只需要將消息發布到緩存庫，而不必等待消息服務器處理消息，提高分發系統的性能。另一方面緩存庫在不影響消息讀寫性能的情況下，又保證了消息可靠性，消息被持久化保存在緩存庫。

將索引庫和消息庫分離，降低了推模式下消息數據庫中重復消息的數量。一個動態的索引大約23～42 byte，而一個動態消息平均大小是1 kbyte，這樣一個消息庫只保存一份動態消息，每個消息將節約980 byte。比如一個名人在消息服務器上的好友10萬個，那么該名人每條動態將節約98 Mbyte數據。

4.3.2 備份與遷移

采用NoSQL數據庫帶來了高性能，同時也要面臨NoSQL數據庫備份遷移工具缺乏的現狀，為此開發了針對動態消息數據庫的備份和遷移工具。

備份工具支持動態消息數據庫熱備份、增量備份，因此設置計劃任務每天執行本機備份，并將備份數據自動遷移到備份服務器。消息服務器故障時，可以快速部署消息服務器應用，并從備份服務器下載相應的動態消息數據庫，快速恢復服務。

遷移工具支持根據用戶空間進行消息數據庫合并。由于用戶ID與消息數據庫采用靜態綁定策略，重新劃分用戶空間將涉及到歷史數據的遷移，比如系統運行一段時間后，發現某些消息服務器中活躍用戶數少，負載小，可以將這些消息服務器合并成一臺消息服務器。

5 小結

系統測試數據顯示，好友動態系統架構能夠滿足大量用戶并發訪問、響應時間較快，而且架構能夠通過水平伸縮快速擴容系統支持用戶規模，在穩定性方面單個服務或硬件的故障對系統影響較小或只影響一定范圍的用戶。到目前為止，好友動態系統已經上線運行兩個多月，表現穩定可靠，友好地支撐了互動平臺好友動態的分發。

[1]CNNIC第27次互聯網報告：個人互聯網應用狀況[EB/OL].（2011-01-19）[2011-04-01].http：//it.people.com.cn/GB/119390/118340/212787/212790/13765052.html.

[2]中國互聯網協會.中國Web2.0發展狀況和調查報告[R].北京：中國互聯網協會，2006.

[3]郭欣.構建高性能Web站點[M].北京：電子工業出版社，2009.

[4]鄧侃.解剖Twitter：Twitter系統架構設計分析[EB/OL].（2010-03-27）[2011-04-01].http：//www.tektalk.org.

[5]基于OSGi實現分布式服務框架歷程[EB/OL].（2008-01-14）[2011-02-01].http：//www.blogjava.net/BlueDavy/archive/2008/01/14/175054.html.

[6]Oracle.Oracle Berkeley DB Java editionhigh availability-large configuration and scalability testing[EB/OL].[2011-03-25].http：//www.oracle.com/technetwork/database/berkeleydb/bdb-je-highavailabilitywhitepaper--129298.pdf.