前沿拓展：

網絡移動經紀人登錄

登錄電腦版網絡經紀人首頁最下面可以查看。
安居客移動經紀人看客戶對自己的評價方式：登錄電腦版網絡經紀人首頁最下面可以看到客戶給自己的評價。同時一個合格的經紀人需要做到以下條件：
1、成功經紀人每天準時到公司，最好能提前20分鐘到公司，做到風雨無阻。
2、找開電腦，查看前一天所新增樓盤，熟悉市場行情，養成每天背誦樓盤信息的習慣。
經紀人入門容易，做精難。底薪低，提成高。好的經紀人每月上萬很正常，但是剛進入這行會有好長時間只拿底薪的日子，等到客戶積累到質變的時候日子就好過了。

12月1日，由58同城攜手騰訊云聯合舉辦的第2期即時通訊技術沙龍專場在望京科技園順利舉行。來自阿里、騰訊、美團等160多位技術大牛參與本次活動，現場火爆到工作人員都沒地坐。值得一提的是本次活動聯合58部落，在“碼農俱樂部”進行圖文直播，受到廣大技術愛好者的好評。相比第1期，活動報名人數和到場率都有了非常大的增長，今天我們就來還原現場，干貨全盤輸出！來一張現場大佬們合影照片鎮樓！

本次沙龍活動的議題如下：

《58 同城面向億級用戶 IM 長連接服務設計與實踐》

《IM 消息存儲及多端同步的架構與設計》

《58 同城 APP 中基于 IM SDK 的應用實踐》

《基于音視頻的騰訊云網絡創新實踐》

《實時音視頻的架構設計與調優實踐》

干貨精選許剛：58同城移動端架構師

干貨分享：《58 同城面向億級用戶 IM 長連接服務設計與實踐》

58同城是全國最大的分類信息平臺。我們有大量的C端用戶，包括58同城，安居客，58部落。我們有大量B端商家，包括移動經紀人，招才貓，二手車，商家通等等。作為全連接戰略的重要部分的即時通訊服務，在內部也叫微聊，為我們的用戶和商家提供了一個便捷的溝通渠道。我們服務的用戶量達到了上億級別。長連接服務作為即時通訊的核心能力之一。長連接服務的背后連接著消息服務，用戶服務，群組服務，幫幫服務。長連接的前面通過負債均衡TGW之后連接著Android設備，iOS設備，Web瀏覽器，PC應用程序。在這樣場景的情況下，必然要求長連接服務需要做到高性能高并發，需要做到兼容多個平臺端，需要做到連接穩定可靠。

高性能高并發

設計評估：

1.核心功能： 建立長連接，保持長連接在線，能夠收發即時通訊消息。提供穩定可靠的連接服務。

2.CPU使用評估：充分使用機器的CPU資源，移動設備，Web瀏覽器建立連接和斷開連接比較頻繁，CPU負責建立連接的線程負載高。用戶活躍，收發巨量消息的時候，需要用到CPU資源多。

3.內存使用評估：保持大量用戶在線，每個用戶需要一個session存儲，需要用到大量內存。用戶活躍，收發巨量消息，每個用戶都需要數據緩存，需要使用大量內存。

設計目標：

1.一臺機器處理盡量多連接數

2.為線程合理分配任務，CPU資源充分使用

3.設計較好的數據結構，合理分配內存

Socket**和管理的線程模型設計：

1.單線程**模型：全局建立一個單線程socket listener，每當**到新的socket連接時分配給一個工作線程進行處理。

如圖所示，這是一個典型的單線程長連接設計模型，使用單線程處理連接，在移動App，Web頁面建立和斷開場景連接較多的情況下，單線程socket處理listener將成為瓶頸，在大量連接并發的情況下，容易丟失socket。

2.多線程**模型

所有工作線程**同一個socket，當有一個新的連接建立時，所有的工作線程去競爭accept此socket，只有一個工作線程會成功，其他的會失敗，等待下一個連接的喚醒。該模型的優點是能夠充分利用多線程的優勢提高服務的響應速度。

同時該模型的存在缺點也很突出：（1）采用競爭方式獲取連接，導致線程間資源分配不均衡。（2）存在驚群問題，新連接到達時所有工作線程都被喚醒，但是只有一個線程能夠成功獲取到任務，其他線程獲取任務失敗后繼續休眠，每次喚醒會造成系統資源的浪費；（3）在負載較高時，線程處理任務延時比較大。

3.全線程**模型

針對上述問題，我們對多線程模型進行優化。

1） 從線程考慮，根據物理機的內核配置，確定最優的線程數，充分利用CPU；

