字数

4765 字

阅读时间

18 分钟

网关实现过程中重点问题的解决和优化

运用责任链模式进行解决网关扩展性问题

1. 发现耦合度过高的问题，扩展性很低：在实现负载均衡过滤器，路由转发过滤器，限流过滤器等网关功能的时候，每添加一个功能，就需要将请求按照模块设置的不同的顺序进行重新构建请求执行流程，如果不考虑后续会加入的模块，可以直接设置好每个功能的执行顺序，将请求依次执行，但是如果后续需要进行扩展过滤器的时候，会发现必须改变一些过滤器的执行逻辑，才能实现想要的执行流程，最终导致耦合度过高，不利于维护代码和后期的扩展。
2. 扩展性优化：使用责任链模式进行设计一个过滤器链，将每一个功能都变成一个过滤器，因为每个过滤器执行的顺序不一样，所以在设计普通过滤器链的基础设计成一个有顺序的过滤器链，添加完所有过滤器进入过滤器链的时候，通过sort进行排序过滤器，得到有序的过滤器链，过滤器链是由多个过滤器组成的，根据过滤器自身规则和顺序，过滤器链有序的执行每个过滤器就，一个过滤器执行完毕过滤流程之后，会转发该请求到下一个过滤器继续执行。具体实现如下：
   1. **过滤器顶级接口设计**：过滤器顶级接口设计，进行定义执行过滤器链的doFilter方法和返回过滤器顺序的getOrder()方法，通过反射进行返回过滤器定义的顺序。通过这两个方法进行设计后续过滤器。如图4.1为接口设计的核心代码。
   2. **GatewayContext的创建**：每个请求的信息都会被封装到 GatewayContext 中，也就是包含了请求以及请求响应，并且包含了一系列的参数信息，如请求，响应，配置中心的配置以及重试次数，上下文状态等，最后根据这个网关上下文，进行构建过滤器链。
   3. **过滤器链工厂**：每个请求都可能触发不同的过滤器链规则，所以需定义一个过滤器链工厂接口，这个接口定义了构建过滤器链条和通过过滤器ID获取过滤器这两个方法，通过对过滤器链工厂的实现达到为每个请求生成特定的过滤器链。 在过滤器工厂实现中通过ServiceLoader.load(Filter.class)(SPI机制)对Fliter顶级接口进行加载得到全部对Fliter接口的实现的类。得到如下图的过滤器SPI加载配置。 然后加载的配置能够获取到过滤器顶级接口Filter对应的实现，通过反射得到过滤器的id，如果反射得到过滤器id不为空，则将过滤器id和对应的过滤器实现放入map缓存中，方便后期的获取。 通过上面可以实现出一个有序执行的过滤器链。

网关网络通信的搭建

Netty客户端

Netty客户端在网关中的主要功能是启动网关的时候，会通过异步客户端构建器进行创建和管理基于Netty的异步HTTP客户端。具体实现如下：

1. AsyncHttpClient异步HTTP客户端参数设置 进行设置事件循环组的个数，以及设置连接超时事件，设置请求超时时间，设置最大重定向次数以及设置最大的连接数，最后创建出AsyncHttpClient异步HTTP客户端，然后创建出的这个异步HTTP客户端的配置将会等待路由转发过滤器进行请求转发。如图为配置AsyncHttpClient异步HTTP客户端参数核心代码。
2. 启动和关闭流程实现 并且还提供了start()方法进行启动客户端，进行初始客户端模块，进行请求进入前请求转发的准备，最后发送完毕后，会进行shutdown()，如果如果客户端实例不为空，则关闭客户端释放资源。

Netty服务端

Netty服务端在网关中的主要功能是启动网关的时候进行监控绑定配置的端口，然后根据请求构建网关请求上下文和执行过滤器链，具体实现如下：

1. ServerBootstrap模块 负责进行配置和启动服务器的Netty ServerBootstrap对象，通过传入事件循环对象，进行配置请求的服务器参数，进行建立服务器端的套接字通道，以及使用编解码器进行数据编码，将请求报文聚合成FullHttpRequest类型，然后启动服务器。
2. Netty服务器的处理器模块 负责将请求进行处理，通过传递请求的信息msg和通道上下文ctx进行封装为对象传递进入执行请求的逻辑模块，在请求执行逻辑块中，执行逻辑块将进行构建网关请求上下文和执行过滤器链用于处理请求，当请求结束的时候，将进行关闭服务器，释放资源。 通过上面的详细实现，得到下面的Netty服务端流程图。

