默認
打賞 發表評論 8
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
閱讀(52997) | 評論(8 收藏13 淘帖2 1

前言


微信于2013年開源的ibco庫,是微信后臺大規模使用的c/c++協程庫,2013年至今穩定運行在微信后臺的數萬臺機器上。libco在2013年的時候作為騰訊六大開源項目首次開源,ibco支持后臺敏捷的同步風格編程模式,同時提供系統的高并發能力。

有關開發libco的背后故事,請見文章《微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案》。

libco支持的特性


libco主要特性:

  • 無需侵入業務邏輯,把多進程、多線程服務改造成協程服務,并發能力得到百倍提升;
  • 支持CGI框架,輕松構建web服務(New);
  • 支持gethostbyname、mysqlclient、ssl等常用第三庫(New);
  • 可選的共享棧模式,單機輕松接入千萬連接(New)。

libco完善簡潔的協程編程接口:

  • 類pthread接口設計,通過co_create、co_resume等簡單清晰接口即可完成協程的創建與恢復;
  • 類__thread的協程私有變量、協程間通信的協程信號量co_signal (New);
  • 非語言級別的lambda實現,結合協程原地編寫并執行后臺異步任務 (New);
  • 基于epoll/kqueue實現的小而輕的網絡框架,基于時間輪盤實現的高性能定時器。

libco產生的背景


早期微信后臺因為業務需求復雜多變、產品要求快速迭代等需求,大部分模塊都采用了半同步半異步模型。接入層為異步模型,業務邏輯層則是同步的多進程或多線程模型,業務邏輯的并發能力只有幾十到幾百。隨著微信業務的增長,系統規模變得越來越龐大,每個模塊很容易受到后端服務/網絡抖動的影響。

異步化改造的選擇


為了提升微信后臺的并發能力,一般的做法是把現網的所有服務改成異步模型。這種做法工程量巨大,從框架到業務邏輯代碼均需要做一次徹底的改造,耗時耗力而且風險巨大。于是我們開始考慮使用協程。

但使用協程會面臨以下挑戰:

  • 業界協程在c/c++環境下沒有大規模應用的經驗;
  • 如何控制協程調度;
  • 如何處理同步風格的API調用,如Socket、mysqlclient等;
  • 如何處理已有全局變量、線程私有變量的使用。

最終我們通過libco解決了上述的所有問題,實現了對業務邏輯非侵入的異步化改造。我們使用libco對微信后臺上百個模塊進行了協程異步化改造,改造過程中業務邏輯代碼基本無修改。至今,微信后臺絕大部分服務都已是多進程或多線程協程模型,并發能力相比之前有了質的提升,而libco也成為了微信后臺框架的基石。

libco框架技術架構圖


libco在框架分為三層,分別是接口層、系統函數Hook層以及事件驅動層。

開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]_1.png

libco對同步風格API的創新處理


對于同步風格的API,主要是同步的網絡調用,libco的首要任務是消除這些等待對資源的占用,提高系統的并發性能。一個常規的網絡后臺服務,我們可能會經歷connect、write、read等步驟,完成一次完整的網絡交互。當同步的調用這些API的時候,整個線程會因為等待網絡交互而掛起。

雖然同步編程風格的并發性能并不好,但是它具有代碼邏輯清晰、易于編寫的優點,并可支持業務快速迭代敏捷開發。為了繼續保持同步編程的優點,并且不需修改線上已有的業務邏輯代碼,libco創新地接管了網絡調用接口(Hook),把協程的讓出與恢復作為異步網絡IO中的一次事件注冊與回調。當業務處理遇到同步網絡請求的時候,libco層會把本次網絡請求注冊為異步事件,本協程讓出CPU占用,CPU交給其它協程執行。libco會在網絡事件發生或者超時的時候,自動的恢復協程執行。

大部分同步風格的API我們都通過Hook的方法來接管了,libco會在恰當的時機調度協程恢復執行。

libco達到千萬級協程的支持


