基于第25章 Nginx 的负载模型，第26章动态刷新 Nginx 的配置和实现，把网关算力节点动态刷新到 Nginx 配置中，完成动态负载的功能实现。
设计这里我们要实现的核心功能就是当有网关算力节点注册到注册中心的时候，可以被动态的配置到 Nginx 负载中，这样就可以实现动态的变更操作了。
在不使用 Nginx 代理的时候，前面章节使用网关都是通过直接方式的方式操作，如 http://10.20.111.132:7397/wg/activity/sayHi?str=1 那么现在因为有负载的设计，希望把来自于不同 URL的请求负载到不同的网关算力上去，所以这里的访问地址将变更为：http://10.20.111.132:8090/10001/wg/activity/sayHi?str=10001 从第1个地址到第2个地址来看，变化的点主要是端口由原来的访问网关算力节点到访问 Nginx，同时多了一个 10001 的路径。这个 10001 就是数据库中 group_id 网关分组的配置。我们也是用这个配置来区分访问哪一组网关。
api-gateway-center 管理着网关算力的 ...
以 Java 程序调用 Docker 容器控制 Nginx 刷新为手段，处理服务与 Docker 容器间挂载的 Nginx 配置文件动态刷新操作。
设计用于承载 HTTP 请求转换协议泛化调用 RPC 服务的网关算力不可能只有一组服务，而是一个网关算力集群化的设计实现。而对于这样一个诉求的实现，基本的核心模型结构就是负载的配置和轮询策略的使用。那么这里继续扩展这部分内容，让 Nginx 可以被动态的变更并重载配置文件。这样就可以满足当有新的网关注册、下线、调整时可以自动的生效 Nginx 配置。
动态刷新的负载配置策略的方案也会根据服务的部署方式有所不同，那么这里做的就是服务在 Docker 容器化部署，通过 Java 调用容器指令的方式进行刷新的一种方案。以下是方案设计：
对于一个网关算力的动态配置和刷新，要根据服务的注册动态变更 Nginx 配置文件并生效。
那么这里就会牵扯到 Nginx 的配置文件变更和刷新，如何通过Java程序进行控制等问题。
那么以当前服务部署到 Docker 容器场景为例，Docker 是嵌入到 Linux 服务器内的，每个镜像实例的部署也都是隔离的， ...
通过模拟多个 HTTP 服务配置到 Nginx 做负载均衡，以学习 API 网关负载的配置和使用。
设计API 网关是用于支撑分布式 RPC 接口协议转换提供 HTTP 调用的一套服务，那么 API 网关系统就需要可横向扩展来满足系统的吞吐量诉求。所以这里需要让 API 网关来支持分布式架构部署，提供负载均衡的能力。
那么在这方面有一套非常成熟的模式就是基于 Nginx 以及 LVS、F5 相关的配置构建出负载均衡服务。在这里同样我们的 API 网关也可以被这样的方式进行处理，来满足部署需求。
这里先介绍基于 Nginx 如何构建出一套负载均衡的网络请求模型，方便理解这样一个过程。
API 网关是根据 HTTP 协议请求的地址转换为对应映射泛化调用的 RPC 框架。这部分请求地址被配置到数据库中。
wg 是一个固定开头的地址，转换后面紧跟着所访问的具体方法。在前面章节中已经实现过 uri 映射到具体的 RPC 上。所以当我们通过在浏览器进行 HTTP 访问接口接口 http://localhost:8090/wg/activity/sayHi 时，则会访问的到对应的 api 协议转换 ...
设计和实现运营后台的接口，以及在前后端分离项目中如何处理跨域接口访问的问题。
设计在使用前后端分离的方式构建运营后台应用系统以后，会遇到一个非常常见的问题，就是跨域访问。那么什么是跨域访问呢？
跨域访问是指当一个网页从一个域名（或端口）请求另一个域名（或端口）的资源时，由于浏览器的同源策略限制，请求会被拒绝。跨域访问是一种常见的安全限制，用于防止网页在不受信任的域中访问敏感信息。
实现【infrastructure层】OperationRequest1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677package cn.ray.gateway.center.infrastructure.common;import org.apache.commons.lang3.StringUtils;/** * @author Ray * @date 2023/6 ...
基于 vue-manage-system 搭建运营管理后台
设计通常在我们的系统开发中，都有一个用于管理整个应用配置和检索数据的管理后台，便于运营使用。在早期没有 vue 出现之前，大家通常使用类似 Layui 这样的框架搭建管理后台，虽然它已经停更了但不影响它的使用也真的非常好用。
不过在互联网公司很多运营后台都是由前端研发提供好 vue 框架并负责开发，或者一些简单的页面，也可以由后端研发进行处理。类似这样的 vue 运营管理框架包括：
vue-element-admin —— —个基于 vue2.0 和 Eelement 的控制面板 UI 框架，这是使用 vue 技术栈开发的前端程序员的首选管理系统模板，模板以及非常的成熟了，并且有相关的社区和维护人员，开发时候遇到问题也不要慌。
ant-design-vue-pro —— 阿里背书，蚂蚁家族的。
iview-admin —— iView admin 是基于 iView 的 vue 2.0 控制面板。搭配使用 iView UI组件库形成的一套后台集成解决方案。
d2-admin —— D2Admin 是一个完全 开源免费 的企业 ...
通过 Redis 发布和订阅的模块，在网关注册中心和网关助手中分别提供相关功能，在应用接口注册到网关中心后触发通知，让网关助手完成新增接口的映射处理。
设计
这一章节的开发有一个需求的背景，我们的网关算力服务在启动过程中会拉取注册中心的接口信息，到网关算法上进行注册操作。通过这样的一个步骤，才能让我们在访问网关接口的时候，泛化调用到对应的 RPC 服务。那么，当网关算力服务已经是部署好后，再有新的服务或者接口注册到网关注册中心的时候，那么网关算力该如何把这些信息获取到并完成网关的映射呢？可以通过几个方案来处理;
接口的轮询，在网关算力 api-gateway-assist 助手服务中通过不断的像网关中心请求接口的方式，拉取到所有需要被注册的接口。这里可以在已经拉取的服务接口上，在Redis中做数据的记录，减少重复拉取。不过这样的方式会给网关中心带来不小的压力。
网关引擎在Spring生命周期初始化中，另起一个线程，在后台while(true)不断重复拉取所有服务，并存入缓存。
显然不论是对于网关引擎还是注册中心都消耗占用不少资源。
服务的连接，在网关助手类与网关中心建立一个 Net ...
封装采集到的RPC应用服务接口信息，随着应用向网关中心注册应用接口。
设计
每一个提供 HTTP 接口的 RPC 应用服务，都需要基于引入的 SDK 组件，采集自身的接口向网关中心注册。因为每一个 RPC 服务本身是在 RPC 注册中心维护的，具备负载均衡的能力。所以通常向网关中心注册的都是 RPC 的接口描述信息，不过网关中心可以在这个过程记录上 RPC 接口的总数以及 IP 信息。这里暂时不需要，所以不提供注册。
结合第20章采集到的服务信息，这里把这些服务信息向网关中心注册。
通常提供服务接口的实现类，只会有一个接口以及对应的实现类。如果有多个接口会抛出异常提醒。
实现注册服务12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697package cn.ray.gatew ...
提供应用服务注册的组件，采集 RPC 服务启动时已经配置了标记注解的对象，摘取出类、接口、方法，用于后续注册到网关中心。
设计
网关的注册中心维护着网关和RPC接口的信息，用于把RPC接口分配到网关算力上使用。那么前面的章节已经实现了网关算力的自动注册，同样 RPC 接口也需要自动注册，否则都是人工手动维护这个成本还是非常大的。
应用注册组件的目的就是提供给 RPC 接口生产的服务使用，通过 RPC 生产者服务引入 SDK 组件，并使用注解配置的方式作为接口标记。当服务启动的时候，SDK组件会采集这些被标记了注解的接口和方法，把这些信息收集后向网关注册中心注册，而 assist 就可以将其注入通信组件的 Configuration 配置中，后续通信组件对其进行一系列处理后，返回泛化调用的结果。
实现自定义注解12345678910111213141516171819202122232425package cn.ray.gateway.sdk.annotation;import java.lang.annotation.*;/** * @author Ray * @date 2023/5 ...
项目笔记
未读api-gateway-engine 是一个用于启动网关算力服务的引擎工程，它的代码内容几乎没有多少，主要负责的是工程的启动操作，因为镜像的打包也是从这个工程中处理。
实现
api-gateway-core：核心通信模块，处理网关对接口的协议转换和映射操作以及泛化调用对应的 RPC 接口。
api-gateway-assist：将 api-gateway-core 包装，提供简化的使用方式。
api-gateway-engine 则是一个打包的执行引擎工程，打包后提供可部署到容器的 Jar 包。
这里的 engine 其实和之前的 assist-test 大体一致，只不过相当于从 assist 中抽取出来，做一个整理分类的动作。
工程相关引入 assist 的 Jar 包12345<dependency> <groupId>cn.ray.gateway</groupId> <artifactId>api-gateway-assist-04</artifactId> <version>1.0-SNAP ...
把网关在注册和拉取时的异常抛出来，交给容器管理做关闭动作，以及处理网关的服务关闭。
设计
在 api-gateway-assist 启动的过程中，我们希望它所发生的一些动作，包括启动中的异常、拉取接口信息的失败以及容器关闭后优雅的处理网关通信的关闭。
这里需要把网关的注册和拉取配置操作，放到 ApplicationContextAware 接口对应的 setApplicationContext 方法中。这样可以在注册服务以及拉取配置的过程中出现失败情况时，则直接抛异常关闭容器。
另外这里还需要做一个容器关闭的监听动作 ApplicationListener\ 容器关闭时则把网关中的通信模块下的 Netty 服务也一起关闭掉。
实现感知容器以及监听关闭事件12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788 ...
