全平台、多賬號體系的58微聊前端系統架構實踐

簡介

溝通是人類賴以生存的基礎。在58同城這個中國最大的分類信息生活服務平台中，58微聊承擔著溝通的紐帶的作用。

58微聊承載著服務用戶，連接團隊，助力未來的艱巨使命；目前已經接入房產、招聘、二手車、黃頁等各大業務線，潛移默化中推動著58方方面面蓬勃發展，尤其是在服務用戶方面很好的契合了我們的使命：「通過互聯網讓人們生活簡單美好」。

58微聊作為即時通訊工具，提供Android、iOS、PC、Web、Wap、小程序全平台的支持。下面將具體分析58微聊的前端技術架構。

整體架構

上圖是微聊前端系統的整體架構，主要分為網路、SDK、UI、接入四層及存儲、安全、質量監控、polyfill等模塊。

各層及模塊的功能如下：

網路層：提供統一的短連接、長連接介面調用。

SDK層：提供統一的業務介面封裝，以及核心的業務邏輯管理。

UI層：UI層是體現平台差異最大的地方，採用了完全不同的設計風格，所以各端的UI實現完全獨立。PC版需要兼容IE8-，採用原生語法模塊化開發；M端則使用VUE框架；小程序端由於目前相關框架問題還比較多，採用原生小程序語法開發。

接入層：58集團旗下擁有58、趕集、安居客等獨立運營的業務線，他們各自有自己的賬號體系及PC、M、小程序的產品，所以UI上很難做到適合所有的業務需求。針對各端我們開發了一款默認的UI，各業務線可以基於默認的UI進行定製，也可以只接入SDK，自行實現UI界面。

存儲模塊：為了使用的便捷和最大限度地復用代碼，存儲模塊屏蔽了各平台的本地存儲方案差異，提供了統一的存取介面。

安全模塊：通過對請求數據加密，防止低成本地進行介面模擬調用；通過對渲染的數據過濾，防止XSS攻擊。

polyfill模塊：為了使用更多便捷、高效的介面併兼容各平台，將一系列的polyfill進行統一管理、按需載入。

質量監控模塊：上報用戶場景下系統的一些關鍵指標，收集在開發、測試環節發現不了的問題，為後續優化提供數據支撐。

消息中心

消息中心是SDK層最核心的功能，簡單的來說就是接收伺服器端下發（通過websocket或者HTTP長連接）的消息。但不管是websocket還是HTTP長連接（下稱通道），對伺服器端及客戶端的資源消耗都是非常大的。

在PC上同時打開多個頁面是非常常見的事情，如果每個頁面都建立一個通道，資源消耗將是非常巨大的，尤其是服務端開銷。

為了解決以上問題，我們設計、封裝了多頁面消息同步的消息管理器，確保了同一個瀏覽器同時有且只有一個通道存在，所有的消息都通過這個唯一的通道下發。

這裡邊有兩個核心問題需要解決：如何確保有且只有一個通道？通道下發的消息如何同步到其他頁面？

第一個問題：我們在所有頁面共享一個心跳（本地存儲的一個欄位），在存在通道的頁面定時（如：3秒）更新心跳時間，在沒有通道的頁面定時（如：5秒）檢測心跳是否有更新，如果有則說明有其他頁面存在通道，否則馬上建立新的通道（因為沒有任何頁面維持通道了）。

第二個問題：消息通過唯一的通道下發後，最直觀的方式就是寫入本地存儲，其他頁面定時去查詢。但需要更新數據的地方非常多，如果每個模塊都去定時讀取數據，程序將會非常複雜並難以管理。我們的做法是，統一封裝了一個消息管理器，提供統一的訂閱/發布介面，其他需要數據的模塊只需要統一的訂閱消息管理器特定類型的消息就可以了。

消息管理器主要負責兩個核心功能：接收通道消息並寫入本地存儲器和定時讀取本地存儲器數據並回調給已訂閱的模塊。

