Feed架構-我們做錯了什么
在過去幾年，所在的微博技術團隊在一定程度成功解決了feed架構的擴展性與性能的問題，大部分精力已經從應對峰值性能或者數據擴展中解放出來。
幾天前，拿著上面這張架構圖問內部一些架構師，目前完成的工作及存在的主要問題是什么？
完成的工作不出意料，大家的觀點比較類似，主要在架構的工程成熟度方面。
- 解決了數據規模大且長尾訪問的問題，通過按時間線的冷熱分區設計，在MySQL等數據庫上成功實現了低成本的長尾分區實現。由于社交產品 中大部分訪問（90%以上）發生在最近的數據，而較舊的數據（長尾數據）相對訪問偏少，因此在存儲上利用時間維度進行不同存儲區域區分，來達到性能及成本 的收益。
- 解決了數據存儲可擴展的問題，可以滿足3年左右數據擴展的需要。這個主要利用成熟的數據庫拆分方案，簡單的實現通常設計成倍擴容，在最初建表時候預留足夠多的分表，當容量增長時將這些表遷移到更多服務器上去。
- 解決了百萬QPS訪問的問題，主要依賴緩存分區及復制機制的成功應用，通過緩存復制及分級，可以讓每秒上十萬次訪問的數據獲得非常好的訪問性能，同時數據復制機制可以提高可用性，防止單點機器故障時給數據庫帶來范圍壓力。
- 解決了可用性及錯誤隔離問題，得益于歷年來建設的SLA體系，服務之間有良好的服務契約及錯誤隔離手段，因此核心功能 有99.99%+的可用性。
但是對于不足呢？如果架構重新再來，你會怎么做？這個問題回答比較多元，經過整理一些主要觀點如下。
首先是從解決架構的問題說起，上述feed架構主要解決了在社交媒體環境中，實時及可擴展的解決基于關注關系的數據分發問題。
由于微博是一個實時的網絡，人們常把推ter/微博這種社交媒體產品比作是地球的脈搏，它確實無時不刻都在產生海量的數據，并且產生著不可預 測的大量隨機峰值訪問，業界也是首次隨著社交網絡的出現遭遇這種架構上的scalability問題，記得在2009-2010年左右，推ter由 于壓力過大經常出現鯨魚頁面錯誤。經過幾年的努力，包括微博在內的業界主要公司都已經成功解決了關系模型的數據分發架構問題。
但在用戶的層面，使用社交媒體產品依舊被信息過載的問題所困擾。
- 雖然每天收到大量信息，但是大部分不是自己感興趣的信息。
- 基于用戶關注維度的興趣閱讀效率不高，用戶關注了一個興趣領域的同行，但這個同行卻大部分時候在談風花雪月。
- 由于傳播的低成本，大號在過度的使用消息通道，生產大量用戶未必感興趣的低質內容。
- 廣告及普通內容的界限很模糊。
- 由于利益關系，僵尸帳號及內容通過變換形式在大行其道。
- 內容同質化及雷同問題，內容被精英占領，小人物聲音不能得到有效傳遞。
在社交網絡中，上述問題，不可能全部像Google的使命那樣，通過技術手段得到解決。但是大部分又跟技術密切相關。
- 基于用戶維度組織內容高效滿足興趣閱讀的難度。在上圖中，綠色的框中是數據流經的主要通道，但在傳統的SNS架構中，這些數據的組織都是 基于用戶緯度。從用戶緯度組織數據較好解決了傳統feed模型基于關系聚合數據的問題。但正是由于數據是從關系維度來組織的結構，造成并不能給改進上述閱 讀效率問題帶來便利。由于在一定程度信息過載，興趣閱讀是發展方向，但是在架構上目前并沒有清晰的解法。
- 信息識別及低質內容鑒定的技術挑戰。雖然業界已經在大數據、自然語言處理等方面積累了不少經驗，但在具體場景中，信息識別仍然還在比較初級的階段。低質內容不一定是垃圾廣告，只是當前瀏覽者不感興趣。
- 反垃圾算法。
社交網絡的信息架構和搜索引擎有很大的不同，在瀏覽feed是并不像使用搜索有明確的搜索意圖，非死book曾經嘗試使用EdgeRank來解決newsfeed算法的效率問題，但是結果并不如預期理想。由于社交關系的存在，用戶對出現（及不出現）什么內容的可解釋性非常敏感，不能接受好友的信息在排序結果不能看到。因此僅能說feed架構只是解決了初步的問題，更大的問題依舊在思考及尋找解決的途中。
PS：本文上述內容會在12月19日ArchSummit北京大數據環境的feed架構演講中介紹，歡迎參會的同行前來交流。
如想及時閱讀Tim Yang的文章，可通過頁面右上方掃碼訂閱最新更新。
Similar Posts: