InfiniGate自研网关实现思路六

21.应用服务接口注册到注册中心

封装采集到的RPC应用服务接口信息，随着应用向网关中心注册应用接口。

每一个做为提供HTTP接口的RPC应用服务，都需要基于引入的SDK组件，采集自身的接口向网关中心注册。因为每一个RPC服务本身是在RPC注册中心维护的，具备负载均衡的能力。所以通常向网关中心注册的都是 RPC 的接口描述信息，不过网关中心可以在这个过程记录上 RPC 接口的总数以及IP信息。这里暂时不需要，所以不提供注册。

这里接着上一章采集到的服务信息，这里把这些服务信息注册到注册中心上。

具体实现：

1.创建domain领域层包，然后domain包下面创建服务的子领域包，创建GatewayCenterService类用于将RPC服务信息注册到注册中心。里面写三个方法分别用来注册应用信息、注册接口信息、注册方法信息。

2.在application层中调用domain领域层的服务注册方法，将收集到服务信息注册到注册中心上。

22.订阅服务注册消息驱动网关映射

通过 Redis 发布和订阅的模块，在网关注册中心和网关助手中分别提供相关功能，在应用接口注册到网关中心后触发通知，让网关助手完成新增接口的映射处理。

这里的开发有一个需求的背景，我们的网关算力服务在启动过程中会拉取注册中心的接口信息，到网关算法上进行注册操作。通过这样的一个步骤，才能让我们在访问网关接口的时候，泛化调用到对应的 RPC 服务。

那么，这里需要思考🤔。当网关算力服务已经是部署在Docker容器中后，再有新的服务或者接口注册到网关注册中心的时候，那么网关算力该如何把这些信息获取到并完成网关的映射呢？

这里我提供一下几种解决方案：

1. 网关算力节点对注册中心进行轮询，在网关算力 api-gateway-assist 助手服务中通过不断地像网关中心请求接口的方式，拉取到所有需要被注册的接口。这里可以在已经拉取的服务接口上，在Redis中做数据的记录，减少重复拉取。不过这样的方式会给网关中心带来不小的压力。
2. 服务的连接，在网关助手类与网关中心建立一个 Netty 的服务，由网关中心接收到新的接口注册时候进行信息通知。但这样的长链接，已经会占用不少的资源。
3. 事件的通知，其实通过事件来通知是一个比较合适的方式，比如你可以使用 MQ、ZK等方式，也可以使用 Redis 的发布和订阅。在有接口变化的时候，可以通过消息的推送，让网关算力获取到变化的接口信息进行注册处理。那么本文就是通过 Redis 的方式进行处理。

带有颜色标记的工程；api-gateway-assist、api-gateway-center、api-gateway-sdk，都是这里所涉及要改动的工程。

1. 在 api-gateway-center 工程中添加 Redis 发布消息模块，并提供应用服务注册后的事件通知操作。这个通知只会通知给对应的网关算力服务，不会全局通知。
2. 在 api-gateway-assist 工程中开发 Redis 订阅消息模块，当收到注册中心的消息推送时，则根据系统的标识信息进行拉取服务。注意这里你可以进行细化，只把变更的信息一条条推送给网关注册，减少接口的拉取
3. 在 api-gateway-sdk 工程中添加对网关注册中心接口的调用，当所有的服务注册完成后，调用接口进行通知。

具体实现：

1.在注册中心模块中新增和改动如下：

绿色表示新增，蓝色表示改动。

2.在用户接口层的RpcRegisterManage类中写一个registerEvent方法，用于接收RPC服务的注册并向网关算力节点推送注册消息。

3..把redis集成到项目中，在domain领域层中新增关于消息订阅发布的子领域包message。

4.网关助手模块的新增改动如下：

为了能收到来自注册中心的消息推送，那么网关助手服务也需要连接到对应的 Redis 服务上。那么这里并不需要用户再网关助手类中配置 Redis 的连接信息，而是通过优化的方式从注册中心拉取 Redis 连接信息，到网关助手中进行注册。因为只有这样，才能减少用户的配置，并做到统一的管理。

5.在 GatewayAutoConfig 网关服务配置类中，创建一个 Redis 链接的 Bean 对象。只不过这个对象在创建的过程中，需要先从网关注册中心拉取 Redis 配置信息，之后完成注册操作。注意这里关于 JedisPoolConfig 是固定的配置，一般这些配置也可以从网关注册中心进行拉取。

6.还要在网关助手模块实现事件订阅，当网关服务助手接收到 Redis 订阅的消息以后，则根据信息进行拉取对应的系统数据。注意这里我在网关注册中心迭代了拉取服务的接口，提供了通过系统ID进行定向拉取。