libco默認是每一個協程獨享一個運行棧,在協程創建的時候,從堆內存分配一個固定大小的內存作為該協程的運行棧。如果我們用一個協程處理前端的一個接入連接,那對于一個海量接入服務來說,我們的服務的并發上限就很容易受限于內存。為此,libco也提供了stackless的協程共享棧模式,可以設置若干個協程共享同一個運行棧。同一個共享棧下的協程間切換的時候,需要把當前的運行棧內容拷貝到協程的私有內存中。為了減少這種內存拷貝次數,共享棧的內存拷貝只發生在不同協程間的切換。當共享棧的占用者一直沒有改變的時候,則不需要拷貝運行棧。

開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]_2.png

libco協程的共享協程棧模式使得單機很容易接入千萬連接,只需創建足夠多的協程即可。我們通過libco共享棧模式創建1千萬的協程(E5-2670 v3 @ 2.30GHz * 2, 128G內存),每10萬個協程共享的使用128k內存,整個穩定echo服務的時候總內存消耗大概為66G。

libco協程級私有變量


多進程程序改造為多線程程序時候,我們可以用__thread來對全局變量進行快速修改,而在協程環境下,我們創造了協程變量ROUTINE_VAR,極大簡化了協程的改造工作量。

因為協程實質上是線程內串行執行的,所以當我們定義了一個線程私有變量的時候,可能會有重入的問題。比如我們定義了一個__thread的線程私有變量,原本是希望每一個執行邏輯獨享這個變量的。但當我們的執行環境遷移到協程了之后,同一個線程私有變量,可能會有多個協程會操作它,這就導致了變量沖入的問題。為此,我們在做libco異步化改造的時候,把大部分的線程私有變量改成了協程級私有變量。協程私有變量具有這樣的特性:當代碼運行在多線程非協程環境下時,該變量是線程私有的;當代碼運行在協程環境的時候,此變量是協程私有的。底層的協程私有變量會自動完成運行環境的判斷并正確返回所需的值。

協程私有變量對于現有環境同步到異步化改造起了舉足輕重的作用,同時我們定義了一個非常簡單方便的方法定義協程私有變量,簡單到只需一行聲明代碼即可。

libco的gethostbyname Hook方法介紹


對于現網服務,有可能需要通過系統的gethostbyname API接口去查詢DNS獲取真實地址。我們在協程化改造的時候,發現我們hook的socket族函數對gethostbyname不適用,當一個協程調用了gethostbyname時會同步等待結果,這就導致了同線程內的其它協程被延時執行。我們對glibc的gethostbyname源碼進行了研究,發現hook不生效主要是由于glibc內部是定義了__poll方法來等待事件,而不是通用的poll方法;同時glibc還定義了一個線程私有變量,不同協程的切換可能會重入導致數據不準確。最終gethostbyname協程異步化是通過Hook __poll方法以及定義協程私有變量解決的。

gethostbyname是glibc提供的同步查詢dns接口,業界還有很多優秀的gethostbyname的異步化解決方案,但是這些實現都需要引入一個第三方庫并且要求底層提供異步回調通知機制。libco通過hook方法,在不修改glibc源碼的前提下實現了的gethostbyname的異步化。

libco定義了協程信號量的概念


在多線程環境下,我們會有線程間同步的需求,比如一個線程的執行需要等待另一個線程的信號,對于這種需求,我們通常是使用pthread_signal 來解決的。在libco中,我們定義了協程信號量co_signal用于處理協程間的并發需求,一個協程可以通過co_cond_signal與co_cond_broadcast來決定通知一個等待的協程或者喚醒所有等待協程。

libco技術小結


libco是一個高效的c/c++協程庫,提供了完善的協程編程接口、常用的Socket族函數Hook等,使得業務可用同步編程模型快速迭代開發。隨著幾年來的穩定運行,libco作為微信后臺框架的基石發揮了舉足輕重的作用。

源碼打包下載


libco-20161207snapshot(52im.net).zip (42.39 KB , 下載次數: 22 , 售價: 1 金幣)

最新源碼地址


https://github.com/52im/libco

附錄1:全站精品資源下載


