前言
是不是覺得C++寫個服務太累，但又沉迷於C++的真香性能而無法自拔？作為一個老牌C++程序員（可以看我 github 上十幾年前的C++項目：https://github.com/kevwan ），這幾天聽一個好友跟我聊起他寫的C++框架，說極簡代碼即可完成各種C++服務的開發，不禁讓我心生好奇！於是我去研究了一下，發現確實有點意思！
實戰（干貨）
話不多說，我們來一起看看，10行C++代碼怎么實現一個高性能的Http服務，輕松QPS幾十萬。Linus說：talk is cheap，show me the code ↓
int main() {
WFHttpServer server([](WFHttpTask *task) {
task->get_resp()->append_output_body("Hello World!");
});
if (server.start(8888) == 0) {
getchar(); // press "Enter" to end.
server.stop();
}
return 0;
}
這個 server 使用了 workflow，安裝編譯都非常簡單，以 Linux 為例，把代碼拉下來后，一行命令即搞定編譯：
➜ git clone https://github.com/sogou/workflow
➜ cd workflow
➜ make
➜ cd tutorial
➜ make
➜ ./helloworld
代碼在 tutorial 目錄，編譯后的 helloworld 可以直接運行，偵聽在 8888 端口，curl 即可訪問：
➜ curl -i http://localhost:8888
HTTP/1.1 200 OK
Content-Length: 25
Connection: Keep-Alive
Hello World!
伴隨着以上這10行代碼，我們詳細地解讀：
- 我們選用 Http 協議，因此構造了一個
WFHttpServer； - 一次網絡交互就是一次任務，因為是 Http 協議，因此我們是
WFHttpTask； - 對server來說，我的交互任務就是收到請求之后，填好回復，這些通過：
task->get_req()和task->get_resp()可以獲得； - 邏輯在一個函數中（即上面的 lambda），表示收到消息之后要做的事情，這里填了一句 “Hello World!”;
- Server啟動和退出使用
start()和stop()兩個簡單的api，而中間要用getchar();卡住，是因為 workflow 是個純異步的框架。
純異步就是這個 Http 服務器的高性能所在：
-
第一，多線程提供服務
如果我們收到請求之后在這個函數里做了一些阻塞的事情（比如等鎖、io請求或者忙碌的計算等），那么再有用戶請求我的時候，我就沒有線程去處理新用戶了
-
第二，網絡線程和執行線程有優秀的調度策略
再多的線程也可能會有被霸占完的時候。我們需要無論 server 函數想要做任何耗時的操作，都不會影響到網絡線程
-
第三，以 linux 為例，對epoll的封裝高效好用
如果服務只打算支持一萬的QPS，其實底層怎么實現都很簡單，但如果我們希望十萬，甚至接近百萬，則我們對server底層做收發的I/O模型有非常高的要求
我們來看看 workflow 是怎么來實現以上這些高並發能力：
基於以上的架構，基於 workflow 的 server 輕輕松松就可以達到幾十萬 QPS，高吞吐、低成本、開發快，完美支撐了搜狗的所有后端在線服務！詳細代碼實現請參考 workflow 源碼。然后我們以數據說話，通過跟名譽全球的高性能 Http 服務器 nginx 和國內開源框架先驅 brpc 一起做比較，看一下固定數據長度下 QPS 與並發度的關系：
以上是在同一台機器上用相同的變量做的 wrk 壓測，具體可以到 github 查看機器配置、參數及壓測工具代碼。當數據長度保持不變，QPS 隨着並發度提高而增大，后趨於平穩。此過程中 workflow 一直有明顯優勢，高於 nginx 和 brpc。 特別是數據長度為64和512的兩條曲線， 並發度足夠的時候，可以保持50W的QPS。
總結
workflow 能在開源大半年在github上收獲4k星星的認可，當然是除了簡單和高性能以外，還有其他許多的特點，如果你對其他使用場景還有所好奇，或者希望嘗試壓測一下感受高QPS帶來的心跳加速，那么歡迎點擊 workflow 的 github 獵奇更多腦洞大開的功能和用法。
項目地址
https://github.com/sogou/workflow
歡迎使用 workflow 並 star 支持一下！
微信交流
關注『微服務實踐』公眾號並回復 進群 獲取微服務社區群二維碼。