API Gateway

目录

简介

API gateway 处于客户端与各个微服务之间，它担任了反向代理的角色，将不同的请求路由到相对应的微服务中去。与此同时，它还有以下功能：安全，限流，缓存，日志，监控，重试，熔断等。

API Gateway在当代云原生架构下是不可或缺的一部分，起到了路由、认证、转换、缓存、监控和安全性等多个方面的作用，帮助简化和管理复杂的API调用和后端服务集成。^2

• 路由和转发请求： API Gateway充当了客户端和后端服务之间的代理，接收并路由传入的请求到相应的后端服务。它可以根据请求的特征（如URL、HTTP方法、请求头等）进行路由决策，将请求转发到适当的服务。
• 认证和授权： API Gateway可以集成身份验证和授权机制，以确保只有经过身份验证的用户可以访问受保护的API。它可以处理用户认证、生成和验证访问令牌、执行访问控制策略等。
• 请求转换和协议转换： API Gateway可以根据需要转换请求和响应的格式、协议和数据结构。它可以将请求和响应从一个协议转换为另一个（例如，从HTTP转换为WebSocket），或者对数据进行格式转换（如JSON到XML的转换）。
• 缓存和性能优化： API Gateway可以缓存经常请求的数据或响应，以减轻后端服务的负载并提高响应速度。它还可以执行一些性能优化措施，如请求合并、数据压缩和负载均衡，以提供更好的性能和可伸缩性。
• 监控和日志记录： API Gateway可以收集和记录关于API的使用情况、性能指标和错误日志等信息。这些信息可以用于监控API的健康状况、分析用户行为、进行故障排查和进行容量规划。
• 安全性和防御措施： API Gateway可以提供安全性功能，如防止DDoS攻击、请求限制、访问速率控制和有效载荷验证。它还可以执行输入验证和过滤，以防止恶意请求和安全漏洞的利用。

分类^3

• 业务网关:业务网关更靠近我们的业务，也就是与服务器应用层打交道，那么有很多应用层需要考虑的事情就可以依托业务网关。业务网关作为微服务体系中的核心基础设施，一般需要具备接口管理、协议适配、熔断限流、日志输出、数据加密、安全防护等功能。
• 流量网关:流量网关，顾名思义就是控制流量进入集群的网关，有很多工作需要在这一步做，对于一个服务集群，势必有很多非法的请求或者无效的请求，这时候要将请求拒之门外，降低集群的流量压力。

可选^1

• java - Gravitee
• 仓库：https://github.com/gravitee-io
• 官网：https://www.gravitee.io/

• 点评: 功能非常全,自带的dashboard也非常好用

• java - Zuul: Netflix Zuul，作为Spring cloud 中的一员，作为其中的api gateway，为服务架构提供前置保护作用。属于Spring cloud体系中，所以基于Java， Spring boot ，可以更好的集成到系统中。

• 仓库：https://github.com/Netflix/zuul

• 点评: 用Spring Cloud全家桶首选

• java - Sentinel

• 仓库：https://github.com/alibaba/Sentinel

• Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

• java - Soul

• 仓库：https://github.com/apache/shenyu

• golang - manba

• 仓库：https://github.com/fagongzi/manba
• 点评: 全开源，自主可控性高

• 最后一个版本2019年4月

• golang - Tyk

• 仓库：https://github.com/TykTechnologies/tyk
• 官网：https://tyk.io/

• 点评: 功能较全，但是授权方面是个问题，性能较差，几乎垫底。

• golang - Goku / Apinto

• 仓库：https://github.com/eolinker/goku_lite 或 https://github.com/eolinker/apinto
• 官网：https://www.apinto.com/
• Goku 已停止维护，项目迁移至 Apinto 开始商业运作

• 据官网介绍其性能远超 Nginx 和 Kong

• goang - Gloo

• 仓库：https://github.com/solo-io/gloo

• 官网：https://docs.solo.io/

