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

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

API网关详解

  • API网关
    • 1、API网关是什么?
    • 2、为什么要做API网关?
      • 2-1、Tomcat自身问题
      • 2-2、Tomcat Buffer
    • 3、基本功能
    • 4、功能设计
      • 4-1、API发布
      • 4-2、配置中心
      • 4-3、API路由
      • 4-4、功能组件
      • 4-5、协议转换&服务调用
      • 4-6、高性能设计
      • 4-7、稳定性保障
      • 4-8、故障自愈
      • 4-9、可迁移
        • 4.9-1、解决方案
        • 4.9-2、灰度过程
      • 4-10、自动生成DSL
      • 4-11、API操作提效
      • 4-12、自定义组件
      • 4-13、服务编排

API网关

1、API网关是什么?

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

2、为什么要做API网关?

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

【架构师】零基础到精通——网关详解_第1张图片

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 的关系图如下:
【架构师】零基础到精通——网关详解_第2张图片

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

3、基本功能

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

4、功能设计

4-1、API发布

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

【架构师】零基础到精通——网关详解_第3张图片

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

4-2、配置中心

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

【架构师】零基础到精通——网关详解_第4张图片

API配置的详细说明

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

4-3、API路由

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

【架构师】零基础到精通——网关详解_第5张图片

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

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

4-4、功能组件

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

【架构师】零基础到精通——网关详解_第6张图片

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

API调用的最后一步,就是协议转换以及服务调用了。网关需要完成的工作包括:获取HTTP请求参数、Context本地参数,拼装后端服务参数,完成HTTP协议到后端服务的协议转换,调用后端服务获取响应结果并转换为HTTP响应结果。
【架构师】零基础到精通——网关详解_第7张图片

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

4-6、高性能设计

【架构师】零基础到精通——网关详解_第8张图片

4-7、稳定性保障

提供了一些常规的稳定性保障手段,来保证自身和后端服务的可用性。如下图所示:
【架构师】零基础到精通——网关详解_第9张图片

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

4-8、故障自愈

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

【架构师】零基础到精通——网关详解_第10张图片

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上,原域名规则不变。

【架构师】零基础到精通——网关详解_第11张图片

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

【架构师】零基础到精通——网关详解_第12张图片

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

【架构师】零基础到精通——网关详解_第13张图片

4-10、自动生成DSL

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

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

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

解决方案

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

【架构师】零基础到精通——网关详解_第14张图片

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方法中实现自定义组件的业务逻辑,如继续执行、进行页面跳转、直接返回结果、抛出异常等。

【架构师】零基础到精通——网关详解_第15张图片

4-13、服务编排

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

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

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

【架构师】零基础到精通——网关详解_第16张图片

你可能感兴趣的:(架构设计,java,开发语言,系统架构,架构)