如今,，微信擁有月活躍用戶8億。不可否認(rèn),，當(dāng)今的微信后臺(tái)擁有著強(qiáng)大的并發(fā)能力,。不過(guò)， 正如羅馬并非一日建成,；微信的技術(shù)也曾經(jīng)略顯稚嫩,。微信誕生于2011年1月，當(dāng)年用戶規(guī)模為0.1億左右,；2013年11月,，微信月活躍用戶數(shù)達(dá)到3.55億，一躍成為亞洲地區(qū)擁有最大用戶群體的移動(dòng)終端即時(shí)通訊軟件,。面對(duì)如此體量的提升,，微信后臺(tái)也曾遭遇棘手的窘境；令人贊嘆的是,，技術(shù)人及時(shí)地做出了漂亮的應(yīng)對(duì),。 這背后有著怎樣的技術(shù)故事？此時(shí)此刻,，你在微信手機(jī)端發(fā)出的請(qǐng)求,，是怎樣被后臺(tái)消化和處理的？ 這次,，我們聚焦微信后臺(tái)解決方案之協(xié)程庫(kù)libco（libco介紹和源碼下載）,。該項(xiàng)目在保留后臺(tái)敏捷的同步風(fēng)格同時(shí)，提高了系統(tǒng)的并發(fā)能力,，節(jié)省了大量的服務(wù)器成本,；自2013年起穩(wěn)定運(yùn)行于微信的數(shù)萬(wàn)臺(tái)機(jī)器之上。 本文是《開(kāi)源libco庫(kù)：?jiǎn)螜C(jī)千萬(wàn)連接,、支撐微信8億用戶的后臺(tái)框架基石》一文的進(jìn)一步技術(shù)挖掘和整理,。 當(dāng)初的微信后端到底遇到了問(wèn)題早期微信后臺(tái)因?yàn)闃I(yè)務(wù)需求復(fù)雜多變、產(chǎn)品要求快速迭代等需求，大部分模塊都采用了半同步半異步模型,。接入層為異步模型,，業(yè)務(wù)邏輯層則是同步的多進(jìn)程或多線程模型，業(yè)務(wù)邏輯的并發(fā)能力只有幾十到幾百,。 隨著微信業(yè)務(wù)的增長(zhǎng),，直到2013年中,，微信后臺(tái)機(jī)器規(guī)模已達(dá)到1萬(wàn)多臺(tái),，涉及數(shù)百個(gè)后臺(tái)模塊，RPC調(diào)用每分鐘數(shù)十億,。在如此龐大復(fù)雜的系統(tǒng)規(guī)模下,，每個(gè)模塊很容易受到后端服務(wù)或者網(wǎng)絡(luò)抖動(dòng)的影響。因此我們急需對(duì)微信后臺(tái)進(jìn)行異步化的改造,。 微信后臺(tái)異步化改造方案的考量當(dāng)時(shí)微信技術(shù)團(tuán)隊(duì)有兩種選擇：
兩者相比，工作量和風(fēng)險(xiǎn)系數(shù)的差異顯而易見(jiàn),。雖然A方案服務(wù)器端多線程異步處理是常見(jiàn)做法,，對(duì)提高并發(fā)能力這個(gè)原始目標(biāo)非常奏效；但是對(duì)于微信后臺(tái)如此復(fù)雜的系統(tǒng),，這過(guò)于耗時(shí)耗力且風(fēng)險(xiǎn)巨大,。 無(wú)論是異步模型還是同步模型，都需要保存異步狀態(tài),。所以兩者在技術(shù)細(xì)節(jié)的相同點(diǎn)是,，兩個(gè)方案，都是需要維護(hù)當(dāng)前請(qǐng)求的狀態(tài),。在A異步模型中方案,，當(dāng)請(qǐng)求需要被異步執(zhí)行時(shí)，需要主動(dòng)把請(qǐng)求相關(guān)數(shù)據(jù)保存起來(lái),，再等待狀態(tài)機(jī)的下一次調(diào)度執(zhí)行,；而在B協(xié)程模型方案中，異步狀態(tài)的保存與恢復(fù)是自動(dòng)的,，協(xié)程恢復(fù)執(zhí)行的時(shí)候就是上一次退出時(shí)的上下文,。 因此，B協(xié)程方案不需要顯式地維護(hù)異步狀態(tài)：一方面在編程上可以更簡(jiǎn)單和直接,；另一方面協(xié)程中只需要保存少量的寄存器,。因此在復(fù)雜系統(tǒng)上，協(xié)程服務(wù)的性能可能比純異步模型更優(yōu)。 綜合以上考慮,，最終微信選擇了B方案,，通過(guò)協(xié)程的方式對(duì)微信后臺(tái)上百個(gè)模塊進(jìn)行了異步化改造。 如何接管歷史遺留的同步風(fēng)格API方案敲定之后,，接下來(lái)做的就是實(shí)現(xiàn)異步化的同時(shí)盡可能地少做代碼修改,。 通常而言，一個(gè)常規(guī)的網(wǎng)絡(luò)后臺(tái)服務(wù)需要connect,、write,、read等系列步驟，如果使用同步風(fēng)格的API對(duì)網(wǎng)絡(luò)進(jìn)行調(diào)用,，整個(gè)服務(wù)線程會(huì)因?yàn)榈却W(wǎng)絡(luò)交互而掛起,，這就會(huì)造成等待并占用資源。原來(lái)的這種情況很明顯地影響到了系統(tǒng)的并發(fā)性能,，但是當(dāng)初這樣的選擇是因?yàn)閷?duì)應(yīng)的同步編程風(fēng)格具有其獨(dú)特的優(yōu)勢(shì)：代碼邏輯清晰,、易于編寫(xiě)并且支持業(yè)務(wù)快速迭代敏捷開(kāi)發(fā)。 微信團(tuán)隊(duì)的改造方案需要消除同步風(fēng)格API的缺點(diǎn),，但是同時(shí)還希望保持同步編程的優(yōu)點(diǎn),。 最后在不修改線上已有的業(yè)務(wù)邏輯代碼的情況下，微信團(tuán)隊(duì)的libco框架創(chuàng)新地接管了網(wǎng)絡(luò)調(diào)用接口（Hook）,。把協(xié)程的讓出與恢復(fù)作為異步網(wǎng)絡(luò)IO中的一次事件注冊(cè)與回調(diào),。當(dāng)業(yè)務(wù)處理遇到同步網(wǎng)絡(luò)請(qǐng)求的時(shí)候，libco層會(huì)把本次網(wǎng)絡(luò)請(qǐng)求注冊(cè)為異步事件,，當(dāng)前的協(xié)程讓出CPU占用,，CPU交給其它協(xié)程執(zhí)行。在網(wǎng)絡(luò)事件發(fā)生或者超時(shí)的時(shí)候,，libco會(huì)自動(dòng)的恢復(fù)協(xié)程執(zhí)行,。 libco的架構(gòu)libco架構(gòu)從設(shè)計(jì)的時(shí)候就已經(jīng)確立下來(lái)了，最近的在GitHub上一次較大更新主要是功能上的更新,。注：libco為開(kāi)源項(xiàng)目,，源碼同步更新，詳見(jiàn)：http://www./thread-623-1-1.html,。 libco框架有三層,，分別是協(xié)程接口層、系統(tǒng)函數(shù)Hook層以及事件驅(qū)動(dòng)層,。  協(xié)程接口層實(shí)現(xiàn)了協(xié)程的基本源語(yǔ),。co_create,、co_resume等簡(jiǎn)單接口負(fù)責(zé)協(xié)程創(chuàng)建于恢復(fù),。co_cond_signal類接口可以在協(xié)程間創(chuàng)建一個(gè)協(xié)程信號(hào)量，可用于協(xié)程間的同步通信,。 系統(tǒng)函數(shù)Hook層負(fù)責(zé)主要負(fù)責(zé)系統(tǒng)中同步API到異步執(zhí)行的轉(zhuǎn)換,。對(duì)于常用的同步網(wǎng)絡(luò)接口，Hook層會(huì)把本次網(wǎng)絡(luò)請(qǐng)求注冊(cè)為異步事件,，然后等待事件驅(qū)動(dòng)層的喚醒執(zhí)行,。 事件驅(qū)動(dòng)層實(shí)現(xiàn)了一個(gè)簡(jiǎn)單高效的異步網(wǎng)路框架，里面包含了異步網(wǎng)絡(luò)框架所需要的事件與超時(shí)回調(diào),。對(duì)于來(lái)源于同步系統(tǒng)函數(shù)Hook層的請(qǐng)求,，事件注冊(cè)與回調(diào)實(shí)質(zhì)上是協(xié)程的讓出與恢復(fù)執(zhí)行。 相比線程,，libco選擇協(xié)程意味著什么,？比起線程,，對(duì)于很多人而言,，協(xié)程的應(yīng)用并不是那么輕車(chē)熟路。 線程和協(xié)程的相同點(diǎn)是什么,？我們可以簡(jiǎn)單認(rèn)為協(xié)程是一種用戶態(tài)線程,，它與線程一樣擁有獨(dú)立的寄存器上下文以及運(yùn)行棧，對(duì)程序員最直觀的效果就是,，代碼可以在協(xié)程里面正常的運(yùn)作,，就像在線程里面一樣。但是線程和協(xié)程還是有區(qū)別的,，我們需要重點(diǎn)關(guān)注是運(yùn)行棧管理模式與協(xié)程調(diào)度策略,。關(guān)于這兩點(diǎn)的具體執(zhí)行，在本文后續(xù)部分會(huì)談及,。 那兩者的不同點(diǎn)呢,？協(xié)程的創(chuàng)建與調(diào)度相比線程要輕量得多，而且協(xié)程間的通信與同步是可以無(wú)鎖的,，任一時(shí)刻都可以保證只有本協(xié)程在操作線程內(nèi)的資源,。 微信的方案是使用協(xié)程，但這意味著面臨以下挑戰(zhàn)：
下面我們來(lái)探討如何攻克這4個(gè)挑戰(zhàn),。 挑戰(zhàn)一 ：前所未有的大規(guī)模應(yīng)用C/C++協(xié)程實(shí)際上，協(xié)程這個(gè)概念的確很早就提出來(lái)了,，但是確是因?yàn)樽罱鼛啄暝谀承┱Z(yǔ)言中（如lua,、go等)被廣泛的應(yīng)用而逐漸的被大家所熟知。但是真正用于C/C++語(yǔ)言的、并且是大規(guī)模生產(chǎn)的著實(shí)不多,。 而這個(gè)libco框架中,，除了協(xié)程切換時(shí)寄存器保存與恢復(fù)使用了匯編代碼，其它代碼實(shí)現(xiàn)都是用C/C++語(yǔ)言編寫(xiě)的,。 那么,，為什么我們選擇了C/C++語(yǔ)言？ 當(dāng)前微信后臺(tái)絕大部分服務(wù)都基于C++,，原因是微信最早的后臺(tái)開(kāi)發(fā)團(tuán)隊(duì)從郵箱延續(xù)而來(lái),，郵箱團(tuán)隊(duì)一直使用C++作為后臺(tái)主流開(kāi)發(fā)語(yǔ)言，而且C++能滿足微信后臺(tái)對(duì)性能和穩(wěn)定性的要求,。 微信的C++后臺(tái)服務(wù)框架增加了協(xié)程支持之后,，高并發(fā)和快速開(kāi)發(fā)的矛盾解決了。開(kāi)發(fā)者絕大部分情況下只需要關(guān)注并發(fā)數(shù)的配置,，不需要關(guān)注協(xié)程本身,。其他語(yǔ)言微信也會(huì)在一些工具里面嘗試，但是對(duì)于整個(gè)微信后臺(tái)而言,，C++仍是微信團(tuán)隊(duì)未來(lái)長(zhǎng)期的主流語(yǔ)言,。 挑戰(zhàn)二：保留同步風(fēng)格的API這里的做法我們?cè)谏衔闹刑岬搅颂幚硗斤L(fēng)格的API的思路方法：大部分同步風(fēng)格的API我們都通過(guò)Hook的方法來(lái)接管了，libco會(huì)在恰當(dāng)?shù)臅r(shí)機(jī)調(diào)度協(xié)程恢復(fù)執(zhí)行,。 怎樣防止協(xié)程庫(kù)調(diào)度器被阻塞？ libco的系統(tǒng)函數(shù)Hook層主要處理同步API到異步執(zhí)行的轉(zhuǎn)換,，我們當(dāng)前的hook層只處理了主要的同步網(wǎng)絡(luò)接口,，對(duì)于這些接口，同步調(diào)用會(huì)被異步執(zhí)行,，不會(huì)導(dǎo)致系統(tǒng)的線程阻塞,。當(dāng)然，我們還有少量未Hook的同步接口,，這些接口的調(diào)用可能會(huì)導(dǎo)致協(xié)程調(diào)度器阻塞等待,。 與線程類似，當(dāng)我們操作跨線程數(shù)據(jù)的時(shí)候,，需要使用線程安全級(jí)別的函數(shù),。而在協(xié)程環(huán)境下，也是有協(xié)程安全的代碼約束,。在微信后臺(tái),，我們約束了不能使用導(dǎo)致協(xié)程阻塞的函數(shù)，比如pthread_mutex,、sleep類函數(shù)（可以用 poll(NULL, 0, timeout) 代替）等,。而對(duì)于已有系統(tǒng)的改造,，就需要審核已有代碼是否符合協(xié)程安全規(guī)范。 挑戰(zhàn)三：調(diào)度千萬(wàn)級(jí)協(xié)程調(diào)度策略方面,，我們可以看下Linux的進(jìn)程調(diào)度,，從早期的O(1)到目前CFS完全公平調(diào)度，經(jīng)過(guò)了很復(fù)雜的演進(jìn)過(guò)程,，而協(xié)程調(diào)度事實(shí)上也是可以參考進(jìn)程調(diào)度方法的,，比如說(shuō)你可以定義一種調(diào)度策略，使得協(xié)程在不同的線程間切換,，但是這樣做會(huì)帶來(lái)昂貴的切換代價(jià)。在進(jìn)程/線程上面,，后臺(tái)服務(wù)通常已經(jīng)做了足夠多的工作,，使得多核資源得到充分使用，所以協(xié)程的定位應(yīng)該是在這個(gè)基礎(chǔ)上發(fā)揮最大的性能,。 libco的協(xié)程調(diào)度策略很簡(jiǎn)潔,，單個(gè)協(xié)程限定在固定的線程內(nèi)部,，僅在網(wǎng)絡(luò)IO阻塞等待時(shí)候切出，在網(wǎng)絡(luò)IO事件觸發(fā)時(shí)候切回,，也就是說(shuō)在這個(gè)層面上面可以認(rèn)為協(xié)程就是有限狀態(tài)機(jī),，在事件驅(qū)動(dòng)的線程里面工作,，相信后臺(tái)開(kāi)發(fā)的同學(xué)會(huì)一下子就明白了,。 那么,，怎么實(shí)現(xiàn)千萬(wàn)級(jí)別呢,？ libco默認(rèn)是每一個(gè)協(xié)程獨(dú)享一個(gè)運(yùn)行棧,，在協(xié)程創(chuàng)建的時(shí)候，從堆內(nèi)存分配一個(gè)固定大小的內(nèi)存作為該協(xié)程的運(yùn)行棧,。如果我們用一個(gè)協(xié)程處理前端的一個(gè)接入連接,，那對(duì)于一個(gè)海量接入服務(wù)來(lái)說(shuō)，我們的服務(wù)的并發(fā)上限就很容易受限于內(nèi)存,。 所以量級(jí)的問(wèn)題就轉(zhuǎn)換成了怎樣高效使用內(nèi)存的問(wèn)題,。 為了解決這個(gè)問(wèn)題，libco采用的是共享?xiàng)ＤＪ?。（傳統(tǒng)運(yùn)行棧管理有stackfull和stackless兩種模式）簡(jiǎn)單來(lái)講,，是若干個(gè)協(xié)程共享同一個(gè)運(yùn)行棧,。 同一個(gè)共享?xiàng)Ｏ碌膮f(xié)程間切換的時(shí)候，需要把當(dāng)前的運(yùn)行棧內(nèi)容拷貝到協(xié)程的私有內(nèi)存中,。為了減少這種內(nèi)存拷貝次數(shù),，共享?xiàng)５膬?nèi)存拷貝只發(fā)生在不同協(xié)程間的切換,。當(dāng)共享?xiàng)５恼加谜咭恢睕](méi)有改變的時(shí)候,，則不需要拷貝運(yùn)行棧。  再具體一點(diǎn)講講共享?xiàng)５脑恚簂ibco默認(rèn)模式(stackfull) 滿足大部分的業(yè)務(wù)場(chǎng)景，每個(gè)協(xié)程獨(dú)占128k?？臻g,，只需1G內(nèi)存就可以支持萬(wàn)級(jí)協(xié)程。 而共享?xiàng)Ｊ莑ibco新增的一個(gè)特性,，可以支持單機(jī)千萬(wàn)協(xié)程,，應(yīng)對(duì)海量連接特殊場(chǎng)景。實(shí)現(xiàn)原理上,，共享?xiàng)ＤＪ皆趥鹘y(tǒng)的stackfull和stackless兩種模式之間做了個(gè)微創(chuàng)新,，用戶可以自定義分配若干個(gè)共享?xiàng)?nèi)存，協(xié)程創(chuàng)建時(shí)指定使用哪一個(gè)共享?xiàng),！?/span> 不同協(xié)程之間的切換,、 如何主動(dòng)退出一個(gè)正在執(zhí)行的協(xié)程？我們把共享同一塊棧內(nèi)存的多個(gè)協(xié)程稱為協(xié)程組,，協(xié)程組內(nèi)不同協(xié)程之間切換需要把棧內(nèi)存拷貝到協(xié)程的私有空間,，而協(xié)程組內(nèi)同一個(gè)協(xié)程的讓出與恢復(fù)執(zhí)行則不需要拷貝棧內(nèi)存，可以認(rèn)為共享?xiàng)５臈?nèi)存是“寫(xiě)時(shí)拷貝”的,。 共享?xiàng)Ｏ碌膮f(xié)程切換與退出,，與普通協(xié)程模式的API一致，co_yield與co_resume,，libco底層會(huì)實(shí)現(xiàn)共享?xiàng)５哪Ｊ较碌陌葱杩截悧?nèi)存,。 挑戰(zhàn)四 ：全局變量 vs 私有變量在stackfull模式下面，局部變量的地址是一直不變的,；而stackless模式下面,，只要協(xié)程被切出，那么局部變量的地址就失效了,，這是開(kāi)發(fā)者需要注意的地方,。 libco默認(rèn)的棧模式是每一個(gè)協(xié)程獨(dú)享運(yùn)行棧的，在這個(gè)模式下,，開(kāi)發(fā)者需要注意棧內(nèi)存的使用,，盡量避免 char buf[128 * 1024] 這種超大棧變量的申請(qǐng),，當(dāng)棧使用大小超過(guò)本協(xié)程棧大小的時(shí)候，就可能導(dǎo)致棧溢出的core,。 而在共享?xiàng)ＤＪ较?，雖然在協(xié)程創(chuàng)建的時(shí)候可以映射到一個(gè)比較大的棧內(nèi)存上面，但是當(dāng)本協(xié)程需要讓出給其它協(xié)程執(zhí)行的時(shí)候,，已使用棧的拷貝保存開(kāi)銷也是有的,，因此最好也是盡量減少大的局部變量使用。更多的,，共享?xiàng)ＤＪ较?，因?yàn)槭嵌鄠€(gè)協(xié)程共享了同一個(gè)棧空間,，因此,，用戶需要注意協(xié)程內(nèi)的局部棧變量地址不可以跨協(xié)程傳遞。 協(xié)程私有變量的使用場(chǎng)景與線程私有變量類似,，協(xié)程私有變量是全局可見(jiàn)的,，不同的協(xié)程會(huì)對(duì)同一個(gè)協(xié)程變量保存自己的副本。開(kāi)發(fā)者可以通過(guò)我們的API宏聲明協(xié)程私有變量,，在使用上無(wú)特別需要注意的地方,。 多進(jìn)程程序改造為多線程程序時(shí)候，我們可以用__thread來(lái)對(duì)全局變量進(jìn)行快速修改,，而在協(xié)程環(huán)境下,，我們創(chuàng)造了協(xié)程變量ROUTINE_VAR，極大簡(jiǎn)化了協(xié)程的改造工作量,。 關(guān)于協(xié)程私有變量,，因?yàn)閰f(xié)程實(shí)質(zhì)上是線程內(nèi)串行執(zhí)行的，所以當(dāng)我們定義了一個(gè)線程私有變量的時(shí)候,，可能會(huì)有重入的問(wèn)題。比如我們定義了一個(gè)__thread的線程私有變量,，原本是希望每一個(gè)執(zhí)行邏輯獨(dú)享這個(gè)變量的,。但當(dāng)我們的執(zhí)行環(huán)境遷移到協(xié)程了之后，同一個(gè)線程私有變量,，可能會(huì)有多個(gè)協(xié)程會(huì)操作它,，這就導(dǎo)致了變量沖入的問(wèn)題。 為此,，我們?cè)谧鰈ibco異步化改造的時(shí)候,，把大部分的線程私有變量改成了協(xié)程級(jí)私有變量。協(xié)程私有變量具有這樣的特性：當(dāng)代碼運(yùn)行在多線程非協(xié)程環(huán)境下時(shí),，該變量是線程私有的,；當(dāng)代碼運(yùn)行在協(xié)程環(huán)境的時(shí)候,，此變量是協(xié)程私有的。底層的協(xié)程私有變量會(huì)自動(dòng)完成運(yùn)行環(huán)境的判斷并正確返回所需的值,。 協(xié)程私有變量對(duì)于現(xiàn)有環(huán)境同步到異步化改造起了舉足輕重的作用,，同時(shí)我們定義了一個(gè)非常簡(jiǎn)單方便的方法定義協(xié)程私有變量，簡(jiǎn)單到只需一行聲明代碼即可,。 簡(jiǎn)言之,，一句話總結(jié)libco庫(kù)的原理，在協(xié)程里面用同步風(fēng)格編寫(xiě)代碼,，實(shí)際運(yùn)作是事件驅(qū)動(dòng)的有限狀態(tài)機(jī),，由上層的進(jìn)程/線程負(fù)責(zé)多核資源的使用。 最終效果：大功告成微信團(tuán)隊(duì)曾把一個(gè)狀態(tài)機(jī)驅(qū)動(dòng)的純異步代理服務(wù)改成了基于libco協(xié)程的服務(wù),，在性能上比之前提升了10%到20%,，并且，在基于協(xié)程的同步模型下,，很簡(jiǎn)單的就實(shí)現(xiàn)了批量請(qǐng)求的功能,。 正如當(dāng)時(shí)所愿，使用libco對(duì)微信后臺(tái)上百個(gè)模塊進(jìn)行了協(xié)程異步化改造,，在整個(gè)的改造過(guò)程中,，業(yè)務(wù)邏輯代碼基本沒(méi)有改變，修改只是在框架層代碼,。微信所做的是把原先在線程內(nèi)執(zhí)行的業(yè)務(wù)邏輯轉(zhuǎn)到了協(xié)程上執(zhí)行,。改造的工作主要是復(fù)核系統(tǒng)中線程私有變量、全局變量,、線程鎖的使用,，確保在協(xié)程切換的時(shí)候不會(huì)數(shù)據(jù)錯(cuò)亂或者重入。 至今,，微信后臺(tái)絕大部分服務(wù)都已是多進(jìn)程或多線程協(xié)程模型,，并發(fā)能力相比之前有了質(zhì)的提升，而在這過(guò)程中應(yīng)運(yùn)而生的libco也成為了微信后臺(tái)框架的基石,。 |
|
|
來(lái)自： liang1234_ > 《架構(gòu)參考》