• golang - KrakenD / Lura

• 仓库：https://github.com/luraproject/lura
• 官网：https://www.krakend.io/

• 据官网介绍其性能远超 Kong

• golang - megaease/easegress

• 仓库： https://github.com/easegress-io/easegress

• Easegress是一个开源的云原生API Gateway和Service Mesh平台，专注于提供高性能、低延迟的API管理和流量控制解决方案。Easegress旨在简化和加速微服务架构的开发和管理过程。以下是Easegress的主要特点和功能：

  • 高性能和低延迟：Easegress采用异步非阻塞的设计，利用事件驱动的方式处理API请求，以实现高性能和低延迟。它具备高吞吐量和高并发处理能力，能够应对大规模的API流量。
  • 动态路由和负载均衡：Easegress支持动态路由功能，可以根据请求的路径、方法、头部等特征进行灵活的请求路由和转发。它还集成了负载均衡算法，以实现流量的均衡分发和高可用性。
  • 插件扩展和中间件支持：Easegress提供了丰富的插件系统和中间件支持，允许用户根据需求扩展和定制API网关的功能。它支持自定义插件和中间件的开发，包括认证、授权、限流、转换等，以满足各种安全性、性能和功能需求。
  • 高度可配置：Easegress具有灵活的配置选项，可以通过配置文件或API进行配置。它支持动态配置更新，无需重启服务即可实时生效，方便快捷地调整API网关的行为和设置。
  • 安全性和防御措施：Easegress提供了多种安全性功能，包括防止DDoS攻击、请求限制、访问速率控制和有效载荷验证。它还执行输入验证和过滤，以防止恶意请求和安全漏洞的利用。
  • 可观察性和监控：Easegress集成了实时监控和日志记录功能，可以收集和展示API的使用情况、性能指标和错误日志等信息。它还支持集成常见的监控工具和服务，如Prometheus和Grafana，以方便进行监控和故障排查。

• Openresty+Lua - Kong: Kong 是一个现成 的 api gateway 的解决方案，它在 nginx 上进行了开发。

• 官网：https://konghq.com/

• 点评: 开源版本功能基本够用，性能优于 Nginx

• Apisix

• 仓库：https://github.com/apache/apisix

为什么需要 gateway^4

那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:

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

API Gateway

更好的方式是采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。 通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。

API注册

业务方如何接入网关?一般来说有几种方式。

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

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

协议转换

内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位。

服务发现

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

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

服务调用

网关由于对接很多种不同的协议，因此可能需要实现很多种调用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用异步的方式，而Http、Dubbo都是支持异步的，比如apache就提供了基于NIO实现的异步HTTP客户端。 因为网关会涉及到很多异步调用，比如拦截器、HTTP客户端、dubbo、redis等，因此需要考虑下异步调用的方式，如果基于回调或者future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的方案，基于响应式进行改造。

性能

网关作为所有流量的入口，性能是重中之重，早期大部分网关都是基于同步阻塞模型构建的，比如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置于响应头中，方便排查问题。

隔离

比如线程池、http连接池、redis等应用层面的隔离，另外也可以根据业务场景，将核心业务部署带单独的网关集群，与其他非核心业务隔离开。

网关管控平台

这块也是非常重要的一环，需要考虑好整个流程的用户体验，比如接入到网关的这个流程，能不能尽量简化、智能，比如如果是dubbo接口，我们可以通过到git仓库中获取源码、解析对应的类、方法，从而实现自动填充，尽量帮用户减少操作；另外接口一般是从测试->预发->线上，如果每次都要填写一遍表单会非常麻烦，我们能不能自动把这个事情做掉，另外如果网关部署到了多个可用区、甚至不同的国家，那这个时候，我们还需要接口数据同步功能，不然用户需要到每个后台都操作一遍，非常麻烦。 这块个人的建议是直接参考阿里云、aws等提供的网关服务即可，功能非常全面。

其他

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

参考文献