2） 每個打開的fd均勻分配到各個線程。**作系統在分配fd資源時是以遞增的方式分配的，這樣我們采用fd%線程數的方式將fd均勻分配到各個工作線程實現各個工作線程的負載均衡；

3）優化socket的**方式。我們使用全線程**模式，每一個線程創建一個套接字，多個套接字 bind()/listen() 同一個TCP/UDP端口。這種方式避免了單線程**的方式**線程負載過高；也避免了使用全部線程**的方式時線程搶占命中率低的問題。

4）驚群問題的優化：經過優化的多線程**方式仍然存在著前文提到的驚群問題，在建立socket連接時多個**線程依舊會被同時喚醒。針對這個問題，我們使用Linux的端口復用技術（SO_REUSEPORT），為每個工作線程生成建立一個套接字對象，這些套接字可以同時綁定（bind），**（listen）同一個TCP/UDP端口，這樣多個工作線程在socket**上便不存在對性能有較大影響的多線程鎖競爭，同時，系統在內核層面實現了連接的負載均衡。

至此，通過這樣的設計，我們實現了對線程資源的充分利用。

有關“線程間高效通訊”、“內存管理”等更多精彩內容點擊“閱讀原文”查找《58 同城面向億級用戶 IM 長連接服務設計與實踐》進行查看

張輝：58同城后端架構師

干貨分享：《IM 消息存儲及多端同步的架構與設計》

58IM即時通訊作為互聯網時代重要的溝通方式，有著不可替代的作用，58同城IM——微聊，作為58平臺的即時通訊服務，為58各業務提供了即時溝通的能力。

單聊消息存儲：

傳統IM系統，因為不涉及多端的問題，也不用考慮客戶端的存儲能力，存儲時更多的只是專注離線消息存儲即可；但現代IM系統，因為涉及多端，存儲設計時，必須要考慮到消息的多端同步，還要考慮到web、小程序這樣沒有存儲能力的端，對服務端的存儲就有了更高的要求。因為涉及多端，所以在存儲時會涉及擴散問題，在方案上，就面臨是讀擴散還是寫擴散兩種選擇。

首先簡單介紹下寫擴散方案，這種方案下，需要給每個用戶每個端設置一個收件箱，按順序存儲用戶收到的消息列表，在發消息時，除了要把消息寫入接收方每個端對應的收件箱外，為了解決發送方多端同步的問題，還需要寫入發送方發消息之外的端的收件箱，一條消息要寫入多次，但每個端都只是在自己的收件箱內讀取消息，所以說這是一種寫擴散的方式。

寫擴散方案最大的好處就是消息同步比較簡單，端上接收消息只需要去對應的收件箱取就好了，但存儲空間比較浪費，發一條消息要寫多次，數據庫寫壓力也比較大，同時，因為消息是不區分會話，按順序存儲的，那么消息量大的時候，獲取歷史消息只能按消息順序回溯，不能按會話獲取，有一定的局限性。

下面再簡單介紹下讀擴散方案，這種方案下，消息按會話存儲，每個會話存儲一份消息列表，會話雙方共享這一份消息數據，多個會話就需要存儲多個消息列表，端上接收消息時，要查詢每個消息列表是不是有新消息，但一般情況下，大部分會話是沒有新消息的，所以有很多查詢是無效的。

讀擴散方案最大的好處是節約磁盤空間，最大化利用存儲，同時獲取歷史消息也可以按會話獲取，效率比較高；但消息同步邏輯相對寫擴散要復雜很多，還有很多無效查詢。

在讀擴散還是寫擴散的選擇上，一般來說IM是典型的一寫多讀場景，適合寫擴散。但在58的業務場景下，涉及業務比較多，多個業務都有多端登錄的需求，同一賬號可能會在幾十個端上登錄，擴散要比一般的IM產品嚴重的多，并不適合采用寫擴散的方式；而且58自研的Wtable分布式數據庫讀的性能要遠高于寫的性能，所以我們選擇了讀擴散的方案。

1.每個會話存儲一份消息列表，消息id全局遞增

2.每個用戶存儲一份會話列表，會話記錄該會話最后一條消息id，按消息id有序存儲

3.寫消息同時更新雙方會話

4.通過讀會話列表判斷會話是否有新消息

