搜狗公司开源了其 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 对长尾处理更及时。
猜你喜欢: