前言
是不是觉得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 支持一下！
微信交流
关注『微服务实践』公众号并回复 进群 获取微服务社区群二维码。