如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源（幾十篇IM文章）

時間 2019-11-08

標籤如約而至微信自用移動網絡層跨平臺組件 mars 正式開源幾十文章欄目無線简体版

原文原文鏈接

如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源

JackJiang-

發表於 3個月前
閱讀 907
收藏 49
點贊 1
評論 1

【粉絲福利】-《web 前端基礎到實戰系列課程》免費在線直播教學>>> php

摘要: 微信內部正在使用的網絡層封裝庫Mars於2016年12月28日正式公開源碼，Mars開源的意義是可爲IM及相關技術應用領域的同行帶來不少有價值的實踐成果，畢竟微信的體量和應用規模決定了技術的高度，確實是值得同行學習和關注。

一、前言

關於微信內部正在使用的網絡層封裝庫Mars開源的消息，1個多月前就已滿天飛（參見《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》），不過微信團隊沒有失約，微信Mars 於2016年12月28日正式公開源碼（源碼地址：https://github.com/Tencent/mars，也可從本文文末的附件下載之，Android版演示程序能夠從文末的附件中下載）。

以前不管是微信團隊仍是手機QQ團隊，都以騰訊公司的名義在Github開源了數個工程，但這些工程所受的關注度遠不及Mars。之因此Mars廣受關注的緣由，其實搞移動端IM或推送技術的開發者同行都明白，由於移動網絡實在太不可靠、太複雜，以致於寫出一個能用於大規模用戶環境的穩定、省流量、省電、數據傳輸流暢、弱網絡健壯、後臺自動保活等技術指標的IM或推送是至關困難的。

更爲重要的緣由是畢竟微信Mars通過微信團隊多年積累並通過海量用戶的測試和使用，是經受的住各類複雜移動端網絡環境、各類亂七八糟型號智能手機的真實考驗的。若Mars開源，必將爲IM及相關技術應用領域的同行帶來不少有價值的實踐成果，畢竟微信的體量和應用規模決定了技術的高度，確實是值得同行學習和關注。

以前的文章，好比《微信移動端應對弱網絡狀況的探索和實踐PPT》、《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》，也都或多或少對Mars進行了初步介紹，但微信Mars究竟是個啥玩意，它能解決啥問題？

咱們簡要的歸納一下，微信Mars解決了以下問題：html

提供長連、短連兩種網絡通道；
常規的網絡能力，例如 DNS 防劫持、動態 IP 下發、就近接入、容災恢復等；
貼合移動互聯網的網絡層解決方案；
貼合移動終端的平臺特性：先後臺、活躍態、休眠、省電、省流量等。

以上特色，還不盡于歸納微信Mars的技術特徵，建議對C++熟悉的IM或推送技術同行能夠直接去看看Mars源碼。

那麼微信Mars到底有什麼用呢？毫無疑問，微信Mars存在的前提就是爲了更好的服務微信這個超級IM而存在，最適合乾的活就是開發移動端IM了，固然因爲提煉的很好，相信移動端推送技術等都是可使用微信Mars做爲網絡層lib來使用，從而以微信的成果爲起點開發出擁有更加優秀網絡體驗的移動端富網絡應用。

好了，言歸正傳，本文正文內容引用了微信開發團隊的資料，請繼續往下閱讀。（本文同步發佈於：http://www.52im.net/thread-684-1-1.html）前端

二、關聯文章