因為Wtable是KV存儲，消息列表的key設計成會話id，只有消息列表沒辦法根據用戶ID索引到具體的消息，所以還需要給每個用戶建立一個會話列表，用來索引每個會話對應的消息列表；同時因為Wtable每個key對應的列表天然支持有序，只要我們保證消息id是全局遞增，就可以保證消息列表有序的同時，會話列表也可以按照會話的最后一條消息排序，只是存儲消息時除了更新消息列表，還需要更新會話雙方的會話列表，以保證會話的順序；同時因為會話里存儲了最后一條消息的id，前端讀取會話列表后，就能判斷該會話有沒有新消息。

群消息存儲：

群消息和單聊消息相比，最大的區別就是擴散范圍更大了，單聊消息只涉及會話的雙方，而群聊會涉及成千上萬的群成員，所以群聊的存儲方案也確定為讀擴散，如下圖所示：

在介紹單聊的時候我們介紹過，因為存儲系統的原因，需要存儲一份會話列表作為消息的索引，同時會話列表里存儲了會話最后一條消息的消息id，因此存儲消息的同時，需要更新消息雙方的會話列表；在群聊的場景下，會話不在只涉及雙方，而是所有群成員，因此需要更新所有群成員的會話列表，導致了寫擴散的問題。

為了解決群聊更新會話類表寫擴散的問題，我們給每個群單獨設計了一個群會話，專門用來存儲會話的最后一條消息，這樣存儲消息時只需要更新群會話，不需要去更新全部群成員的會話列表了，群成員在取會話列表時，再來讀取群會話中的消息id，補充到會話列表中；通過這樣一種把寫擴散變成讀擴散的方式，解決了這個問題。

但這樣又會引入新的問題，剛才介紹單聊存儲是說過，會話列表是有序的，而且就是按會話里存儲的最后一條消息的消息id排序的，如果存儲消息時不更新會話列表，那會話的排序就不會改變，所以我們又做了以下機制解決這個問題：

1.用戶獲取會話列表時，補充群會話中的消息id，然后對會話列表重新排序；

2.單聊、群聊會話分開存儲，排序時只處理群聊會話，取會話列表時合并兩種會話；

3.異步、延遲更新群會話列表，每隔一段時間，異步更新一次群會話列表，保證活躍群會話一定排在前面，這樣排序時就可以不用全量排序所有群會話；

最終，在解決群聊會話寫擴散問題的同時，也能保證用戶能夠及時獲取會話的變更信息。

消息同步機制：

所謂消息同步，簡單來說就是讓消息通過一定的機制，到達客戶端，讓接收方能看見。

我們可以看下上面這張圖，圖片中的在線推送，就是最基本的一種同步機制，可以保證在線的時候把消息推送給接收方，但接受方離線時產生的消息，又是怎么同步的呢，下面我們來詳細介紹。

上面介紹消息存儲時，我們也簡單提到過，在讀擴散的方案下，用戶的會話列表中存儲了最后一條消息的id，用戶需要通過獲取會話列表的消息id，就能判斷該會話是不是有新消息，所以我們同步消息之前，首先要同步會話列表。客戶端想要獲取會話列表，無外乎兩種方式，要么服務端推，要么客戶端拉，但這兩種方式都有個問題需要解決，就是兩端信息不對稱，雙方都不知道需要推或者拉多少，如果推或者拉全量，那就太浪費資源了，所以需要有一個信息同步的過程；所以我們采用了客戶端帶上信息拉取的方案，客戶端拉會話列表的同時，帶上本身已經存在的會話信息，服務端根據客戶端當前已有會話情況，選擇下發客戶端需要的會話。同步會話列表除了客戶端主動拉取之外，我們還做了一個小的優化，就是在客戶端首次登陸沒有任何信息的情況下，服務端主動下發會話列表，這樣可以保證客戶端啟動時盡快展示會話列表，同時也不會造成資源浪費。

同步完會話列表之后，就需要同步消息了，客戶端拿到會話列表里最后一條消息的信息后，首先需要根據這條消息判斷，本地消息列表是不是完整的，還需不需要去服務端拉取完整消息列表；這里我們設計了這樣一種機制，把消息列表串成了一個鏈表，每條消息都有一個屬性，用來記錄上一條消息的id，如果客戶端讀到一條消息，發現他的上一條消息本地沒有，那就可以肯定，需要去服務端拉取了。通過這種機制我們不光解決了是不是有新消息到達的問題，還可以解決其他任何情況導致的客戶端消息不完整問題，可以說無論何種情況，只要客戶端缺少消息，都可以通過這種機制判斷出來，然后拉取服務端消息補充完整。同樣的客戶端拉取消息，也是帶上現有消息信息，服務端發現客戶端消息已經存在，則不再下發。

