【架构师】零基础到精通——网关详解

博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名退役Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
个人百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！

API网关

1、API网关是什么？

API网关是随着微服务（Microservice）概念兴起的一种架构模式。原本一个庞大的单体应用（All in one）业务系统被拆分成许多微服务（Microservice）系统进行独立的维护和部署，服务拆分带来的变化是API的规模成倍增长，API的管理难度也在日益增加，使用API网关发布和管理API逐渐成为一种趋势。一般来说，API网关是运行于外部请求与内部服务之间的一个流量入口，实现对外部请求的协议转换、鉴权、流控、参数校验、监控等通用功能。

2、为什么要做API网关？

在没有API网关之前，业务研发人员如果要将内部服务输出为对外的HTTP API接口。通常要搭建一个Web应用，用于完成基础的鉴权、限流、监控日志、参数校验、协议转换等工作，同时需要维护代码逻辑、基础组件的升级，研发效率相对比较低。此外，每个Web应用都需要维护机器、配置、数据库等，资源利用率也非常差。

2-1、Tomcat自身问题

• 缓存太多。Tomcat用了很多对象池技术，内存有限的情况下，流量一高很容易触发gc

• 内存copy。Tomcat默认用堆内存，所以数据需要读到堆内，而后端服务是Netty，有堆外内存，需要通过数次copy

• Tomcat读body是阻塞的。Tomcat的NIO模型和Reactor模型不一样，读body是Block的

• Tomcat对链接重用的次数是有限制的。默认是100次，当达到100次后，Tomcat会通过在响应头里添加Connection:close，让客户端关闭该链接，否则如果再用该链接发送的话，会出现400

2-2、Tomcat Buffer

Tomcat buffer 的关系图如下：

通过上面的图，我们可以看出，Tomcat 对外封装的很好，内部默认的情况下会有三次 copy。

3、基本功能

• 反向代理：类似于Nginx效果，实现外部HTTP请求反向代理转为内部RPC请求进行转发
• 动态发现：加入后端微服务中心，实现动态发现后端服务实例
• 负载均衡：根据后端服务的实例列表进行负载均衡分配
• 服务路由：可以根据请求URL中的参数进行不同服务的调用路由

4、功能设计

4-1、API发布

使用API网关的控制面，业务研发人员可以轻松的完成API的全生命周期管理，如下图所示：

业务研发人员从创建API开始，完成参数录入、DSL脚本生成；接着可以通过文档和MOCK功能进行API测试；API测试完成后，为了保证上线稳定性，管理平台提供了发布审批、灰度上线、版本回滚等一系列安全保证措施；API运行期间会监控API的调用失败情况、记录请求日志，一旦发现异常及时发出告警；最后，对于不再使用的API进行下线操作后，会回收API所占用的各类资源并等待重新启用。整个生命周期，全部通过配置化、流程化的方式，由业务研发人员全自助管理，上手时间基本在10分钟以内，极大地提升了研发效率。

4-2、配置中心

API网关的配置中心存放API的相关配置信息——使用自定义的DSL（Domain-Specific Language，领域专用语言）来描述，用于向API网关的数据面下发API的路由、规则、组件等配置变更。配置中心的设计上使用统一配置管理服务和本地缓存结合的方式，实现动态配置，不停机发布。API的配置如下图所示：

API配置的详细说明

• Name、Group：名字、所属分组
• Request：请求的域名、路径、参数等信息
• Response：响应的结果组装、异常处理、Header、Cookies信息
• Filters、FilterConfigs：API使用到的功能组件和配置信息
• Invokers：后端服务(RPC/HTTP/Function)的请求规则和编排信息

4-3、API路由

API网关的数据面在感知到API配置后，会在内存中建立请求路径与API配置的路由信息。通常HTTP请求路径上，会包含一些路径变量，考虑到性能问题，没有采用正则匹配的方式，而是设计了两种数据结构来存储。如下图所示：

一种是不包含路径变量的直接映射的MAP结构。其中，Key就是完整的域名和路径信息，Value是具体的API配置。

另外一种是包含路径变量的前缀树数据结构。通过前缀匹配的方式，先进行叶子节点精确查找，并将查找节点入栈处理，如果匹配不上，则将栈顶节点出栈，再将同级的变量节点入栈，如果仍然找不到，则继续回溯，直到找到（或没找到）路径节点并退出。

4-4、功能组件

当请求流量命中API请求路径进入服务端，具体处理逻辑由DSL中配置的一系列功能组件完成。网关提供了丰富的功能组件集成，包括链路追踪、实时监控、访问日志、参数校验、鉴权、限流、熔断降级、灰度分流等，如下图所示：

4-5、协议转换&服务调用

API调用的最后一步，就是协议转换以及服务调用了。网关需要完成的工作包括：获取HTTP请求参数、Context本地参数，拼装后端服务参数，完成HTTP协议到后端服务的协议转换，调用后端服务获取响应结果并转换为HTTP响应结果。

上图以调用后端RPC服务为例，通过JsonPath表达式获取HTTP请求不同部位的参数值，替换RPC请求参数相应部位的Value，生成服务参数DSL，最后借助RPC泛化调用完成本次服务调用。

4-6、高性能设计

4-7、稳定性保障

提供了一些常规的稳定性保障手段，来保证自身和后端服务的可用性。如下图所示：

