今天听说了一个新的C++语言开发的网络框架，叫做seastar。

seastar有何特别之处呢？先看看官网提供的性能数据：

性能

  • HTTPD benchmark:


    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

  • Memcached Benchmark:
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++ 库》

通过官方文档可以了解到这些特性：

  1. 底层包处理的API不是epoll，而是DPDK

    有了DPDK，网卡中的包直接被传输到用户空间的buffer中，免去了内核协议栈的层层处理。当然这里还需要一个用户态的协议栈，使得可以以更少的内存和更小CPU消耗来处理大量的网络包。

    DPDK的使用门槛还是比较高的，而seastar已经把这个神器封装在了框架之中，实在是皆大欢喜。

  2. 无共享设计

    这也就是网络框架处理性能随着核数增加而增加的秘诀。

    首先，处理上是多核IO的，充分发挥出了服务器的IO能力；

    其次，各个核的处理逻辑独立，减少了操作系统调度和NUMA结构的影响；

    就算各个核之间需要通讯，seastar也提供了很好的通讯机制来避免加锁。

  3. 充分利用了C++语言的新特性

    高性能的网络框架毫无疑问应该设计成纯异步非阻塞的。但是异步代码难写难调试，开发周期太长。seastart利用了Futures and promises这样的C++语言特性，使得代码可以同步编写异步执行，降低了心智负担，又不会带来性能的损失。

seastar会带来什么改变

我认为seastar并不仅仅只是又一个网络框架的轮子而已，它的出现将会改变一些领域的玩法：

  1. 倍数的性能提升，以及可以随着核数增加而线性增加的性能，使得很多不得不依赖分布式解决的问题可以依赖单机解决，并且获得更高的吞吐量和更低的成本。特别是纯网络服务一类的应用，例如DNS POD分享的经验，之前做了很多分布式的方案来解决大量域名托管的问题，后来硬件水平上去了就可以简单粗暴的单机解决。

    典型的应用有：NTP服务，DNS服务，cache服务，内存数据库等。seastar能够让这类服务的硬件成本缩减数倍。
  2. 云上的微服务，其通讯不再使用TCP/IP了，而是有特定的系统调用来专门发给特定的类似seastar写成的服务进程。让微服务的开发更简单，又能充分榨干网络服务器的性能。
  3. 在高带宽低延迟的场景，seastar能够让团队快速开发出满足要求的应用。典型的是实时音视频传输的场景，流量又大，对延迟又敏感，传统的nginx一类的网络服务框架，在seastar面前黯然失色。

对这个框架也有一些期待：

  1. 希望尽快有rust语言的版本，系统编程领域，rust才是未来；
  2. 希望有支持seastar框架的容器环境；（毕竟DPDK不是操作系统内置的协议栈）

希望这个发现对你也有用，have fun

今天太开心了，因为我知道了seastar框架的

扫描二维码，在手机上阅读！