消息列表串成鏈表這種機制，確實解決了客戶端判斷消息完整性的問題，但同時也帶來了新的問題，在并發場景下，如果兩條消息同時發送，那兩條消息存儲的上一條消息id，可能會寫成同一個，這樣就導致鏈表不完整，為了解決這個問題，我們采用了動態建立鏈表的機制。上面講存儲的時候，我們說過消息列表是有序存儲的，那既然已經是有序的了，我們就沒有必要實際記錄一份鏈表的關系，完全可以在獲取消息列表的同時，動態構建鏈表關系，這樣只要我們通過一定的事務機制，保證會話列表里存儲的消息id一定是會話里最大的，就可以通過這樣動態建立的方式，解決并發問題。

最終我們的消息同步方案是這樣的：

1.用戶在線，實時推送消息

2.用戶首次登陸，推送會話列表

3.非首次登陸，帶上客戶端會話信息，按需拉取會話列表

4.消息有序存儲，客戶端通過鏈表機制判斷消息完整性，按需拉取

微聊消息存儲因為業務的特殊性，不同于一般的IM設計，采用了讀擴散的方案，結合我們存儲的特點，設計了一系列的方案解決消息同步問題，雖然這里很多問題是我們存儲系統特有的，但是解決問題的思路是通用的，希望讀者在自身業務上也可以得到些啟發。

**：58同城客戶端架構師

干貨分享：《58 同城 APP 中基于 IM SDK 的應用實踐》

背景：

目前IM即時通信對于各大應用來說都是重要的功能部分，而且地位較高，線上溝通，可提高用戶體驗和APP的活躍度、流量，58也是對IM系統相當重視，承載各個業務線用戶的線上溝通，為了給用戶更好的IM體驗，我們對IM做了很深入的研發，包括公司內部的IM體系自研底層SDK和server服務，功能優化和版本迭代。將IM模塊模塊的框架和近期為面向并行研發IM功能實現方案、項目經驗和遇到的問題及解決方案跟大家分享一下。

IM功能模塊的框架：

介紹IM功能模塊的框架之前先講一下早期IM功能的情況和問題

早期IM是由**平臺開發維護，IM功能實現不完善，消息類型少，只有文本和語音，不支持音視頻通話，消息無漫游，同一個賬戶在夸端登陸時會出現消息無法同步到新登陸的終端上，IM作為重要的功能和主框架耦合嚴重，未統一底層服務，未實現SDK化。

早期IM也出現了一些問題，主要表現在4個方面：

1)層級結構，層級結構不清晰，類的功能職責不明確，代碼邏輯相互耦合嚴重；

2)維護擴展，可維護和擴展性差，代碼邊界不清楚，開發維護成本高，部分功能在實現擴展方面較差，如消息協議，添加新的類型實現成本高；

3)問題排查，問題多，排查難，代碼邏輯經過長時間的迭代后出現交叉依賴，難以梳理，問題難以修復；

4)基礎邏輯，客戶端和PC端的基礎邏輯存在不一致的情況，跨端問題很難**，部分需求實現不對齊；

近期公司中臺為提高IM功能的質量，搭建了即時通信服務，統一IM的實現，為各業務子公司提供基礎服務，面向客戶端應用開發了IM SDK（微聊 SDK），隨后58同城APP中集成了這套IM 服務體系，在此基礎服務上開發IM相關功能，這其中遇到了一些問題和大家分享一下，并講一下我們的解決方案。

現IM功能模塊基于微聊 SDK的框架設計采用經典的三層設計架構，包括表現層、業務邏輯層、數據訪問層。

結合框架的使用，在以下的分析講解中會分層說明在項目中的作用；

I.表現層

1）IM相關界面的邏輯，IM數據展示和界面**作交互；

2） 功能模塊化，UI界面區分出消息列表、會話列表、用戶連接狀態、消息未讀數、帖子信息展示等功能；

II. 業務邏輯層

1）具體的**作邏輯，對表現層提供接口調用，鏈接數據訪問層，承上啟下；

2）用戶輸入的數據通過業務邏輯層的處理發給中間層；數據層返回的數據通過業務邏輯層發送給界面展示；

3）接口單一職責、易于業務邏輯維護；

該層為核心邏輯層，設計成兩部分：

A）主要邏輯管理類組和API接口，按IM主要功能設計管理類，處理表現層需要的邏輯處理；B）轉換功能，主要職能是數據轉換、加密、數據緩存等，數據轉換的設計是為讓表現層隔離IM SDK的數據類，將IM SDK有自己的消息bean類轉換為我們自己的bean類，已到達上層與SDK的隔離，這樣升級SDK或替換SDK，對上層無影響；

III．數據訪問層

