基于SpringCloudGateway实现跨注册中心服务发现(增强版)

Overview

第一版中跨域网关和路由网关属于2个不同类型的网关，本质上跨域也是路由的一种，路由给另一个网络域网关。所以在第二版中合并跨域和路由网关功能，成为支持服务发现的路由转发和跨注册中心调用的网关。
第一版网关设计链接：https://blog.csdn.net/sweatOtt/article/details/117042429

路由网关只考虑通过服务发现的方式转发请求的场景，暂不考虑其他场景。

详细设计

如何区分请求来源

主要考虑的场景为以下2类:

1. 请求来自外部（非微服务体系）。
2. 请求来自微服务。

不同的请求来源，需要有不同的处理逻辑来区分处理，最后都由网关转发。

为了顺利的转发请求，需要优先考虑以下几点：

1. 对于来自外部的请求，请求的路径为http://{host:port}/{service-name}/api/xxx，请求api的第一段为{service-name}，即目标微服务名，后面接上的为希望调用的对应微服务的api。
2. 来自微服务的请求，请求路径为http://{host:port}/api/xxx，请求api没有{service-name}作为前缀，内容为目标微服务的api。
3. 网关转发跨网络域请求，目标调用者为另一个网络域的网关（网关需要通过服务发现转发请求），所以转发的请求路径必须带有微服务名前缀（/{service-name}/api/xxx）。
4. 结合上述3点，网关在接收到不同来源跨网络域请求后，需要统一请求API路径，路径增加微服务名前缀，转发给另一个域网关。

针对不同来源的请求，请求的url不同，需要有不同的格式化处理方式，区分请求来源的最佳方式是通过header来判断，通过给不同来源的请求添加header，让gateway能够确定如何处理请求。

• 对于来自微服务的请求，可以增加header，表示当前网关接收到的请求来自微服务，需要进行跨网络域请求。
• 对于来自外部的请求，请求不存在header，说明来自外部。

微服务请求处理

来自微服务的请求，如果需要进行跨网络域转发，需要对请求路径增加微服务名前缀，确保网关转发后的请求能成功通过网关进行服务发现转发。

外部请求处理

对于来自外部的请求，请求的url都是标准网关请求格式，无需做额外格式化，只需要关注以下2类场景：

1. 请求只需要通过服务发现，路由请求。被调用方微服务和网关在同一个网络域注册中心，只需要通过服务发现就能转发请求。
2. 请求服务发现找不到，需要进行跨网络域调用。被调用方微服务和网关不在同一个网络域注册中心，需要通过gateway进行跨网络域调用，转发给另一个网络域的网关。

对于上述2类场景，需要关注的是请求处理顺序，只有在服务发现找不到目标微服务时，才进行跨域请求转发。这一点必须严格遵守，否则请求会陷入循环跨网络域调用。

外部请求的处理逻辑如下图

跨域目标网关地址

跨域目标网关获取方式有多种，原本设计通过域找到对应域网关的F5地址，请求转发给F5进行路由。考虑到F5单点和F5维护问题，通过服务发现寻找跨网络域网关会更优雅（高可用、节点扩容等）。

跨网络域网关从目标域注册中心，进行服务发现查找网关列表，结合load balancer获取一个网关地址转发请求。

1. 跨域网关维护所有注册中心服务发现客户端实例（只发现不注册）。
2. 跨域网关针对每个服务发现客户端对应一个负载均衡实例。
3. 网关根据跨域请求目标微服务所在域，通过对应域的服务发现、负载均衡调用目标网关路由请求。