[1] 精品源碼下載:
輕量級即時通訊框架MobileIMSDK的iOS源碼(開源版)[附件下載]
開源IM工程“蘑菇街TeamTalk”2015年5月前未刪減版完整代碼 [附件下載]
微信本地數據庫破解版(含iOS、Android),僅供學習研究 [附件下載]
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰 [附件下載]
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰 [附件下載]
NIO框架入門(二):服務端基于MINA2的UDP雙向通信Demo演示 [附件下載]
NIO框架入門(一):服務端基于Netty4的UDP雙向通信Demo演示 [附件下載]
用于IM中圖片壓縮的Android工具類源碼,效果可媲美微信 [附件下載]
高仿Android版手機QQ可拖拽未讀數小氣泡源碼 [附件下載]
一個WebSocket實時聊天室Demo:基于node.js+socket.io [附件下載]
Android聊天界面源碼:實現了聊天氣泡、表情圖標(可翻頁) [附件下載]
高仿Android版手機QQ首頁側滑菜單源碼 [附件下載]
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
分享java AMR音頻文件合并源碼,全網最全
微信團隊原創Android資源混淆工具:AndResGuard [有源碼]
一個基于MQTT通信協議的完整Android推送Demo [附件下載]
Android版高仿微信聊天界面源碼 [附件下載]

[2] 精品文檔和工具下載:
計算機網絡通訊協議關系圖(中文珍藏版)[附件下載]
史上最全即時通訊軟件簡史(精編大圖版)[附件下載]
基于RTMP協議的流媒體技術的原理與應用(技術論文)[附件下載]
獨家發布《TCP/IP詳解 卷1:協議》CHM版 [附件下載]
良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]
MQTT協議手冊(中文翻譯版)[附件下載]
經典書籍《UNIX網絡編程》最全下載(卷1+卷2、中文版+英文版)[附件下載]
音視頻開發理論入門書籍之《視頻技術手冊(第5版)》[附件下載]
國際電聯H.264視頻編碼標準官方技術手冊(中文版)[附件下載]
Apache MINA2.0 開發指南(中文版)[附件下載]
網絡通訊數據抓包和分析工具 Wireshark 使用教程(中文) [附件下載]
最新收集NAT穿越(p2p打洞)免費STUN服務器列表 [附件下載]
高性能網絡編程經典:《The C10K problem(英文)》[附件下載]
即時通訊系統的原理、技術和應用(技術論文)[附件下載]
技術論文:微信對網絡影響的技術試驗及分析[附件下載]
華為內部3G網絡資料: WCDMA系統原理培訓手冊[附件下載]
網絡測試:Android版多路ping命令工具EnterprisePing[附件下載]
Android反編譯利器APKDB:沒有美工的日子里繼續堅強的擼
一款用于P2P開發的NAT類型檢測工具 [附件下載]
兩款增強型Ping工具:持續統計、圖形化展式網絡狀況 [附件下載]

[3] 精選視頻、演講PPT下載:
QQ空間移動端10億級視頻播放技術優化揭秘(視頻+PPT)[附件下載]
RTC實時互聯網2017年度大會精選演講PPT [附件下載]
微信分享開源IM網絡層組件庫Mars的技術實現(視頻+PPT)[附件下載]
微服務理念在微信海量用戶后臺架構中的實踐(視頻+PPT)[附件下載]
移動端IM開發和構建中的技術難點實踐分享(視頻+PPT)[附件下載]
網易云信的高品質即時通訊技術實踐之路(視頻+PPT)[附件下載]
騰訊音視頻實驗室:直面音視頻質量評估之痛(視頻+PPT)[附件下載]
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT[附件下載]
微信朋友圈海量技術之道PPT[附件下載]
手機淘寶消息推送系統的架構與實踐(音頻+PPT)[附件下載]
如何進行實時音視頻的質量評估與監控(視頻+PPT)[附件下載]
Go語言構建高并發消息推送系統實踐PPT(來自360公司)[附件下載]
網易IM云千萬級并發消息處理能力的架構設計與實踐PPT [附件下載]
手機QQ的海量用戶移動化實踐分享(視頻+PPT)[附件下載]
釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT)[附件下載]
微信技術總監談架構:微信之道——大道至簡(PPT講稿)[附件下載]
Netty的架構剖析及應用案例介紹(視頻+PPT)[附件下載]
聲網架構師談實時音視頻云的實現難點(視頻采訪)
滴滴打車架構演變及應用實踐(PPT講稿)[附件下載]
微信海量用戶背后的后臺系統存儲架構(視頻+PPT)[附件下載]
在線音視頻直播室服務端架構最佳實踐(視頻+PPT)[附件下載]
從0到1:萬人在線的實時音視頻直播技術實踐分享(視頻+PPT)[附件下載]
微信移動端應對弱網絡情況的探索和實踐PPT[附件下載]
Android版微信從300KB到30MB的技術演進(PPT講稿)[附件下載]