數據來源層，IM SDK為我司自研的IM 體系微聊SDK、路由庫、網絡庫；

分層架構實施后的優點

介紹一下業務邏輯層核心邏輯的設計

將IM的核心邏輯抽象了一個統一的入口類IMClient，作為IM功能的代表，包含多個業務邏輯管理類成員變量，與上層交互統一使用此類交互，調用方便簡單，可讀性**作性高，縮短API的學習時間，先將場景羅列，再抽象，明確管理類的職責，使管理類易維護可擴展，有利于單元測試。

音視頻通話的設計是底層服務采用我們公司開發的音視頻通話WRTC SDK庫，封裝管理類WRTCManager,用于管理和對接音視頻功能，音視頻通話界面包括4個View，音頻通話邀請/接通，視頻通話邀請/接通，以狀態驅動界面的展示和邏輯，音視頻通話界面可以切換音頻通話界面，可通過管理類**作WRTC庫服務API。

有關“面向并行研發的IM功能實現方案”“思考與總結”等內容可以 點擊“閱讀原文”找到《58同城APP中基于IM SDK的應用實踐》詳細閱讀

王劍飛：58同城資深架構師

干貨分享：《實時音視頻的架構設計與調優實踐》

WRTC是58同城TEG架構平臺線為58各業務線提供的實時音視頻通話解決方案，幫助業務線快速實現音視頻通話及IP電話能力。在如今的網絡環境下，58很多業務場景都有音視頻通信的需求，比如IM場景，除了文字交流還需要音視頻通話進行實時交互。WRTC能幫助58、安居客等業務線更好的為用戶提供服務，節約溝通成本，提升效率，實現App客戶端與Web端、小程序客戶端、移動電話之間互相通話的功能。

客戶端SDK：

這一部分是WRTC面向iOS、Android所提供的接入SDK，在工程架構上分為3個模塊：（1）WebRTC基礎能力模塊，由TEG在開源軟件WebRTC基礎上改造而來，是WRTC客戶端實踐的核心功能，主要實現了音視頻的采集、視頻**處理、視頻編解碼、信息傳輸、傳輸質量控制等功能；（2）WRTC通話管理模塊，這一部分是對通話流程的抽象，包括房間管理、信令管理和狀態管理，方便從邏輯層控制通話流程；（3）WRTC客戶端API模塊，該模塊是WRTC向客戶端提供的調用入口，對（1）（2）模塊的功能進行了業務化封裝，調用方只需要關心業務邏輯的實現和調用，無需過多關注通話功能的代碼細節。

WRTC服務：

WRTC服務端包括媒體轉換單元SFU、協議轉換服務(SIP)、房間服務、STUN服務、信令服務、Nginx-RTMP等模塊。WRTC中主要處理兩部分數據，即信令和媒體。信令的處理是為了服務媒體通信，在一對一音視頻通話中，有房間ID的概念，即是每一個房間只有兩方，主叫和被叫。所以信令的邏輯主要包括房間狀態的管理，媒體的信息與主被叫的綁定關系。在整體架構中，這部分的處理由信令服務和房間服務共同完成；房間服務通過同時控制SFU進行媒體的中轉；協議轉換服務主要負責WebRTC的協議和SIP協議的轉換,完成App/Web瀏覽器到電話的IP電話能力；Nginx-RTMP模塊主要實現推拉流的地址的分配。通過自研的媒體轉換進行RTMP和RTP的轉換，完成App/Web瀏覽器和小程序之前的媒體通信。在整體實踐中，WRTC分別從SDK包壓縮、首幀時間、網絡結構、弱網對抗、丟包處理上做了大量的優化工作，對通話質量有了一定的程度的提升。在新技術的結合實踐中，音視頻服務積極擴展了VR帶看功能，持續為業務賦能，效果如下圖。

除了一對一音視頻外，擴展了多人音視頻的能力。最多支持9人同時在線。并在此基礎上通過和直播服務的結合提供了互動直播的能力。統一提供了一套一對一音視頻、IP電話、多人音視頻、直播、互動直播在內的完整的58視頻生態。

現場活動精美照我們也來分享一波：

關注【58技術】微信公眾號，掌握更多優質一手干貨

保存相冊——微信掃一掃即可關注

拓展知識：

網絡移動經紀人登錄

安居客**網絡經紀人登錄首先需要進入安居客主頁面，然后右上角有個**網絡經紀人，點擊進去之后出現經紀人登錄界面。具體步驟如下：

找到安居客的官方網站。

點擊右上角的**網絡經紀人。

點擊進去之后就可以進行登錄。

本回答被網友采納