ibco是微信後臺大規(guī)模使用的c/c++協(xié)程函式庫，2013年至今穩(wěn)定運作在微信後臺的數(shù)萬臺機器上。 libco在2013年的時候作為騰訊六大開源專案首次開源，我們最近做了一次較大的更新，同步更新在github.com/tencent/libco?上。 libco支援後臺敏捷的同步風(fēng)格程式設(shè)計模式，同時提供系統(tǒng)的高並發(fā)能力。

　　libco支援的特性

　　無需侵入業(yè)務(wù)邏輯，把多進程、多執(zhí)行緒服務(wù)改造成協(xié)程服務(wù)，並發(fā)能力得到百倍提升;

　　支援CGI框架，輕鬆建置web服務(wù)(New);

　　支援gethostbyname、mysqlclient、ssl等常用第三函式庫(New);

　　可選的共用堆疊模式，單機輕鬆接入千萬連接(New);

　　完善簡潔的協(xié)程編程接口

　　– 類別pthread接口設(shè)計，透過co_create、co_resume等簡單清晰接口即可完成協(xié)程的創(chuàng)建與恢復(fù); – 類別thread的協(xié)程私有變數(shù)、協(xié)程間通訊的協(xié)程信號量co_signal (New); – 非語言層級的lambda實現(xiàn)，結(jié)合協(xié)程間通訊的協(xié)程信號量co_signal (New); – 非語言層級的lambda實現(xiàn)，結(jié)合協(xié)程原地編寫並執(zhí)行後臺非同步任務(wù)(New); – 基於epoll/kqueue實現(xiàn)的小而輕的網(wǎng)路框架，基於時間輪盤實現(xiàn)的高效能定時器;

　　libco產(chǎn)生的背景

　　早期微信後臺因為業(yè)務(wù)需求複雜多變、產(chǎn)品要求快速迭代等需求，大部分模組都採用了半同步半異步模型。存取層為非同步模型，業(yè)務(wù)邏輯層則是同步的多進程或多執(zhí)行緒模型，業(yè)務(wù)邏輯的並發(fā)能力只有幾十到幾百。隨著微信業(yè)務(wù)的成長，系統(tǒng)規(guī)模變得越來越龐大，每個模組很容易受到後端服務(wù)/網(wǎng)路抖動的影響。

　　非同步化改造的選擇

　　為了提升微信後臺的並發(fā)能力，一般的做法是把現(xiàn)網(wǎng)的所有服務(wù)改成非同步模型。這種做法工程量龐大，從框架到業(yè)務(wù)邏輯程式碼均需要做一次徹底的改造，耗時耗力且風(fēng)險巨大。於是我們開始考慮使用協(xié)程。

　　但使用協(xié)程會面臨以下挑戰(zhàn)：

　　業(yè)界協(xié)程在c/c++環(huán)境下沒有大規(guī)模應(yīng)用的經(jīng)驗;

　　如何控制協(xié)程調(diào)度;

　　如何處理同步風(fēng)格的API調(diào)用，如Socket、mysqlclient等;

　　如何處理已有全域變數(shù)、執(zhí)行緒私有變數(shù)的使用;

#最後我們透過libco解決了上述的所有問題，實現(xiàn)了對業(yè)務(wù)邏輯非侵入性的非同步化改造。我們使用libco對微信後臺上百個模組進行了協(xié)程非同步化改造，改造過程中業(yè)務(wù)邏輯程式碼基本上沒有修改。至今，微信後臺絕大部分服務(wù)都已是多進程或多執(zhí)行緒協(xié)程模型，並發(fā)能力相比之前有了質(zhì)的提升，而libco也成為了微信後臺框架的基石。

　　libco框架

　　libco在框架分為三層，分別是介面層、系統(tǒng)函數(shù)Hook層以及事件驅(qū)動層。

　　同步風(fēng)格API的處理

　　對於同步風(fēng)格的API，主要是同步的網(wǎng)路調(diào)用，libco的首要任務(wù)是消除這些等待對資源的佔用，提高系統(tǒng)的並發(fā)效能。一個常規(guī)的網(wǎng)路後臺服務(wù)，我們可能會經(jīng)歷connect、write、read等步驟，完成一次完整的網(wǎng)路互動。當同步的呼叫這些API的時候，整個執(zhí)行緒會因為等待網(wǎng)路互動而掛起。

　　雖然同步程式設(shè)計風(fēng)格的並發(fā)效能並不好，但是它具有程式碼邏輯清晰、易於編寫的優(yōu)點，並可支援業(yè)務(wù)快速迭代敏捷開發(fā)。為了繼續(xù)保持同步程式設(shè)計的優(yōu)點，且不需修改線上已有的業(yè)務(wù)邏輯程式碼，libco創(chuàng)新地接管了網(wǎng)路呼叫介面(Hook)，把協(xié)程的讓出與復(fù)原作為非同步網(wǎng)路IO中的一次事件註冊與回調(diào)。當業(yè)務(wù)處理遇到同步網(wǎng)路請求的時候，libco層會把本次網(wǎng)路請求註冊為非同步事件，本協(xié)程讓出CPU佔用，CPU交給其它協(xié)程執(zhí)行。 libco會在網(wǎng)路事件發(fā)生或逾時的時候，自動的復(fù)原協(xié)程執(zhí)行。

　　大部分同步風(fēng)格的API我們都透過Hook的方法來接管了，libco會在恰當?shù)臅r機調(diào)度協(xié)程恢復(fù)執(zhí)行。

