9月3日，搜狗公司正式宣布開源C++服務(wù)器引擎——Sogou C++Workflow。目前Workflow支撐著搜狗幾乎所有后端C++在線服務(wù)包括所有搜索服務(wù)，云輸入法，在線廣告等，每日處理數(shù)百億請求，引擎一經(jīng)發(fā)布就在 GitHub 上引起眾多開發(fā)者關(guān)注。這款引擎不僅實(shí)現(xiàn)了高性能、輕量級的落地，還創(chuàng)新性的引入任務(wù)流概念，實(shí)現(xiàn)了計(jì)算任務(wù)與通信任務(wù)的統(tǒng)一和協(xié)同調(diào)度?；赪orkflow引擎，開發(fā)者可以方便的實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)邏輯，并進(jìn)一步滿足對高并發(fā)、高性能C++服務(wù)器程序的開發(fā)需求。
GitHub搜索 Sogou C ++ Workflow即可找到該項(xiàng)目。
輕量級、高性能， Sogou C++ Workflow助力企業(yè)降本增效
Workflow在設(shè)計(jì)之初，就秉持著高性能與輕量級兩個核心理念。長久以來，業(yè)界中優(yōu)化服務(wù)器性能都主要專注于如何跑滿cpu、如何單獨(dú)地讓網(wǎng)絡(luò)請求極速響應(yīng)等方面。而此次上線搜狗Workflow則更專注于如何讓各種網(wǎng)絡(luò)資源被具體的調(diào)度器管理，使其盡可能地全部調(diào)度起來。
另一方面，對多通信計(jì)算資源融為一體的解決方案，進(jìn)一步提升了Workflow引擎的性能。過去開發(fā)者在面臨選擇高吞吐網(wǎng)絡(luò)框架時，需要自己面對不同計(jì)算資源比例而劃分不同大小的線程池。然而每種計(jì)算具體資源需求比例是動態(tài)變化的，重要性也不一樣，后端響應(yīng)時長也是動態(tài)變動。如今在workflow的加持下，C++服務(wù)器引擎也能像Go語言一樣，實(shí)現(xiàn)網(wǎng)絡(luò)資源異步調(diào)度，并且進(jìn)一步打通計(jì)算，磁盤等資源。
引入任務(wù)流概念，是搜狗Workflow引擎的另一亮點(diǎn)。Workflow將資源高度封裝，用戶再也接觸不到連接池、線程池、包括想要做aio時的文件fd與各種異步通知機(jī)制。這就意味著，在開發(fā)階段開發(fā)人員僅僅需要了解業(yè)務(wù)關(guān)系而不用關(guān)心內(nèi)部細(xì)節(jié)，幫助開發(fā)者們實(shí)現(xiàn)自己復(fù)雜的業(yè)務(wù)邏輯。
開發(fā)人員可以利用Workflow封裝好的各種任務(wù)來動態(tài)或靜態(tài)組建自己的業(yè)務(wù)邏輯，如下圖所示，不同類型的任務(wù)都可以被串行、并行到一起：
除了各種創(chuàng)新設(shè)計(jì)以外，workflow還擁有比其他C++框架更友好的用戶體驗(yàn)。過去許多企業(yè)自己搭建的服務(wù)器平臺，在設(shè)計(jì)之初并未考慮到對多平臺、多協(xié)議的支持，導(dǎo)致當(dāng)新需求出現(xiàn)之時，開發(fā)者不得不通過自定義框架等方式來解決這個問題。Workflow原生實(shí)現(xiàn)了對http、redis、mysql和kafka等協(xié)議，可以直接作為這些協(xié)議的客戶端使用。并且在其基礎(chǔ)上開發(fā)了一套更加易用的Sogou RPC，實(shí)現(xiàn)與brpc和thrift互通，IDL支持protobuf和thrift，并且可以通過http+json或IDL實(shí)現(xiàn)跨語言，Sogou RPC項(xiàng)目也會在不久的將來開源。
Http Server性能實(shí)測：Sogou C++Workflow VS nginx、brpc
為了充分的體現(xiàn)出Workflow在性能上的優(yōu)勢，搜狗也提供了Workflow和nginx、brpc兩個比較主流知名的系統(tǒng)一起做的http server性能對比，
測試環(huán)境：
這里選取了最基本的測試場景：wrk或者wrk2跨機(jī)做client，單server，長連接，CPU：40核 E5-2630 v4 @ 2.20GHz，內(nèi)存：192GB，網(wǎng)卡：25000Mb/s。nginx配置了auto的進(jìn)程數(shù)(與核數(shù)一致)，brpc配置了40個nthreads，workflow配置了16個poller線程和20個handler線程。
測試一：不同并發(fā)數(shù)對QPS的影響(越高越好)
結(jié)論：隨著壓測并發(fā)數(shù)的增加，server的QPS會隨著增高?？梢钥吹絎orkflow無論是低并發(fā)數(shù)還是高并發(fā)數(shù)的情況下，QPS依然比nginx和brpc要高，尤其是并發(fā)數(shù)超過128的時候優(yōu)勢更加明顯，Workfow對于小包基本能保證50w的QPS，說明內(nèi)部對網(wǎng)絡(luò)資源的高并發(fā)調(diào)度做了很多優(yōu)化。
測試二：不同數(shù)據(jù)大小對QPS的影響(越高越好)
結(jié)論：此處的返回包大小是http請求的body大小，隨著返回包增大，QPS會有所下降，我們希望QPS依然盡可能保持平穩(wěn)不要下降得太快。Workflow在同并發(fā)下的性能依然比其他兩個系統(tǒng)要好，說明網(wǎng)絡(luò)收發(fā)和其他調(diào)用之間的調(diào)度協(xié)調(diào)得更好。
測試三：固定QPS下的延遲分布CDF圖(越左越好，越直越好)
結(jié)論：本測試由wrk2進(jìn)行固定QPS的壓測，其中還有1%的長尾請求Outiler，長尾請求不計(jì)入結(jié)果，因?yàn)槲覀冴P(guān)注的是模擬真實(shí)情況下普通請求能否被及時處理。由于nginx在其他測試中性能略差一截，因此沒有對其進(jìn)行CDF對比?？梢钥吹皆诓煌壤姆植贾?，Workflow的延遲更低、且最慢的那些(0.99到1.00之間)延遲增長也相對緩慢，說明Workflow對長尾處理更及時。
通過對比，可以發(fā)現(xiàn)Workflow的確在核心性能上有著自己獨(dú)到的優(yōu)勢，對于很多開發(fā)者來說，往后也就多了一種選擇，遇到合適的應(yīng)用場景，Workflow無疑會幫助開發(fā)者大大提升開發(fā)效率，確保項(xiàng)目成功。
開源核心技術(shù)，讓搜狗走向開發(fā)者生態(tài)的前沿
開源如此“硬核”的服務(wù)器引擎并不常見。許多科技公司都在花費(fèi)極大精力對自己的產(chǎn)品、技術(shù)進(jìn)行保密，核心算法更是秘而不宣。而近年來，搜狗卻走了一條與大眾相反的道路。不僅是Workflow，之前搜狗還相繼開源了機(jī)器閱讀理解工具SMRC、內(nèi)部項(xiàng)目管理系統(tǒng)Cynthia在內(nèi)的多項(xiàng)核心技術(shù)和工具。事實(shí)上，搜狗正是通過的不斷對核心技術(shù)的開源，遵守并理解開源社區(qū)文化，才能推動企業(yè)本身的技術(shù)進(jìn)步，吸納更多優(yōu)秀的開發(fā)者投入其中，為相關(guān)產(chǎn)品的后續(xù)發(fā)展持續(xù)輸送技術(shù)養(yǎng)料和創(chuàng)造力。
想要在日趨激烈的互聯(lián)網(wǎng)市場中獲得話語權(quán)，就必須積極的制定標(biāo)準(zhǔn)，始終站在開發(fā)者生態(tài)的前沿，建立可持續(xù)的競爭優(yōu)勢，讓產(chǎn)品被更多用戶喜愛并使用。未來，在開源的道路上，搜狗還會不斷將相關(guān)先進(jìn)技術(shù)持續(xù)對外開放，發(fā)揮自身領(lǐng)域的專業(yè)能力與力量，推動開源運(yùn)動的進(jìn)一步普及。