《移動端IM實踐：實現Android版微信的智能心跳機制》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《微信移動端應對弱網絡狀況的探索和實踐PPT [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》android

三、微信Mars起源

2012 年中，微信支持包括 Android、iOS、Symbian 三個平臺。但在各個平臺上，微信客戶端沒有任何統一的基礎模塊。2012 年的微信正處於高速發展時期，各平臺的迭代速度不1、使用的編程語言各異，後臺架構也處在不斷探索的過程當中。多種因素使得各個平臺基礎模塊的實現出現了差別，致使出現屢次須要服務器作兼容的善後工做。網絡做爲微信的基礎，重要性不言而喻。任何網絡實現的 bug 均可能致使重大事故。例如微信的容災實現，若是由於版本的實現差別，致使某些版本上沒法進行容災恢復，將會嚴重的影響用戶體驗，甚至形成用戶的流失。咱們亟需一套統一的網絡基礎庫，爲微信的高速發展保駕護航。

剛好，這個時候塞班漸入日暮，微信對塞班的支持也逐漸減弱。老大從塞班組抽調人力，組成一個三人小 team 的初始團隊，開始着手作通用的基礎組件。這個基礎組件最初就定位爲：跨平臺、跨業務的基礎組件。如今看，這個組件除了解決了已有問題，還給微信的高速發展帶來了不少優點，例如：git

基礎組件方便了開展專項的網絡基礎研究與優化。
基礎組件爲多平臺的快速實現提供了有力的支持。

通過四年多的發展，跨平臺的基礎組件已經包含了網絡組件、日誌組件在內的多個組件。回頭看，這是一條開荒路。github

四、微信Mars設計原則

在基礎模塊的開發中，設計尤其重要。在設計上，微信基礎組件以跨平臺、跨業務爲前提，聽從高可用，高性能，負載均衡的設計原則。

可用是一個即時通信類 App 的立身之本。高可用又體如今多個層面上：網絡的可用性、 App 的可用性、系統的可用性等。web

網絡的可用性：
移動互聯網有着丟包率高、帶寬受限、延遲波動、第三方影響等特色，使得網絡的可用性，尤爲是弱網絡下的可用性變得尤其關鍵。Mars 的 STN 組件做爲基於 socket 層的網絡解決方案，在不少細節設計上會充分考慮弱網絡下的可用性。
App 的可用性：
App 的可用性包含穩定性、運行性能等多個方面。文章高性能日誌模塊 xlog 描述了 xlog 在不影響 App 運行性能的前提下進行的大量設計思考。
系統的可用性：
除了考慮正常的使用場景，APP的設計還須要從整個系統的角度進行設計思考。例如在容災設計上，Mars 不只使用了服務器容災方案，也設計了客戶端的本地容災。當部分服務器出災時，目前微信能夠作到，15min 內把95%以上的用戶轉移到可用服務器上。

保障高可用並不表明能夠犧牲性能，對於一個用戶使用最頻繁的應用，反而更要對使用的資源精打細算。例如在 Mars 信令傳輸超時設計中，多級超時的設計充分的考慮了可用性與高性能之間的平衡取捨。

若是說高可用高性能只是客戶端自己的考慮的話，負載均衡就須要結合服務器端來考慮了，作一個客戶端網絡永遠不能只把眼光放在客戶端上。任何有關網絡訪問的決策都要考慮給服務器所帶來的額外壓力是多大。爲了選用質量較好的 IP，曾經寫了完整的客戶端測速代碼，後來刪掉，其中一個緣由是由於不想給服務器帶來額外的負擔。Mars 的代碼中，選擇 IP 時用了大量的隨機函數也是爲了規避大量的用戶同時訪問同一臺服務器而作的。

在這四年，我學到最多的就是簡單和平衡。把方案作的儘量簡單，這樣纔不容易出錯。設計方案時大多數時候都不可能知足全部想達到的條件，這個時候就須要去平衡各個因素。在組件中一個很好的例子就是長鏈接的鏈接頻率(具體實現見longlink_connect_monitor.cc)，這個鏈接頻率就是綜合耗電量，流量，網絡高可用，用戶行爲等因素進行綜合考慮的。算法

五、Mars 的發展歷程

5.1 階段1：讓微信跑起來

跨平臺基礎組件的需求起源於微信，首要目標固然是先承載起微信業務。爲了避免侷限於微信，知足跨平臺、跨業務的設計目標，在設計上，網絡組件定位爲客戶端與服務端之間的無狀態網絡信令通道，即交互方式主要包含一來一回、主動push兩種方式。這使得基礎組件無需考慮請求間的關聯性、時序性，核心接口獲得了極大的簡化。同時，簡潔的交互也使得業務邏輯的耦合極少。目前基礎組件與業務的交互只包括：編解碼、auth狀態查詢兩部分（具體見stn_logic.h）。編程

void StartTask(...); int OnTaskEnd(...); void OnPush(...); bool Req2Buf(...); int Buf2Resp(...); bool MakeSureAuthed();

在線程模型的選擇上，最先使用的是多線程模型。當須要異步作一個工做，就起一個線程。多線程勢必少不了鎖。但當灰度幾回以後發現，想要規避死鎖的四個必要條件並無想象中的那麼容易。用戶使用場景複雜，客戶端的時序、狀態的影響因素多，例如網絡切換事件、先後臺事件、定時器事件、網絡事件、任務事件等，致使了很多的死鎖現象和對象析構時序錯亂致使的內存非法訪問問題。

這時，咱們開始思考，多線程確實有它的優勢：能夠併發甚至並行提升運行速度。可是對於網絡模塊來講，性能瓶頸主要是在網絡耗時上，並不在於本地程序執行速度上。那爲什麼不把大部分程序執行改爲串行的，這樣就不會存在多線程臨界區的問題，無鎖天然就不會死鎖。

所以，咱們目前使用了消息隊列的方案(具體實現見 comm/messagequeue 目錄)，把絕大多數非阻塞操做放到消息隊列裏執行。而且規定，基礎組件與調用方之間的交互必須1. 儘快完成，不進行任何阻塞操做；2. 單向調用，避免造成環狀的複雜時序。消息隊列的引入很好的改善了死鎖問題，但消息隊列的線程模型中，咱們仍是不能避免存在須要阻塞的調用，例如網絡操做。在將來的嘗試中，咱們計劃引入協程的方式，將線程模型儘量的簡化。

在其它技術選型上，有時甚至須要細節到API 的使用，好比考慮平臺兼容性問題，捨棄了一些函數的線程安全版本，使用了 asctime、localtime、rand 等非線程安全的版本。安全

5.2 階段2：修煉內功

在屢次的灰度驗證、數據比對下，微信各平臺的網絡邏輯順利的過渡到了統一基礎組件。爲了有效的驗證組件的效果，咱們開發了 smc 的統計監控組件，開始關注網絡的各項指標，進行網絡基礎研究與優化，尤爲是關注移動網絡的特徵。

基礎網絡優化：常規的網絡能力，例如 DNS 防劫持、動態 IP 下發、就近接入、容災恢復等，在這一階段獲得逐步的建設與完善。除此以外，Mars 的網絡模塊是基於 socket 層的網絡解決方案，在缺失大而全的 HTTP 能力的同時，卻能夠將優化作到更細緻，細緻到鏈接策略、鏈接超時、多級讀寫超時、收發策略等每一個網絡過程當中。例如，當遇到弱網絡下連通率較低，或者某些連通率很差的的服務器影響使用時，咱們使用了複合鏈接(代碼見complexconnect.cc)和 IP 排序(代碼見simple_ipport_sort.cc)的方案很好的應對這兩個問題。
平臺特性優化：雖然 Mars 是跨平臺的基礎組件，但在不少設計上是須要結合各平臺的特性的。例如爲了儘可能減小頻繁的喚醒手機，引入了智能心跳（詳見《移動端IM實踐：實現Android版微信的智能心跳機制》），而且在智能心跳中考慮了 Android 的 alarm 對齊特性(具體實現見smart_heartbeat.cc)。再如在網絡切換時，爲了平滑切換的過程，使用了 iOS 中網絡的特性，在 iOS 中作了延遲處理等。
移動特性優化：微信的使用場景大部分是在手機端進行使用，在組件的設計過程當中，咱們也會研究移動設備的特性，並進行結合優化。例如，結合移動設備的無線電資源控制器（RRC）的狀態切換，對一些性能要求特別特別敏感的請求，進行提早激活的優化處理等。

5.3 階段3：「抓妖記」

基礎組件全量上線微信後，以微信的用戶量，固然也會遇到各類各樣的「妖」。例如，寫網絡程序躲不開運營商。印象比較深入的某地的用戶反饋鏈接 WiFi 時，微信不可用，後來 tcpdump 發現，當包的大小超過必定大小後就發不出去。解決方案：在 WiFi 網絡下強制把 MSS 改成1400(代碼見 unix_socket.cc)。

作移動客戶端更避不開手機廠商。一次遇到了一個百思不得其解的 crash，堆棧以下：

#00  pc 0x43e50  /system/lib/libc.so (???)
#01 pc 0x3143 /system/vendor/lib/libvendorconn.so (handleDpmIpcReq+154) #02 pc 0x2f6d /system/vendor/lib/libvendorconn.so (send_ipc_req+276) #03 pc 0x30ff /system/vendor/lib/libcneconn.so (connect+438)

看堆棧結合程序 xlog 分析，非阻塞 socket 卡在了 connect 函數裏超過了6 min, 被咱們自帶的 anr 檢測(代碼見anr.cc)發現而後自殺。最後實在一籌莫展，聯繫廠商一塊兒排查，最終查明緣由：爲了省電，當手機鎖屏時連的不是 WiFi 且又沒有下行網絡數據時，芯片 gate 會關閉，block 住全部網絡請求，直到有下行數據或者超過 20min 纔會放開。當手機有網絡即便是手機網絡的狀況下，很難沒有下行數據，因此基本不會觸發組件自帶的 anr 檢測，但當手機沒鏈接任何網絡時，就很容易觸發。解決方案：廠商修改代碼邏輯，當沒有任何網絡時不 block 網絡請求。

運營商和手機廠商對咱們來講已是一個黑盒，但其實也遇到過更黑的黑盒。當手機長時間不重啓，有極小几率不能繼續使用微信，重啓手機會恢復。但由於一直找不到一個願意配合咱們又知足條件的用戶，致使這個問題很長一段時間內都沒有任何進展，最終偶然一個機會，在一臺測試機器上重現了該問題，tcpdump 發如今三步握手階段，服務器帶回的客戶端帶過去的 tsval 字段被篡改，致使三步握手直接失敗，並且這個篡改發生在離開服務器以後到達客戶端以前。

這個問題是微信網絡模塊中排查時間最長也是花費精力最多的一個問題，不只由於很長一段時間內無案例可分析，也由於在重現後，聯繫了大量的同事和外部有關人的幫忙，想排查出罪魁禍首。但由於中間涉及的環節和運營商相關部門過多，沒法繼續排查下去，最終也沒找到根本緣由。解決辦法：服務器更改 net.ipv4.tcp_timestamps = 0。

這段時間是痛並快樂着，見識到了各類極差的網絡，才切膚感覺到移動網絡環境的惡劣程度，但看着咱們的網絡性能數據在穩步提高又有種知足感。截止到今天，已經不多有真正的網絡問題須要跟進了。這也是咱們能有時間開始把這些代碼開源出去的很大的一個緣由。

六、爲了更好地開源Mars，微信團隊作了這些前期工做

大概一年前（大約2015年10月），咱們開始有想法把基礎組件開源出去，當時你們都在糾結叫什麼名字好呢？此時恰逢《火星救援》正在熱映，一位同事說乾脆叫 Mars 吧，因而就定下來叫了 Mars。看了看代碼，發現想要開源出去可能仍是須要作一些其餘工做的。

6.1 代碼重構

首先，代碼風格方面，由於最初咱們使用文件名、函數名、變量名的規則是內部定義的規則，爲了能讓其餘人讀起來更舒心，咱們決定把代碼風格改成谷歌風格，好比：變量名一概小寫, 單詞之間用下劃線鏈接；左大括號不換行等等。可是爲了更好的區分訪問空間，咱們又在谷歌代碼風格進行了一些變通，好比：私有函數所有是」__」開頭；函數參數所有以」_」開頭等等。

其次，雖然最初的設計一直是秉承着業務性無關的設計，但在實際開發過程當中仍然不免帶上了微信的業務性相關代碼，比較典型的就是 newdns 。爲了 Mars 之後的維護以及保證開源出去代碼的同源，在開源出去以前必須把這些業務性有關的代碼抽離出來，抽離後的結構以下：

mars-open 也就是要開源出去的代碼，獨立 git repo。
mars-private 是可能開源出去的代碼，依賴 mars-open。
mars-wechat 是微信業務性相關的代碼，依賴 mars-open 和 mars-private。

最後，爲了接口更易用，對調用接口以及回調接口的參數也進行了反覆思考與修改。

6.2 編譯優化

在 Mars以前，是直接給 Android 提供動態庫(.so)，由於代碼邏輯都已經固定，不須要有可定製的部分。給 Apple 系平臺提供靜態庫(.a)，由於對外暴露的函數幾乎不會改變，直接把相應的頭文件放到相應的項目裏就行。但對外開源就徹底不同了：日誌的加密算法可能別人須要本身實現；長連或者短連的包頭有人須要本身定製；對外接口的頭文件咱們可能會修改……

爲了讓使用者可定製代碼，對於編譯 Android 平臺咱們提供了兩種選擇：

1. 動態庫。有些可能須要定製的代碼都提供了默認實現。
2. 先編譯靜態庫，再編譯動態庫。

編譯出來靜態庫後，實現本身須要定製的代碼後，執行 ndk-build 後便可編譯出來動態庫。對於 Apple 系平臺，把頭文件所有收攏爲 Mars 維護，直接編譯出 Framework。

爲了能讓開發者快速的入門，咱們提供了 Android、iOS、OS X 平臺的 demo（微信開源Mars的Demo源碼點此進入），其餘平臺的編譯和 demo 會在不久就加上支持。

▲ 成型的 Mars 結構圖如上圖所示

6.3 同類技術橫向對比

咱們作的一直都不是知足全部需求的組件，只是作了一個更適合咱們使用的組件，這裏也列了下和同類型的開源代碼的對比。

能夠看出：

Mars 中包括一個完整的高性能的日誌組件 xlog；
Mars 中 STN 是一個跨平臺的 socket 層解決方案，並不支持完整的 HTTP 協議；
Mars 中 STN 模塊是更加貼合「移動互聯網」、「移動平臺」特性的網絡解決方案，尤爲針對弱網絡、平臺特性等有不少的相關優化策略。

總的來講，Mars 是一個結合移動 App 所設計的基於 socket 層的解決方案，在網絡調優方面有更好的可控性，對於 HTTP 完整協議的支持，已經考慮後續版本會加入。

6.4 Mars開源源碼結構

▲ 截止2016年12月28日微信Mars的開源工程代碼結構

七、獲取Mars的演示Demo（Sample）

7.1 下載和安裝

試用 Android Demo 請從文末的附件下載之，iOS sample 請經過 Mars的Github倉庫編譯得到（或文末的附件下載源碼）。

7.2 Mars Android版演示程序截圖

7.3 Mars iOS版演示程序源碼截圖

八、本文小結

常常有朋友和我說：發現網絡信號差的時候或者其餘應用不能用的時候，微信仍然能發出去消息。不知不覺咱們好像什麼都沒作，回頭看，原來咱們已經作了這麼多。

我想，並非任何一行代碼均可以經歷日活躍5億用戶的考驗，感謝微信給咱們提供了這麼一個平臺。如今咱們想把這些代碼和大家分享，運營方式上 Mars 所開源出去的代碼會和微信所用的代碼保持同源，全部開源出去的代碼也首先會在微信上驗證經過後再公開。

開源並非結束，只是開始。咱們後續仍然會繼續探索在移動互聯網下的網絡優化。Talk is cheap，show you our code。

（本文同步發佈於：http://www.52im.net/thread-684-1-1.html，本文引用了微信團隊原創文章：原始文字點此進入）