附錄2:相關文章匯總


[1] 有關QQ、微信的技術文章:
微信后臺團隊:微信后臺異步消息隊列的優化升級實踐分享
微信團隊原創分享:微信客戶端SQLite數據庫損壞修復實踐
騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(下篇)
騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(上篇)
微信Mars:微信內部正在使用的網絡層封裝庫,即將開源
如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源
開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]
微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解
微信團隊原創分享:Android版微信后臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)
Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]
微信團隊原創分享:Android版微信從300KB到30MB的技術演進
微信技術總監談架構:微信之道——大道至簡(演講全文)
微信技術總監談架構:微信之道——大道至簡(PPT講稿) [附件下載]
如何解讀《微信技術總監談架構:微信之道——大道至簡》
微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]
微信異步化改造實踐:8億月活、單機千萬連接背后的后臺解決方案
微信朋友圈海量技術之道PPT [附件下載]
微信對網絡影響的技術試驗及分析(論文全文)
一份微信后臺技術架構的總結性筆記
架構之道:3個程序員成就微信朋友圈日均10億發布量[有視頻]
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
快速裂變:見證微信強大后臺架構從0到1的演進歷程(二)
微信團隊原創分享:Android內存泄漏監控和優化技巧總結
全面總結iOS版微信升級iOS9遇到的各種“坑”
微信團隊原創資源混淆工具:讓你的APK立減1M
微信團隊原創Android資源混淆工具:AndResGuard [有源碼]
Android版微信安裝包“減肥”實戰記錄
iOS版微信安裝包“減肥”實戰記錄
移動端IM實踐:iOS版微信界面卡頓監測方案
微信“紅包照片”背后的技術難題
移動端IM實踐:iOS版微信小視頻功能技術方案實錄
移動端IM實踐:Android版微信如何大幅提升交互性能(一)
移動端IM實踐:Android版微信如何大幅提升交互性能(二)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
移動端IM實踐:iOS版微信的多設備字體適配方案探討
>> 更多同類文章 ……

[2] 有關QQ、微信的技術故事:
技術往事:創業初期的騰訊——16年前的冬天,誰動了馬化騰的代碼
技術往事:史上最全QQ圖標變遷過程,追尋IM巨人的演進歷史
開發往事:深度講述2010到2015,微信一路風雨的背后
開發往事:微信千年不變的那張閃屏圖片的由來
開發往事:記錄微信3.0版背后的故事(距微信1.0發布9個月時)
一個微信實習生自述:我眼中的微信開發團隊
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:微信移動端應對弱網絡情況的探索和實踐PPT [附件下載]下一篇:網易IM云千萬級并發消息處理能力的架構設計與實踐PPT [附件下載]

本帖已收錄至以下技術專輯

推薦方案
評論 8
樓主有正式使用過libco嗎
引用:william 發表于 2017-01-04 09:19
樓主有正式使用過libco嗎

我沒正式用過,但你如果精通c++的話值得花時間研究一下,這樣的東西目前基本沒有第種實現。
簽名: 《Java的BIO和NIO很難懂?跟著代碼示例,重新理解它們!》:http://www.emxvra.tw/thread-2846-1-1.html
嗯,我現在線上是用的,效果還可以
引用:william 發表于 2017-01-04 13:58
嗯,我現在線上是用的,效果還可以

用在你自已的IM服務端了?性能有微信官方說的這么好嗎?
簽名: 《Java的BIO和NIO很難懂?跟著代碼示例,重新理解它們!》:http://www.emxvra.tw/thread-2846-1-1.html
值得學習
簽名: talk is cheap,show me the code
感謝分享!!!!!!!!
mark
簽名: 樣樣精通
感謝分享
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
777彩票走势图表