7.在GatewayApplication类的setApplicationContext（创建Bean后实现自动调用）方法中，调用监听服务注册的方法。

23.网关运营管理后台框架搭建

基于 vue-manage-system 搭建运营管理后台，这里会涉及到 vue、html、css、js 以及对应前端开发环境的配置。

通常在我们的系统开发中，都有一个用于管理整个应用配置和检索数据的管理后台，便于运营使用。在早期没有vue出现之前，大家通常使用类似 Layui 这样的框架搭建管理后台，虽然它已经停更了但不影响它的使用也真的非常好用。

不过在互联网公司很多运营后台都是由前端研发提供好vue框架并负责开发，或者一些简单的页面也可以由后端研发进行处理。类似这样的 vue 运营管理框架包括：

1. vue-element-admin - 一个基于 vue2.0 和 Eelement 的控制面板 UI 框架，这是使用vue技术栈开发的前端程序员的首选管理系统模板，模板以及非常的成熟了，并且有相关的社区和维护人员，开发时候遇到问题也不要慌。
2. ant-design-vue-pro - 阿里背书，蚂蚁家族的。
3. iview-admin - iView admin 是基于 iView 的 Vue 2.0 控制面板。搭配使用 iView UI 组件库形成的一套后台集成解决方案。
4. d2-admin - D2Admin 是一个完全 开源免费 的企业中后台产品前端集成方案，基于 vue.js 和 ElementUI 的管理系统前端解决方案 ，小于 60kb 的本地首屏 js 加载
5. vuestic-admin - vuestic-admin，一款免费而美妙Vue.js管理模板包括38以上个定制用户界面组件，像地图，聊天，个人资料卡，图标，进度条、l登录和注册的预建页面等等。
6. Vue Admin - Vue Admin 是一个基于 Vue 2.0 & Bulma 0.3 的后台管理面板（管理系统），相当于是 Vue 版本的 Bootstrap 管理系统，提供了一组通用的后台界面 UI 和组件，其中还有丰富的图表组件，开箱即用。
7. vue-manage-system - 基于Vue.js 2.x系列 + Element UI 的后台管理系统解决方案 ,弥补了element中缺少图片裁剪上传、富文本编辑器、图表等这些在后台管理系统中很常见的功能。适用于绝大部分的后台管理系统（Web Management System）开发。

以上这些框架都可以搭建出运营管理后台，我这里也做了一些测试验证，虽然有些像 vue-element-admin 这种老牌框架非常强大，但整体框架也不小，开发模式会复杂一些适合更大的系统和专业的vue人员使用。我们这里为了让大家既能学习到vue，也能简单的入门，所以我在测试后选择了 vue-manage-system 进行使用。

24.前后端分离应用的跨域接口调用

这里主要涉及到了运营后台的接口设计和实现，以及在前后端分离项目中如何处理跨越接口访问的问题。

在使用前后端分离的方式构建运营后台应用系统以后，你会遇到一个非常常见的问题，就是跨域访问。那么什么是跨域访问呢？

跨域访问是指当一个网页从一个域名（或端口）请求另一个域名（或端口）的资源时，由于浏览器的同源策略限制，请求会被拒绝。跨域访问是一种常见的安全限制，用于防止网页在不受信任的域中访问敏感信息。

其实跨越问题并不是一个很大的问题，但对于很多新人来说没经历过前后端分离的项目，在面试时被问题还是会很晕的。另外除此之外，那么多接口页面接口需要查询，出参入参该如何设计，也是一个技术点。

具体实现：

1.在api-gateway-center模块中，在 interfaces 中添加类 DataOperationManage 类，专门对 ERP 工程提供数据查询接口服务。一般如果服务工程较大，有更多的开发人员可提供开发和维护的情况，可以单独开发一个系统与 api-gateway-center 做对接。

2.进行跨域配置，@CrossOrigin 是一个跨域配置的注解，可以指定可访问接口的跨越域名和端口，如果什么都不配置，那么默认就是都可以访问。

另外关于跨域还有其他的解决方案；

1. 使用代理服务器，将请求转发到目标域。
2. 使用 JSONP 技术，通过动态创建 script 标签来请求数据。
3. 使用 CORS（Cross-Origin Resource Sharing）技术，通过在服务器端设置 HTTP 头来允许跨域访问。也就是咱们使用的注解方式。
4. 使用服务器端框架或库，例如 Spring 或 Apache Shiro，提供跨域访问支持。
5. 使用 Nginx 代理服务器，在服务器端配置跨域访问。
6. 使用WebSocket，建立双向通信，消除跨域问题