搜狗公司開源了其 C++ 服務(wù)器引擎 Sogou C++ Workflow柏副，這一引擎實(shí)現(xiàn)了高性能、輕量級(jí)落地蚣录，還引入任務(wù)流概念割择，實(shí)現(xiàn)了計(jì)算任務(wù)與通信任務(wù)的統(tǒng)一和協(xié)同調(diào)度。
據(jù)介紹萎河，目前該引擎支撐著搜狗幾乎所有后端 C++ 在線服務(wù)荔泳，包括所有搜索服務(wù)、云輸入法與在線廣告等虐杯，每日處理數(shù)百億請(qǐng)求玛歌。
Sogou C++ Workflow 在設(shè)計(jì)之初，就秉持著高性能與輕量級(jí)兩個(gè)核心理念擎椰。長久以來支子，業(yè)界中優(yōu)化服務(wù)器性能都主要專注于如何跑滿 cpu、如何單獨(dú)地讓網(wǎng)絡(luò)請(qǐng)求極速響應(yīng)等方面达舒。而此次上線的搜狗 Workflow 則更專注于如何讓各種網(wǎng)絡(luò)資源被具體的調(diào)度器管理值朋，使其盡可能地全部調(diào)度起來叹侄。
另一方面，對(duì)多通信計(jì)算資源融為一體的解決方案昨登，進(jìn)一步提升了 Workflow 引擎的性能趾代。過去開發(fā)者在面臨選擇高吞吐網(wǎng)絡(luò)框架時(shí)，需要自己面對(duì)不同計(jì)算資源比例而劃分不同大小的線程池丰辣。然而每種計(jì)算具體資源需求比例是動(dòng)態(tài)變化的撒强，重要性也不一樣，后端響應(yīng)時(shí)長也是動(dòng)態(tài)變動(dòng)笙什。Sogou C++ Workflow 使得 C++ 服務(wù)器引擎也能像 Go 語言一樣飘哨，實(shí)現(xiàn)網(wǎng)絡(luò)資源異步調(diào)度，并且進(jìn)一步打通計(jì)算與磁盤等資源琐凭。
此項(xiàng)目最大的亮點(diǎn)可能是創(chuàng)新性引入了任務(wù)流的概念杖玲，Sogou C++ Workflow 將資源高度封裝，用戶再也接觸不到連接池淘正、線程池摆马，包括想要做 aio 時(shí)的文件 fd 與各種異步通知機(jī)制。這就意味著鸿吆，在開發(fā)階段開發(fā)人員僅僅需要了解業(yè)務(wù)關(guān)系而不用關(guān)心內(nèi)部細(xì)節(jié)囤采，幫助開發(fā)者們實(shí)現(xiàn)自己復(fù)雜的業(yè)務(wù)邏輯。
開發(fā)人員可以利用 Sogou C++ Workflow 封裝好的各種任務(wù)來動(dòng)態(tài)或靜態(tài)組建自己的業(yè)務(wù)邏輯惩淳，如下圖所示蕉毯，不同類型的任務(wù)都可以被串行、并行到一起：
根據(jù)資料思犁，除了各種創(chuàng)新設(shè)計(jì)以外代虾，Sogou C++ Workflow 還擁有友好的用戶體驗(yàn)。Sogou C++ Workflow 原生實(shí)現(xiàn)了對(duì)http激蹲、redis棉磨、mysql 和 kafka 等協(xié)議的支持，可以直接作為這些協(xié)議的客戶端使用学辱。并且在其基礎(chǔ)上開發(fā)了一套更加易用的 Sogou RPC乘瓤，實(shí)現(xiàn)了與 brpc 和 thrift 互通，并且可以通過 http+json 或 IDL 實(shí)現(xiàn)跨語言策泣。
開發(fā)團(tuán)隊(duì)透露衙傀，Sogou RPC 項(xiàng)目也會(huì)在不久的將來開源。
Http Server 性能實(shí)測：Sogou C++ Workflow VS nginx萨咕、brpc
搜狗團(tuán)隊(duì)也提供了 Sogou C++ Workflow 和 nginx统抬、brpc 兩個(gè)主流系統(tǒng)的 http server 性能對(duì)比。
測試環(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 個(gè) nthreads钱骂，workflow 配置了 16 個(gè) poller 線程和 20 個(gè) handler 線程。
測試一：不同并發(fā)數(shù)對(duì) QPS 的影響(越高越好)
結(jié)論：隨著壓測并發(fā)數(shù)的增加挪鹏，server 的 QPS 會(huì)隨著增高见秽。可以看到 Workflow 無論是低并發(fā)數(shù)還是高并發(fā)數(shù)的情況下讨盒，QPS 依然比 nginx 和 brpc 要高解取，尤其是并發(fā)數(shù)超過 128 的時(shí)候優(yōu)勢(shì)更加明顯，Workfow 對(duì)于小包基本能保證 50w 的 QPS返顺，說明內(nèi)部對(duì)網(wǎng)絡(luò)資源的高并發(fā)調(diào)度做了很多優(yōu)化禀苦。
測試二：不同數(shù)據(jù)大小對(duì) QPS 的影響(越高越好)
結(jié)論：此處的返回包大小是 http 請(qǐng)求的 body 大小，隨著返回包增大遂鹊，QPS 會(huì)有所下降振乏，我們希望 QPS 依然盡可能保持平穩(wěn)不要下降得太快。Workflow 在同并發(fā)下的性能依然比其他兩個(gè)系統(tǒng)要好秉扑，說明網(wǎng)絡(luò)收發(fā)和其他調(diào)用之間的調(diào)度協(xié)調(diào)得更好慧邮。
測試三：固定 QPS 下的延遲分布 CDF 圖(越左越好，越直越好)
結(jié)論：
本測試由 wrk2 進(jìn)行固定 QPS 的壓測舟陆，其中還有 1% 的長尾請(qǐng)求 Outiler误澳，長尾請(qǐng)求不計(jì)入結(jié)果，因?yàn)槲覀冴P(guān)注的是模擬真實(shí)情況下普通請(qǐng)求能否被及時(shí)處理秦躯。由于 nginx 在其他測試中性能略差一截忆谓，因此沒有對(duì)其進(jìn)行 CDF 對(duì)比□獬校可以看到在不同比例的分布中陪毡，Workflow 的延遲更低、且最慢的那些(0.99 到 1.00 之間)延遲增長也相對(duì)緩慢勾扭，說明 Workflow 對(duì)長尾處理更及時(shí)毡琉。