客户端和服务端的关系

由于网关需要接受用户请求，又要做请求向其他服务的发送，所以我们设置了客户端和服务端，用客户端从网关向其他地方发送消息，用服务端接收用户发送过来的请求进行处理。

网关配置中心和注册中心的实现

配置中心

Nacos提供了许多强大的功能，其中一个就是Nacos提供了一个可视化的控制台方便对实例等信息进行管理。 同时Nacos提供了动态配置服务，可以动态化的方式管理所有环境的应用配置和服务配置，并且Nacos的社区相对其他的来说更加活跃，代码也更加容易阅读，所以选择使用Nacos作为配置中心，具体实现如下：

1. 配置中心接口实现 定义一个配置中心接口来进行初始化配置中心配置以及配置中心信息变更监听事件方法，然后传入配置中心地址和环境进行初始化，以及当订阅配置中心的配置变更的时候进行实时监听变更事件。
2. 配置拉取实现 进行了配置中心接口的定义后，需要进行配置的拉取，先需要进行引入Nacos的Client，然后可以通过Nacos提供的configService，通过这个类的方法根据DataId和Group就可以进行快速的拉取Nacos设置的配置，然后进行解析JSON获取到配置，转换为自定义数据。
3. 配置变更事件订阅 当配置进行变更的时候需要进行订阅，使用Nacos提供的configService的addListener方法通过在网关配置的DataId和Group的参数将会向Nacos的监听器列表中添加一个监听器，当Nacos的配置发生变更之后，就可以监听到这个事件，并且将配置进行更新。如图为配置变更事件订阅的核心代码实现。

注册中心

Nacos提供了许多强大的功能，其中一个就是Nacos提供了一个可视化的控制台方便对实例等信息进行管理。 比如服务发现、健康检测。Nacos还提供对服务的实时的健康检查，阻止向不健康的主机活服务发送请求。 并且Nacos的社区相对其他的来说更加活跃，代码也更加容易阅读，所以选择使用Nacos作为注册中心，具体设计如下：

1. 编写注册中心接口 定义一个注册中心接口，进行定义初始化方法，注册方法，取消注册方法，服务订阅方法，通过这个接口，进行实现服务的初始化，注册，取消注册以及服务变更监控，实现完毕接口后，再定义一个监控方法进行监听注册中心的配置变更。
2. 服务信息加载 基于上面的服务注册与订阅接口，进行封装服务定义和服务实例，通过传入服务定义的服务ID，服务名字，以及端口号中心信息进行封装服务定义和服务实例，并且作为参数传入服务注册方法和订阅事件变更方法。如图4.17为服务信息加载的核心代码实现。
3. 实现将网关注册到注册中心 在服务注册方法设计中，使用Nacos客户端提供的NamingMaintainFactory和NamingFactory这两个服务注册方法向传入的服务定义和服务实例这两个参数进行注册服务定义和服务实例到Nacos中，然后通过端口号和ip以及服务唯一id进行构建nacos实例信息，然后进行注册服务id对应服务实例。
4. 实现服务的订阅 实现服务订阅，首先需要拉取Nacos上面的所有的服务的信息，由于服务信息会不断的更新变化，进行设计使用定时任务的方式不断的更新服务订阅信息。 实现对Nacos服务信息的订阅的时候，通过Nacos的事件监听器NamingEven事件对象进行，通过NamingEvent 进行监听和处理命名空间中的服务实例的变化，可以根据这些变化来动态地更新服务实例列表，如果服务发生了改变，通过拿到已经订阅的服务，从nacos拿到服务列表进行遍历，判断这些服务是否已经订阅了当前服务，如果当前服务之前不存在，则调用监听器方法进行添加处理，进行初始化，并且指定的服务和环境注册一个事件监听器，最后进行更新服务定义和服务实例，保持与注册中心的数据同步。

网关请求过滤器链的重点实现

负载均衡算法过滤器

网关的请求转发到后端服务的时候，可能会出现单一服务压力过大的情况，所以需要进行负载均衡，负载均衡算法的种类有很多种，可以适用于不同的场景下，这里将请求按照实现的负载均衡算法进行转发，达到将请求分散到各个服务，因此设计了一个负载均衡过滤器，具体实现如下：