消息中心的流程如下：

消息管理器類圖如下：

跨平台兼容

58微聊前端項目在58集團內的使用非常廣泛。

從端來看，需要支持PC、M、和小程序。

從業務線來看，需要支持58、趕集、安居客等，他們都有各自的賬號體系。

從瀏覽器兼容性來看，PC上需要兼容IE8及以下版本，M端需要兼容IE9+版本，小程序暫無太多需要兼容處理的地方。

一方面，多端、多業務線的支持給技術選型帶來了很大的挑戰，最簡單直觀的就是各端各自為政，進行獨立開發、維護。但由於業務邏輯的一致性，三端的業務代碼會有非常高的重合度，這意味著每一次的改動需要同時修改三個代碼庫，這既浪費時間，又難以做到修改同步。基於此，我們把業務重合度高的SDK層進行合併、統一開發、管理，最大限度復用代碼，降低維護成本。而對區別非常大、復用性非常小的UI層則完全獨立開發、迭代，有效避免技術選型的局限性。

另一方面，雖然ES6標準都已經發布很久了，但對於IE9-的瀏覽器連ES5都不支持，所以很多簡潔的語法不能直接應用到項目中，不過像，這類的語法糖，已經有很成熟的polyfill方案，所以在項目中可以在引入這些polyfill的情況下，盡情享受這些新語法帶來的便利。但兼容代碼的引入勢必會增大代碼的體積，58微聊項目的解決方案是，在業務代碼編寫的時候使用新的語法，但只在WebSdk中引入polyfill以實現對低版本瀏覽器的兼容，這樣做，既可以在所有代碼中使用新的語法，也不會對不需要兼容的平台（M端和小程序）引入額外的代碼，實現了代碼利用的最優化。

質量監控

網路環境千變萬化，用戶的設備、系統、網路千差萬別或者說千奇百怪的，不管是開發還是測試人員的環境都只是很小的一個子集。僅僅通過開發、測試人員很難覆蓋所有場景，我們需要了解更多用戶實際的情形，從而更全面地了解整個系統的質量並實施改進措施。

為了解決以上痛點，我們開發了前端質量監控組件，用於上報用戶場景下系統的一些關鍵指標，從而收集在開發、測試環節發現不了的問題。

這些關鍵指標主要包括：

錯誤日誌：可以有效監控代碼BUG，在大量用戶反饋之前拿到錯誤現場，可以更快地解決問題。也實實在在地為我們的系統發現了一些難以復現、只在特定用戶環境出現的BUG，使得定位、解決問題的效率得到了本質的提升，而且還極大程度地降低了對用戶的打擾，將問題扼殺在萌芽階段，避免了更大規模的蔓延。

性能指標：可以有效監控代碼質量，為我們後續的性能優化提供了基礎和標杆，可以通過性能指標曲線方便、快捷地看到優化的效果。

劫持信息：可以有效把握網站安全現狀，為後續的安全策略提供場景指導。後續我們會根據實際的劫持情況，開啟CSP、RSI等安全策略。

寫在最後

58微聊前端項目，作為58集團各服務平台的基礎、核心功能，連接著平台上的各類用戶，發揮著橋樑的作用。經過一兩年的功能迭代，項目變得比較複雜，在追求卓越的58工程師文化的驅動下，我們不斷地進行著代碼的重構，從而達到目前的分層結構。

時代在變遷，技術在進步，任何系統或者產品都需要不斷的迭代升級，以適應新的形勢。58微聊前端項目作為集團核心的基礎服務工具，我們也在不斷地追逐更極致的用戶體驗。

短期來看，我們會充分利用質量監控收集的關鍵指標數據，針對性地進行代碼質量和性能的提升。

中長期來看，我們會緊隨技術變遷的步伐，探索、研究pwa、csp、webrtc等新技術運用到項目的可行性以及落地方案的制定和實施。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！