58同城：商家（移動）管理平臺技術架構解析 | UPYUN Open Talk NO.3

孫玄 58同城系統架構師

咱們都知道，58同城是一個分類信息網站，涵蓋房產、二手車、招聘、黃頁等內容，在每個類別裏都能看到方便用戶交流溝通的58幫幫。58幫幫分爲IM部分和非IM的業務處理部分，目前，整個幫幫系統天天要處理10億次+的發消息，加好友等傳統IM請求，和30億+的業務線操做，總請求到達40億次+。幫幫同時在線用戶量也突破了100萬，這給咱們帶來了很大的挑戰。

系統起步：傳統IM

說到挑戰，58幫幫從誕生到如今，曾經面對過不少。最開始時，它只是一個傳統的IM，主要用來知足用戶溝通和傳遞信息的功能。針對這樣的業務場景，咱們設計了以下的結構：

整個架構分爲四層：接入層、邏輯層、路由層、數據層。

1）接入層
直接面對 PC、移動、網頁海量客戶端的鏈接請求，整合成少數的長鏈接，並將請求轉發至邏輯層。

2）邏輯層
主要是一些業務邏輯的處理（例如權限校驗、添加好友、發送消息等）。

3）路由層
主要處理和用戶一次登陸session相關的數據（好比：用戶在線狀態，登陸IP等），這部分涉及的數據變化很是快，不必固化，-直接存儲在內存中。

4）數據層
嚴格來說是數據中間件，屏蔽了底層RDBMS和NoSQL的區別和複雜性，較容易完成關鍵數據的存儲。

系統發展：第三方業務接入

隨着業務的不斷變化，58幫幫再也不侷限於傳統的IM，而是一個逐步向一個商家綜合移動管理平臺演進，例如接入房產、招聘等業務，提供商家管理功能，進行發帖、刷新、置頂帖子等操做。不少功能，好比招聘、房產等須要在客戶端完成操做和展現。針對這些需求，在原有IM的架構上了調整，主要變化在客戶端APP。

第三方業務接入，因爲和IM業務類型不同，對長鏈接沒有依賴，所以沒必須使用長鏈接，能夠直接在APP經過http調用第三方服務，垂直劃分後，開發效率很是高，第三方業務能夠快速介入，但因爲客戶端與第三方業務耦合太緊，帶來不少兼容性的困難，一旦第三方業務接口發生變更，客戶端就要隨之更新來適配變化，客戶端升級代價很是大，並且不能作到實時更新，好比須要升級時，用戶能夠選擇不升級，這些都會帶來很大的麻煩。

系統成熟：客戶端輕量化

爲解決這個問題，在此基礎上又作了些調整，造成了目前的框架：

主要調整是將客戶端輕量化，將容易變化的部分遷移至服務端，在APP和第三方業務中間加入一層幫幫WebService服務。經過這層業務，較少客戶端與第三方的耦合，即便第三方服務發生變化，客戶端也不受影響。

O2O核心技術解析

對於移動O2O，長鏈接、移動LBS、推送技術都比較重要。

一、推送的主要途徑

推送方面，咱們主要經過如下三個方式來作：

1.1客戶端輪詢（pull）
客戶端按期發起查詢請求，來達到推送的目的。pull的優勢和缺點都很明顯，架構簡單但實時性差，想提升實時性，只能加快查詢頻率，但這會形成電量消耗太高。

1.2短信推送
經過短信發送推送消息，並在客戶端置入短信攔截模塊，將接收到的短信攔截，並解析後轉發給應用處理。這個方案實時性好、到達率高，但成本很高。

1.3服務端長鏈接（push)
這是目前的主流實現方式，實時性好，且電量消耗低。

二、不一樣平臺的實現方案

基本上目前的推送技術都是結合這 3 個方面展開的，但對於不一樣的終端平臺，又有各自不同的實現，這裏簡單介紹一下 IOS 和 android 上的具體實現方案。

2.1 IOS平臺
對於 IOS 來講比較簡單，你沒有別的選擇，由於 IOS 中的應用是不容許後臺常駐的，因此你沒有辦法經過開發本身的 pushservice 來完成推送下發，只能經過蘋果APNS 渠道來完成推送，大體流程以下：

2.2Android 平臺
在 android 平臺上，因爲沒有 IOS 那樣的限制，可選的方案就多一些。你能夠經過谷歌官方的。

C2DM 完成推送，能夠藉助開源的推送協議（例如 XMPP）實現，也能夠藉助市面上的各類推送產品完成推送。

谷歌 C2DM 的主要流程以下：

C2DM 和 APNS 流程相似，但其最大的問題是服務器在國外，很容易被屏蔽，並且因爲 android 社區分裂比較嚴重，不少廠商可能直接就把 C2DM 模塊給去掉了，因此在國內這個方案極不可靠。

對於開源推送協議，常見的有XMPP 等, 事實上谷歌的 C2DM 底層就是基於 XMPP 實現的，咱們經過調用和測試，主要遇到了兩個問題：1. 沒有ACK 機制，消息不可靠。2. 請求量大時會不穩定。

最後就是一些市面上的第三方推送產品了，使用這些產品須要面對幾個問題：

首先是到達率。雖然都宣傳到達率能到 90%及以上，但實際使用起來，發現遠遠不到。

其次是實時性。第三方推送產品的推送通道是共用的，會面向多個客戶，若是某一個客戶推送量特別大，你的推送實時性可能就會受到影響，這些都是你不可控的。

咱們曾經有考慮過本身去實現一套推送方案，若是本身來作的話，要先解決幾個難點。首先是服務端海量長鏈接的管理，而後是客戶端常駐 sevice 的穩定性，手機在內存不足的時候，系統會殺掉你的 service，甚至有些系統比較強勢，它不容許你的 service 常駐，如何在這些複雜場景下處理好，很是麻煩。

綜合上面的一些考慮，58 幫幫目前的推送方案沒有過多的使用自建方案，主要結合多家第三方推送來實現。針對到達率的提高，什麼手機上使用什麼推送產品，這須要去作一些數據分析，而後再作針對性優化。