1. 设计负载均衡接口 创建负载均衡接口，进行定义通过由请求构建的网关上下文拿到对应的服务实例方法和通过服务ID拿到服务实例这两个方法，获取根据负载均衡策略选择到的后端服务实例。
2. 轮询的负载均衡算法实现 对于实现轮询的负载均衡算法，需要维护一个全局的索引编号，并且每次执行都不断自增，进行获取到所有服务后，对服务实例数量进行取余，最后拿到服务实例信息，这样就实现了轮询算法获取后端服务实例。
3. 随机的负载均衡算法实现 实现随机的负载均衡算法， 通过得到的服务id，然后进行保存当前服务id对应的所有服务实例，进行获取所有服务后，从服务实例中随机返回一个即可，这样就实现了随机算法进行获取后端服务实例。

路由转发过滤器

路由转发是在网关处理完所有过滤逻辑后的最后一个操作，可以进行请求的修改，可以进行修改请求的各个部分，包括请求头、请求体、请求参数等，来适应目标服务的要求。具体实现如下：

1. 请求转发 使用的异步的方式去发送http请求,通过Netty配合AsyncHttpClient的方式来实现的异步IO通信功能，最后执行负载均衡策略将请求转发到后端的多个目标服务，以确保请求均匀地分发到不同的服务实例。
2. 请求重试 当请求出现IO异常或者请求超时的时候会进行一个请求重试，所以在路由过滤器中添加一个重试的函数进行再次执行路由过滤器， 每当出现现IO异常或者请求超时的时候都会再次调用重试函数，然后重试次数可以从配置中心进行获取来进行设定重试的次数。 上面这种方式已被废弃，因为我们完全可以通过resilience4j来做一次增强，将重试的功能直接交由更成熟的中间组件来实现

限流过滤器

网关限流设计中，对于限流这一块，需要在配置中心配置限流参数， 通过灵活地配置限流参数，实现根据路径进行限流。具体实现如下：

1. **设计一个限流接口** 创建一个限流通用接口，定义根据拿到配置中心限流的规则和服务ID，进行执行限流规则的方法。
2. **根据路径进行限流** 根据请求获取对应的限流配置参数，获取到指定的限流参数之后，根据路径进行限流，每当对应的请求到来时，就从缓存根据路径中获取对应的限流规则，如果能够获取到，说明存在限流，就开始进行限流逻辑，判断服务是否分布式、设定限流时间和次数等进行选择限流方法，如果是分布式选择Redis进行限流，否则选择Guaua实现令牌桶限流。
3. **基于Redis实现固定窗口限流算法** 根据获取到的限流规则，可以得到限流时间和次数，通过引入Redis里面的Jedis来进行操作，创建出一个JedisPoolConfig实例，用于配置连接池参数，进行设置连接池的最大连接数，设置连接池的最大空闲连接数，创建JedisPool实例，连接redis 连接池，最后调用jedis的evalsha方法，传入执行的redis的代码和限流时间以及次数，最后实现固定窗口限流。如图4.25为Redis实现固定窗口限流算法的核心代码实现。

熔断降级过滤器

网关项目使用的是基于resilience4j的熔断降级，需要将服务整合resilience4j，引入依赖之后，进行使用resilience4j编写熔断限流，需要在gateway.yaml或者配置中心的配置中添加出配置，熔断降级具体实现如下：

1. 熔断逻辑 因为执行逻辑是走过滤器的，所以在路由过滤器添加额外的对hystrix的配置，来监测最后转发请求的时候，如果请求路径是是设置的熔断降级触发的路径，需要进行设置重要的熔断超时时间参数，如果超时后中断执行线程，执行降级逻辑，如果路径不是熔断降级触发的路径，则正常进行执行请求转发的逻辑。
2. 实现降级逻辑 系统访问的高峰期的时候，此时要对部分服务进行降级操作，所以当触发熔断的时候，如果请求的时间超过设置的熔断时间，进行执行降级逻辑，在降级逻辑中，直接将数据返回客户端。
   这里会调用我们自定义的降级策略，来自定义我们在降级的时候会返回给前端什么数据。

本章小结

本章先进行介绍了网关实现过程中重点问题的解决和优化，并且进行了详细的解决过程中遇到的问题，并且最后给出了优化，然后进行了网关通信层的实现、网关配置中心的实现、注册中心的实现、网关规则的实现、网关过滤器链的实现、网关负载均衡算法的实现、网关路由的实现、网关重试和限流的实现、网关熔断降级的实现、通过实现这些有效的、可靠的和高性能的过滤器，确保了网关流程的逻辑正确性和效率，使网关变得更加高效、可靠、灵活和可管理。

贡献者

breatheCoder

文件历史

最后编辑于 大约 1 小时前查看完整历史

4b67a-优化启动脚本