今天听说了一个新的C++语言开发的网络框架，叫做seastar。
seastar有何特别之处呢？先看看官网提供的性能数据：
性能
-
cpu # request/sec 2 637,430(相当于单核性能318715/s ) 4 1,303,761 6 1,907,912 8 2,493,690 12 3,495,012 16 4,385,829 20 5,359,786 24 6,291,073 28 6,826,827 32 6,869,199
| CPU | Seastar Memcached with DPDK | Stock Memcached (multi process) | Stock memcached (multi threaded) |
|---|---|---|---|
| 2 | 553,175(单核性能276587/s) | 350,844 | 321,287 |
| 4 | 1,021,918 | 615,270 | 573,149 |
| 6 | 1,703,790 | 857,428 | 709,502 |
| 8 | 2,149,162 | 1,102,417 | 741,356 |
| 10 | 2,629,885 | 1,335,069 | 608,014 |
| 12 | 2,870,919 | 1,528,598 | 608,968 |
| 14 | 3,217,044 | 1,726,642 | 440,658 |
| 16 | 3,460,167 | 1,887,060 | 603,479 |
| 18 | 4,049,397 | 2,167,573 | 902,192 |
| 20 | 4,426,457 | 2,281,064 | 1,128,469 |
网络框架单核的极限性能我做过很多次，我几年前测试得到的数据大约是：
- http网络服务，单核极限性能7万~9万/s
- tcp协议网络服务，单核极限性能21万~24万/s
以上的测试是简单的echo服务，没有任何业务逻辑。TCP服务更是简单，每个请求仅50字节。
在seastar框架中，http协议的单核处理能力上涨了约4.5倍。这虽然让人欣喜，但并不惊奇。令人惊奇的地方在于，框架的处理性能随着核数的增加而线性增加！
通常而言，随着操作系统和业务的复杂性，网络框架的处理性能并不会因为核数线性增加，应该类似于对数曲线的效果：
而从官方测试数据看，几乎是达到了线性增长的效果。如果是使用现在的上百核的服务器，单机性能超过千万每秒是毫无疑问的。
单机网络处理性能超过千万每秒，这就是我激动的原因。
C10K问题与C10M问题
这时就要谈起高性能网络服务器的两个经典问题，称为C10K问题和C10M问题。
- C10K就是指单机网络处理性能达到1万/每秒的并发处理能力
- C10M指单机网络处理性能达到1000万/每秒的并发处理能力
The C10K problem 由 Dan Kegel 于2003/11/03 提出。在当时的硬件水平和操作系统能力上，单机支持1万并发是很有难度的事情。由这个问题开始，催生了epoll为核心网络编程技术的推广。
The C10M problem 由 Robert Graham 于2013/02提出。十年过去了，硬件、网络、操作系统都有大幅的提升，如何做到单机1000万并发呢？当时讨论的可行方案是多队列网卡+多核IO+用户态协议栈。后来，intel放出了DPDK这个网络包处理的神器，陆续开始有团队基于DPDK挑战C10M的具体实现。
而今，seastar出现了，这就意味着后台程序员可以以很低的门槛轻松写出具备C10M性能的网络服务！！！令人惊叹。
seastar的牛叉之处
对于其内部理念的介绍，我推荐阅读这篇：《Seastar：多核机器上编写高效复杂的服务器应用程序的 C++ 库》
通过官方文档可以了解到这些特性：
-
底层包处理的API不是epoll，而是DPDK
有了DPDK，网卡中的包直接被传输到用户空间的buffer中，免去了内核协议栈的层层处理。当然这里还需要一个用户态的协议栈，使得可以以更少的内存和更小CPU消耗来处理大量的网络包。
DPDK的使用门槛还是比较高的，而seastar已经把这个神器封装在了框架之中，实在是皆大欢喜。 -
无共享设计
这也就是网络框架处理性能随着核数增加而增加的秘诀。
首先，处理上是多核IO的，充分发挥出了服务器的IO能力；
其次，各个核的处理逻辑独立，减少了操作系统调度和NUMA结构的影响；
就算各个核之间需要通讯，seastar也提供了很好的通讯机制来避免加锁。 -
充分利用了C++语言的新特性
高性能的网络框架毫无疑问应该设计成纯异步非阻塞的。但是异步代码难写难调试，开发周期太长。seastart利用了Futures and promises这样的C++语言特性，使得代码可以同步编写异步执行，降低了心智负担，又不会带来性能的损失。
seastar会带来什么改变
我认为seastar并不仅仅只是又一个网络框架的轮子而已，它的出现将会改变一些领域的玩法：
- 倍数的性能提升，以及可以随着核数增加而线性增加的性能，使得很多不得不依赖分布式解决的问题可以依赖单机解决，并且获得更高的吞吐量和更低的成本。特别是纯网络服务一类的应用，例如DNS POD分享的经验，之前做了很多分布式的方案来解决大量域名托管的问题，后来硬件水平上去了就可以简单粗暴的单机解决。
典型的应用有：NTP服务，DNS服务，cache服务，内存数据库等。seastar能够让这类服务的硬件成本缩减数倍。 - 云上的微服务，其通讯不再使用TCP/IP了，而是有特定的系统调用来专门发给特定的类似seastar写成的服务进程。让微服务的开发更简单，又能充分榨干网络服务器的性能。
- 在高带宽低延迟的场景，seastar能够让团队快速开发出满足要求的应用。典型的是实时音视频传输的场景，流量又大，对延迟又敏感，传统的nginx一类的网络服务框架，在seastar面前黯然失色。
对这个框架也有一些期待：
- 希望尽快有rust语言的版本，系统编程领域，rust才是未来；
- 希望有支持seastar框架的容器环境；（毕竟DPDK不是操作系统内置的协议栈）
希望这个发现对你也有用，have fun
原文链接
我的公众号：
