关于API网关性能

Posted 2021-05-18 隔壁王书

API网关通常位于流量的入口，负责对进出的流量进行加工处理。当然，大到整个公司的流量，小到一个服务的入口，都可以有网关，无非规模不同，功能多少不一，但本质上都是对流量就行控制。
网上关于API网关的文章有很多，但是大多内容比较空洞。我接下来准备分几个主题，每个主题都旨在解决一类问题。大家不妨站在开发者的角度上想一想，如果是你，你会怎样解决这些问题。
这次先说的是关于API网关“性能”的内容。

网关作为流量的入口，需要处理极大量的并发请求，对一个大型网关而言，峰值QPS往往会达到百万级别，因此，对网关而言，性能是必须重点考虑的一个因素。
当前主流的服务架构，一般都是在配置比较高的硬件服务器上划分出很多容器，根据请求量的大小，进行横向扩容/缩容。
一个粗略的网关系统的架构，大致是下面这个样子的：

这一篇，只讲API网关这一层的性能。
硬件本身的性能是一定的，因为硬件本身的资源是一定的，这里和资源相关的性能是指机器的性能，比如磁盘每秒能转多少圈，CPU每秒能进行多少次运算，网卡每秒能传输多少数据，等等。
这一层的性能不是我们要讨论的，我们服务端开发人员也无能为力，这一层的性能只能靠搞硬件的大神们了。不过，摩尔定律差不多已经失效的今天，除了量子计算之外，传统的计算机硬件性能可提升的空间应该已经极其极其有限了。

我们回到软件的性能上来，理论上，我们谈到软件性能时，基本上就是指在有限的硬件资源下，在保证服务的响应时间（后续用rt代替）在一定范围内时，每秒可以处理的请求数（后续用qps代替）。请求数越大，性能就越好，或者对于API网关来说，用另一个词更合适一些：吞吐量。
举个例子，一个请求的rt是10ms，同样配置的机器，网关A可以保证qps=100时，rt=10ms不变，另一个网关B，可以保证qps=1000时，rt=10ms不变，我们说网关B的性能更好，其实是网关B的吞吐量更高。
对于服务响应时间，补充一点，服务响应的rt = 网关层的耗时 + 下游服务的耗时。我们假设下游服务的耗时是一直稳定的，至于怎样保证下游读物耗时一直稳定，那是下游的事情，这里我们只考虑网关层的耗时。

所以，应该怎样提升网关的性能（吞吐量）呢？
等等，在回答这个问题之前，还有一个更重要的问题，为啥要提高网关的性能？
因为要节约成本啊，10台机器可以搞定的事情，如果现在用1台就能搞定，那肯定能省很多钱。或者，更高尚一些，能为这个星球节省一些资源，毕竟，程序员们都是心怀宇宙的。

好，回到刚才的问题，怎样提升网关的性能呢？
答：性能和耗时是成反比的，因此，提升性能=缩短耗时。
网关的耗时基本由3部分组成：

• 等待请求的数据传过来
• 等下游服务响应
• 网关本身的数据处理

1和2，显然没办法，这是网络传输和下游服务的事。
至于第3点，数据就那么多，算法也摆在那，貌似也没办法缩短时间。并发很低的情况下，确实是这样的，但是，并发很高的场景下，比如网关系统，情况就发生了变化。这个变化很重要，具体变化是：比如我们的机器时4核的，当并发是4的时候，每个核处理一个请求，刚刚好，耗时就是上面的1+2+3.但是当并发很大，比如4000的时候，就会冒出来第4个耗时：线程切换的耗时。

线程切换是怎么回事？不解释，网上一搜一大把。
线程切换为什么会耗时？同上。
怎么缩短线程切换的耗时？切换的少了就耗时少了。
怎么降低线程切换频率？少创建一些线程就行了。
可是并发那么多，线程少了怎么处理的过来？IO多路复用
IO多路复用是什么？不解释，网上一搜一大把。
最后，我一直认为，但凡性能问题，说到底都是软件（使用硬件的方式）问题和硬件问题（计算速度）。
硬件不多说，看自己电脑配置。
软件这里推的是我正在使用的Eolinker，国产的开源API网关，团队开发也有专门的客服，比其他个人开发的使用体验更好，感兴趣可以自己试试：www.eolinker.com