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