吹爆什么意思是什么 被吹爆了的API网关，到底是什么？

假设你刚好是一个后端开发人员，你的老板只是让你开发一个网站，这个网站涉及到很多后端的微服务，比如会员、商品、推荐服务等等。

那么这里就有问题了。APP/Browser如何访问这些后端服务？

如果业务简单，您可以为每个业务分配一个独立的域名(https://service.api.company.com)，但这种方式有几个问题:

每个业务都会需要鉴权、限流、权限校验等逻辑，如果每个业务都各自为战，自己造轮子实现一遍，会很蛋疼，完全可以抽出来，放到一个统一的地方去做。如果业务量比较简单的话，这种方式前期不会有什么问题，但随着业务越来越复杂，比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作，如果每一个微服务都分配一个域名的话，一方面客户端代码会很难维护，涉及到数百个域名，另一方面是连接数的瓶颈，想象一下你打开一个APP，通过抓包发现涉及到了数百个远程调用，这在移动端下会显得非常低效。每上线一个新的服务，都需要运维参与，申请域名、配置Nginx等，当上线、下线服务器时，同样也需要运维参与，另外采用域名这种方式，对于环境的隔离也不太友好，调用者需要自己根据域名自己进行判断。另外还有一个问题，后端每个微服务可能是由不同语言编写的、采用了不同的协议，比如HTTP、Dubbo、GRPC等，但是你不可能要求客户端去适配这么多种协议，这是一项非常有挑战的工作，项目会变的非常复杂且很难维护。后期如果需要对微服务进行重构的话，也会变的非常麻烦，需要客户端配合你一起进行改造，比如商品服务，随着业务变的越来越复杂，后期需要进行拆分成多个微服务，这个时候对外提供的服务也需要拆分成多个，同时需要客户端配合你进行改造，非常蛋疼。

应用编程接口网关

更好的办法是采用API网关，实现一个API网关来接管所有的入口流量，类似于Nginx，将用户的所有请求转发给后端服务器，但是网关不仅仅是简单的转发，还扩展了流量。

比如认证、限流、权限、保险丝、协议转换、错误码统一、缓存、日志、监控、报警等。，使得公共逻辑由网关提取并完成，服务端可以更加关注业务逻辑，提高迭代效率。

通过引入API网关，客户端只需要与API网关进行交互，而不需要与各业务方的接口进行通信。但是多引入一个组件就多引入了一个潜在的失效点，所以实现一个高性能稳定的网关会涉及到很多点。

API注册

业务方如何访问网关？一般来说，有几种方式。

第一种采用插件扫描业务方的API，比如Spring MVC的注解，并结合Swagger的注解，从而实现参数校验、文档&&SDK生成等功能，扫描完成之后，需要上报到网关的存储服务。手动录入。比如接口的路径、请求参数、响应参数、调用方式等信息，但这种方式相对来说会麻烦一些，如果参数过多的话，前期录入会很费时费力。

配置文件导入。比如通过SwaggerOpenAPI等，比如阿里云的网关:

协议转换

内部应用编程接口可以通过许多不同的协议来实现，如超文本传输协议、杜博协议、GRPC协议等。，但是很多对用户不是很友好，或者根本不能对外公开，比如Dubbo服务，所以需要在网关层做一个协议转换，把用户的HTTP协议请求转换成底层对应的协议，比如HTTP-> Dubbo，但是这里有很多需要注意的问题，比如参数类型。如果类型不对，导致转换问题，日志不够详细，问题就很难定位。

服务发现

作为流量的入口，网关负责转发请求，但首先需要知道转发给谁，如何处理。这里有几种方法:

写死在代码/配置文件里，这种方式虽然比较挫，但也能使用，比如线上仍然使用的是物理机，IP变动不会很频繁，但扩缩容、包括应用上下线都会很麻烦，网关自身甚至需要实现一套健康监测机制。域名。采用域名也是一种不错的方案，对于所有的语言都适用，但对于内部的服务，走域名会很低效，另外环境隔离也不太友好，比如预发、线上通常是同一个数据库，因此网关读取到的可能是同一个域名，这时候预发的网关调用的就是线上的服务。注册中心。采用注册中心就不会有上述的这些问题，即使是在容器环境下，节点的IP变更比较频繁，但节点列表的实时维护会由注册中心搞定，对网关是透明的，另外应用的正常上下线、包括异常宕机等情况，也会由注册中心的健康检查机制检测到，并实时反馈给网关。并且采用注册中心性能也没有额外的性能损耗，采用域名的方式，额外需要走一次DNS解析、Nginx转发等，中间多了很多跳，性能会有很大的下降，但采用注册中心，网关是和业务方直接点对点的通讯，不会有额外的损耗。

服务调用

因为网关接口有很多不同的协议，可能需要实现很多调用模式，比如Http和Dubbo。出于性能原因，最好采用异步模式，而HTTP和Dubbo都支持异步。比如apache提供基于NIO的异步HTTP客户端。

因为网关涉及很多异步调用，比如拦截器、HTTP客户端、dubbo、redis等。，有必要考虑异步调用模式。如果是基于回调或者未来的话，代码会嵌套很深，可读性很差。因此，我们可以参考zuul和spring cloud gateway的解决方案，并根据响应进行改革。

优雅离线

优雅的离线也是网关需要注意的问题。网关底层涉及很多协议，比如HTTP、Dubbo，HTTP可以细分，比如域名、注册中心。推荐:一张图告诉你为什么是服务网关。

其中一些支持优雅的注销。比如Nginx本身就支持健康监测机制。如果检测到某个节点已挂起，它将被删除。对于应用的正常注销，需要先结合发布系统进行逻辑注销，然后直接将失败返回给后续的Nginx健康监测请求(比如直接返回500)，然后等待一段时间(根据Nginx配置确定)，再实际注销应用。

另外，报名中心其实也差不多。注册中心一般只支持手动注销，在逻辑注销阶段可以调用注册中心的接口注销节点。但是，有些不支持主动注销，这需要结合缓存配置来延迟应用程序注销。此外，它类似于其他原则，如杜博。

演出

作为所有流量的网关，性能最重要。早期大多数网关都是基于同步阻塞模型构建的，比如Zuul 1.x但是我们都知道每个请求/连接都会占用一个线程，线程在JVM中是一个很重的资源。

例如，Tomcat默认有200个线程。如果网关隔离做得不好，当上游服务因为网络延迟、FullGC、慢第三方服务等而延迟时。，线程池将很容易被填满，新的请求将被拒绝。但是此时线程实际上在IO上被阻塞了，系统资源没有得到充分利用。

另一方面，容易受到网络和磁盘IO延迟的影响。有必要仔细设置超时。如果设置不当，服务隔离不完善，网关很容易被慢接口拖垮。

异步模式完全不同。通常，CPU内核可以启动一个线程来处理所有的请求和响应。一个请求的生命周期不再固定在一个线程上，而是会分成不同的阶段，由不同的线程池来处理，使系统的资源得到充分利用。

而且因为一个线程不再被某个连接独占，一个连接占用的系统资源会低很多，就一个文件描述符加几个监听器等等。在阻塞模型中，每个连接都会独占一个线程，线程是一个非常重的资源。上游服务的延迟也可以大大缓解，因为在阻塞模式下，慢请求会独占一个线程资源，而异步后，由于单个连接占用的资源变得非常少，系统可以同时处理大量请求。

在JVM平台的情况下，Zuul 2、Spring Cloud gateway等等都是不错的异步网关选择，也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的异步支持自行开发

高速缓存

对于一些幂等的get请求，可以根据服务端指定的缓存头在网关级做一层缓存，存储在Redis等二级缓存中。这种重复的请求可以在网关级别直接处理，而不会触及服务线，从而减轻了服务端的压力。另外，如果服务端节点挂机，网关可以返回自己的缓存。

限流

可以说，限流是每个业务组件的必备组件。如果限流做得不好，当请求量突然增加时，业务端的服务很容易挂断。例如，双11和双12升级时，接口的请求量是平时的几倍。如果容量没有评估好，没有进行限流，整个服务很容易不可用。因此，需要根据业务端接口的处理能力制定限流策略。

因此，必须在接入层做好限流策略。对于非核心接口，我们可以直接降级，以保证核心服务的可用性。对于核心接口，我们需要根据试压时获得的接口容量制定相应的限流策略。电流限制有几种类型:

单机。单机性能比较高，不涉及远程调用，只是本地计数，对接口RT影响最小。但需要考虑下限流数的设置，比如是针对单台网关、还是整个网关集群，如果是整个集群的话，需要考虑到网关缩容、扩容时修改对应的限流数。分布式。分布式的就需要一个存储节点维护当前接口的调用数，比如redis、sentinel等，这种方式由于涉及到远程调用，会有些性能损耗，另外也需要考虑到存储挂掉的问题，比如redis如果挂掉，网关需要考虑降级方案，是降级到本地限流，还是直接将限流功能本身降级掉。

另外还有不同的策略:简单计数、令牌桶等。其实大多数场景简单的计数就够了，但是如果需要支持突发流量等场景，可以使用令牌桶等方案。还需要考虑当前限制是基于什么，例如IP、接口、用户维度或请求参数中的一些值。这里可以用表达式，比较灵活。

稳定

稳定性是网关非常重要的一部分，监控和告警需要完善，比如监控与接口调用量、响应时间、异常、错误代码、成功率相关的告警，一些与线程池相关的，比如活动线程数、队列积压，还有一些系统级的，比如CPU、内存、FullGC。

网关是所有业务的入口，对网关稳定性的要求高于其他业务。最好一直稳定运行，尽量少重启。然而，当添加新功能或添加日志来解决问题时，不可避免地会重新发出它们。所以可以参考zuul的方法，基于不同的拦截器实现所有核心功能。拦截器的代码用Groovy编写，存储在数据库中。支持动态加载、编译、运行，这样出了问题就能第一时间定位并解决。如果网关需要开发新的功能，只需要添加新的拦截器，动态添加到网关中，不需要重新发布。

保险丝退化

熔断机制也是很重要的一个。如果某个服务挂起，接口响应严重超时等。，整个网关可能会被一个接口拖垮，所以要加熔丝降级。当出现特定异常时，接口降级会直接由网关返回，可以基于Hystrix或Resilience4j实现。

杂志

由于所有请求都由网关处理，日志也需要相对完善，比如耗时的接口、请求模式、请求IP、请求参数、响应参数(注意脱敏)等。此外，因为可能涉及许多微服务，所以有必要提供一个统一的traceId，以方便所有日志的关联，并且可以将该traceId放在响应头中，以方便故障排除。

网关管控平台

这也是很重要的一部分。需要考虑整个流程的用户体验。例如，访问网关的过程可以尽可能地简化和智能化。例如，如果是一个dubbo接口，我们可以获取源代码并在git仓库中进行分析。对应的类和方法，从而实现自动填充，尽量帮助用户减少操作；另外，界面一般是从测试-->:高级-->:在线，如果每次填表格都很麻烦，可以自动完成吗？另外，如果网关部署在多个可用区域甚至不同国家，那么此时我们还需要接口数据同步功能，否则用户需要在每个后台操作一次，非常麻烦。

这个个人建议是直接参考阿里巴巴云和aws提供的网关服务，功能非常全面。

其他的

还有一些其他需要考虑的点，比如接口模拟、文档生成、sdk代码生成、错误代码统一、服务治理相关等。，这里就不描述了。

总结

目前网关是集中式架构，所有的请求都需要经过网关一次。所以当有大的提升或者流量突然增加的时候，网关就有可能成为性能瓶颈。当网关接入大量接口时，做好流量评估不是一件容易的事情。每次大的推广之前，都要和业务端一起对接口进行压力测试，评估大概的容量，对网关进行扩展。此外，网关是所有流量的入口，所有请求都由网关处理。

可以参考目前流行的ServiceMesh，采用一种分散的方案，将网关的逻辑沉入sidecar。sidecar和应用程序部署到同一个节点，并接管应用程序的流入和流出。这样你只需要对相关服务进行测试，有针对性的扩容即可。

另外，升级会更流畅，更集中。即使是灰度发布，理论上所有业务方的流量都会流入新版网关。出了问题，会影响所有业务。但是这种分散的方式可以先把非核心业务升级，再全推上线。此外，ServiceMesh的解决方案对多语言支持也更加友好。