　　千萬級協(xié)程支援
　　libco預(yù)設(shè)是每一個協(xié)程獨享一個運行棧，在協(xié)程創(chuàng)建的時候，從堆內(nèi)存分配一個固定大小的內(nèi)存作為該協(xié)程的運行棧。如果我們用一個協(xié)程處理前端的一個接入連接，那麼對於一個海量接入服務(wù)來說，我們的服務(wù)的並發(fā)上限就很容易受限於記憶體。為此，libco也提供了stackless的協(xié)程共享堆疊模式，可以設(shè)定若干個協(xié)程共享同一個運行堆疊。同一個共享堆疊下的協(xié)程間切換的時候，需要把目前的運行棧內(nèi)容拷貝到協(xié)程的私有記憶體中。為了減少這種記憶體拷貝次數(shù)，共享堆疊的記憶體拷貝只發(fā)生在不同協(xié)程間的切換。當共享棧的佔用者一直沒有改變的時候，則不需要拷貝運行棧。

　　libco協(xié)程的共享協(xié)程堆疊模式使得單機很容易接入千萬連接，只需創(chuàng)建足夠多的協(xié)程即可。我們透過libco共享堆疊模式創(chuàng)建1千萬的協(xié)程(E5-2670 v3 @ 2.30GHz * 2, 128G內(nèi)存)，每10萬個協(xié)程共享的使用128k內(nèi)存，整個穩(wěn)定echo服務(wù)的時候總記憶體消耗大概為66G。
　　協(xié)程私有變數(shù)
　　多行程程式改造為多執(zhí)行緒程式時候，我們可以用thread來對全域變數(shù)進行快速修改，而在協(xié)程環(huán)境下，我們創(chuàng)造了協(xié)程變數(shù)ROUTINE_VAR，極大簡化了協(xié)程的改造工作量。
　　因為協(xié)程實質(zhì)上是線程內(nèi)串行執(zhí)行的，所以當我們定義了一個線程私有變數(shù)的時候，可能會有重入的問題。例如我們定義了一個thread的線程私有變量，原本就是希望每一個執(zhí)行邏輯獨享這個變數(shù)的。但當我們的執(zhí)行環(huán)境遷移到協(xié)程了之後，同一個執(zhí)行緒私有變量，可能會有多個協(xié)程會操作它，這就導(dǎo)致了變數(shù)衝入的問題。為此，我們在做libco非同步化改造的時候，把大部分的執(zhí)行緒私有變數(shù)改成了協(xié)程級私有變數(shù)。協(xié)程私有變數(shù)具有這樣的特性：當程式碼運行在多執(zhí)行緒非協(xié)程環(huán)境下時，該變數(shù)是執(zhí)行緒私有的;當程式碼運行在協(xié)程環(huán)境的時候，此變數(shù)是協(xié)程私有的。底層的協(xié)程私有變數(shù)會自動完成執(zhí)行環(huán)境的判斷並正確傳回所需的值。
　　協(xié)程私有變數(shù)對於現(xiàn)有環(huán)境同步到非同步化改造起了舉足輕重的作用，同時我們定義了一個非常簡單方便的方法定義協(xié)程私有變量，簡單到只需一行聲明程式碼即可。
　　gethostbyname的Hook方法
　　對於現(xiàn)網(wǎng)服務(wù)，有可能需要透過系統(tǒng)的gethostbyname API介面去查詢DNS取得真實位址。我們在協(xié)程化改造的時候，發(fā)現(xiàn)我們hook的socket族函數(shù)對gethostbyname不適用，當一個協(xié)程呼叫了gethostbyname時會同步等待結(jié)果，這就導(dǎo)致了同執(zhí)行緒內(nèi)的其它協(xié)程被延遲執(zhí)行。我們對glibc的gethostbyname源碼進行了研究，發(fā)現(xiàn)hook不生效主要是由於glibc內(nèi)部是定義了poll方法來等待事件，而不是通用的poll方法;同時glibc還定義了一個線程私有變量，不同協(xié)程的切換可能會重入導(dǎo)致數(shù)據(jù)不準確。最終gethostbyname協(xié)程非同步化是透過Hook poll方法以及定義協(xié)程私有變數(shù)來解決的。
　　gethostbyname是glibc提供的同步查詢dns接口，業(yè)界還有很多優(yōu)秀的gethostbyname的非同步化解決方案，但是這些實作都需要引入一個第三方函式庫並且要求底層提供非同步回呼通知機制。 libco透過hook方法，在不修改glibc源碼的前提下實現(xiàn)了的gethostbyname的非同步化。
　　協(xié)程信號量
　　在多執(zhí)行緒環(huán)境下，我們會有執(zhí)行緒間同步的需求，例如一個執(zhí)行緒的執(zhí)行需要等待另一個執(zhí)行緒的訊號，對於這個需求，我們通常是使用pthread_signal 來解決的。在libco中，我們定義了協(xié)程信號量co_signal用於處理協(xié)程間的並發(fā)需求，一個協(xié)程可以透過co_cond_signal與co_cond_broadcast來決定通知一個等待的協(xié)程或喚醒所有等待協(xié)程。
　　總結(jié)
　　libco是一個高效的c/c++協(xié)程函式庫，提供了完善的協(xié)程程式介面、常用的Socket族函數(shù)Hook等，使得業(yè)務(wù)可用同步程式設(shè)計模型快速迭代開發(fā)。隨著幾年來的穩(wěn)定運行，libco作為微信後臺框架的基石發(fā)揮了舉足輕重的作用。

【相關(guān)推薦】

1. 微信公眾號平臺原始碼下載

2. 阿貍子訂單系統(tǒng)原始碼免費下載

以上是教你libco是如何支撐龐大數(shù)據(jù)資訊的的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！