[[340695]]

搜狗公司開源了其 C++ 服務器引擎 Sogou C++ Workflow，這一引擎實現了高性能、輕量級落地，還引入任務流概念，實現了計算任務與通信任務的統一和協同調度。

據介紹，目前該引擎支撐著搜狗幾乎所有后端 C++ 在線服務，包括所有搜索服務、云輸入法與在線廣告等，每日處理數百億請求。

Sogou C++ Workflow 在設計之初，就秉持著高性能與輕量級兩個核心理念。長久以來，業界中優化服務器性能都主要專注于如何跑滿 cpu、如何單獨地讓網絡請求極速響應等方面。而此次上線的搜狗 Workflow 則更專注于如何讓各種網絡資源被具體的調度器管理，使其盡可能地全部調度起來。

另一方面，對多通信計算資源融為一體的解決方案，進一步提升了 Workflow 引擎的性能。過去開發者在面臨選擇高吞吐網絡框架時，需要自己面對不同計算資源比例而劃分不同大小的線程池。然而每種計算具體資源需求比例是動態變化的，重要性也不一樣，后端響應時長也是動態變動。Sogou C++ Workflow 使得 C++ 服務器引擎也能像 Go 語言一樣，實現網絡資源異步調度，并且進一步打通計算與磁盤等資源。

此項目最大的亮點可能是創新性引入了任務流的概念，Sogou C++ Workflow 將資源高度封裝，用戶再也接觸不到連接池、線程池，包括想要做 aio 時的文件 fd 與各種異步通知機制。這就意味著，在開發階段開發人員僅僅需要了解業務關系而不用關心內部細節，幫助開發者們實現自己復雜的業務邏輯。

開發人員可以利用 Sogou C++ Workflow 封裝好的各種任務來動態或靜態組建自己的業務邏輯，如下圖所示，不同類型的任務都可以被串行、并行到一起：

根據資料，除了各種創新設計以外，Sogou C++ Workflow 還擁有友好的用戶體驗。Sogou C++ Workflow 原生實現了對http、redis、mysql 和 kafka 等協議的支持，可以直接作為這些協議的客戶端使用。并且在其基礎上開發了一套更加易用的 Sogou RPC，實現了與 brpc 和 thrift 互通，并且可以通過 http+json 或 IDL 實現跨語言。

開發團隊透露，Sogou RPC 項目也會在不久的將來開源。

Http Server 性能實測：Sogou C++ Workflow VS nginx、brpc

搜狗團隊也提供了 Sogou C++ Workflow 和 nginx、brpc 兩個主流系統的 http server 性能對比。

測試環境：

• 選取了最基本的測試場景：wrk 或者 wrk2 跨機做 client，單 server，長連接，CPU：40 核 E5-2630 v4 @ 2.20GHz，內存：192GB，網卡：25000Mb/s。nginx 配置了 auto 的進程數(與核數一致)，brpc 配置了 40 個 nthreads，workflow 配置了 16 個 poller 線程和 20 個 handler 線程。

測試一：不同并發數對 QPS 的影響(越高越好)

結論：隨著壓測并發數的增加，server 的 QPS 會隨著增高。可以看到 Workflow 無論是低并發數還是高并發數的情況下，QPS 依然比 nginx 和 brpc 要高，尤其是并發數超過 128 的時候優勢更加明顯，Workfow 對于小包基本能保證 50w 的 QPS，說明內部對網絡資源的高并發調度做了很多優化。

測試二：不同數據大小對 QPS 的影響(越高越好)

結論：此處的返回包大小是 http 請求的 body 大小，隨著返回包增大，QPS 會有所下降，我們希望 QPS 依然盡可能保持平穩不要下降得太快。Workflow 在同并發下的性能依然比其他兩個系統要好，說明網絡收發和其他調用之間的調度協調得更好。

測試三：固定 QPS 下的延遲分布 CDF 圖(越左越好，越直越好)

結論：本測試由 wrk2 進行固定 QPS 的壓測，其中還有 1% 的長尾請求 Outiler，長尾請求不計入結果，因為我們關注的是模擬真實情況下普通請求能否被及時處理。由于 nginx 在其他測試中性能略差一截，因此沒有對其進行 CDF 對比。可以看到在不同比例的分布中，Workflow 的延遲更低、且最慢的那些(0.99 到 1.00 之間)延遲增長也相對緩慢，說明 Workflow 對長尾處理更及時。