• 流量管控：从用户自定义UUID限流、App限流、IP限流、集群限流等多个维度提供流量保护
• 请求缓存：对于一些幂等的、查询频繁的、数据及时性不敏感的请求，业务研发人员可开启请求缓存功能
• 超时管理：每个API都设置了处理超时时间，对于超时的请求，进行快速失败的处理，避免资源占用
• 熔断降级：支持熔断降级功能，实时监控请求的统计信息，达到配置的失败阈值后，自动熔断，返回默认值

4-8、故障自愈

API网关服务端接入了弹性伸缩模块，可根据CPU等指标进行快速扩容、缩容。除此之外，还支持快速摘除问题节点，以及更细粒度的问题组件摘除。

4-9、可迁移

对于一些已经在对外提供API的Web服务，业务研发人员为了减少运维成本和后续的研发提效，考虑将其迁移到API网关。对于一些非核心API，可以考虑使用灰度发布功能直接迁移。但是对于一些核心API，上面的灰度发布功能是机器级别的，粒度较大，不够灵活，不能很好的支持灰度验证过程。

4.9-1、解决方案

API网关为业务研发人员提供了一个灰度SDK，接入SDK的Web服务，可在识别灰度流量后转发到API网关进行验证。灰度哪些API、灰度百分比可以在API网关管理端动态调节，实时生效，业务研发人员还可以通过SPI的方式自定义灰度策略。灰度验证通过后，再把API迁移到API网关，保障迁移过程的稳定性。

4.9-2、灰度过程

灰度前：在API网关管理平台创建API分组，域名配置为目前使用的域名。在Oceanus上，原域名规则不变。

灰度中：在API网关管理平台开启灰度功能，灰度SDK将灰度流量转发到网关服务，进行验证。

灰度后：通过灰度流量验证API网关上的API配置符合预期后再迁移。

4-10、自动生成DSL

业务研发人员在实际使用网关管理平台时，我们尽量通过图形化的页面配置来减轻DSL的编写负担。但服务参数转换的DSL配置，仍然需要业务研发人员手工编写。一般来说，生成服务参数DSL的流程是：

• 引入服务的接口包依赖
• 拿到服务参数类定义
• 编写Testcase生成JSON模板
• 填写参数映射规则
• 最后手工录入管理平台，发布API

整个过程非常繁琐，且容易出错。如果需要录入的API多达几十上百个，全部由业务研发人员手工录入的效率是非常低下的。

解决方案

那么能不能将服务参数DSL的生成过程给自动化呢？ 答案是可以的，业务RD只需在网关录入API文档信息，然后录入服务的Appkey、服务名、方法名信息，API网关管理端会从最新发布的服务框架控制台获取到服务参数的JSON Schema信息，JSON Schema定义了服务参数的类型和结构信息，管理端可根据这些信息，自动生成服务参数的JSON Mock数据。结合API文档的信息，自动替换参数名相同的Value值。 这套DSL自动生成方案，使用过程中对业务透明、标准化，业务方只需升级最新版本服务框架即可使用，极大提升研发效率，目前受到业务研发人员的广泛好评。

4-11、API操作提效

快速创建API

API网关的核心能力是建立在API配置的基础上的，但提供强大功能的同时带来了较高的复杂性，不少业务研发人员吐槽API配置太繁琐，学习成本高。快速创建API的功能应运而生，业务研发人员只需要提供少量的信息就可以创建API。快速创建API的功能当前分为4种类型（后端RPC服务API、后端HTTP服务API、SSO CallBack API、Nest API），未来会根据业务应用场景的不同，提供更多的快速创建API类型。

批量操作

业务研发人员在API网关上，需要管理非常多的业务分组，每个业务分组，最多可以有200个API配置，多个API可能有很多相同的配置，如组件配置，错误码配置和跨域配置的。每个API对于相同的配置都要配置一遍，操作重复度很高。因此API网关支持批量操作多个API：勾选多个API后，通过【批量操作】功能可一次性完成多个API配置更新，降低业务重复配置的操作成本。

API导入导出

API网关提供在不同研发环境相互导入导出API的能力，业务研发人员在线下测试完成后，只需要使用API导入导出功能，即可将配置导出到线上生产环境，避免重复配置。

4-12、自定义组件

API网关提供了丰富的系统组件完成鉴权、限流、监控能力，能够满足大部分的业务需求。但仍有一些特殊的业务需求，如自定义验签、自定义结果处理等。API网关通过提供加载自定义组件能力，支持业务完成一些自定义逻辑的扩展。下图是自定义组件实现的一个实例。getName中填写自定义组件申请时的名称，invoke方法中实现自定义组件的业务逻辑，如继续执行、进行页面跳转、直接返回结果、抛出异常等。

4-13、服务编排

一般情况下，网关上配置的一个API对应后端一个RPC或者HTTP服务。如果调用端有聚合和编排后端服务的需求，那么有多少后端服务，就必须发起多少次HTTP的请求调用。由此就会带来一些问题，调用端的HTTP请求次数过多，效率低，在调用端聚合服务的逻辑过重。

服务编排的需求应运而生，服务编排是对既有服务进行编排调用，同时对获取的数据进行处理。主要应用在数据聚合场景：一次HTTP请求返回的数据需要调用多个或多次服务（RPC或HTTP）才能获取到完整的结果。

通过独立部署的方式提供服务编排能力，API网关与服务编排服务之间通过RPC进行调用。这样可以解耦API网关与服务编排服务，避免因服务编排能力影响集群上的其他服务，同时多一次RPC调用并不会有明显耗时增加。使用上对业务研发人员也是透明的，非常方便，业务研发人员在管理端配置好服务编排的API，通过配置中心同时下发到API网关服务端和服务编排服务上，即可开始使用服务编排能力。整体的交互架构图如下：