基于SpringCloudGateway实现跨注册中心服务发现

一、Overview

由于特殊的网络架构，网络被划分为多个域，不同域之间网络是不通的。不同的网络域部署了不同的系统，不同网络域的系统都需要接入微服务体系，并且需要支持不同网络域之间的微服务调用；如果微服务调用设计到跨网络域，对于微服务的调用和被调用方都应该是无感的（对他们来说不存在不同域网络隔离）。

由于不同域的网络是隔离的，所以一个跨所有网络域的全局注册中心是不合理的（因为服务调用时，还是端到端的，网络不通）。

所以现有的架构是不同的网络域内部署一套eureka集群，单个域内的微服务注册到同域内的eureka。问题就简化为如何支持不同注册中心之间的微服务调用。

本文就阐述一种支持跨注册中心的微服务调用架构设计。

二、TODO & NOT TODO

TODO：

1. 跨网络的微服务调用。
2. 不同网络域之间的微服务之间不需要开通网络规则。

三、详细设计

1.请求由外部系统通过当前网络域的网关进行微服务调用

简单的理解就是：外部系统调用了当前域的Spring Cloud Gateway入口网关。

1）如果被调用的微服务在本网络注册中心存在

如果被调用的微服务在本域注册中心存在，那就成功完成一次调用。

2）如果被调用的微服务在本网络注册中心不存在

如果被调用的微服务不在本域，只有2种情况：

1. 本域内被调用的微服务掉线了。
2. 被调用的微服务不在本域。

针对情况1，网关服务发现找不到微服务是合情合理的，因为是微服务掉线导致的，不需要对它进行特殊处理。

针对情况2，被调用的微服务不在本域，接入方需要优先考虑微服务所在域的API网关，如果接入方没法做到调用微服务所在域的API网关，则需要将请求转发给跨域网关，跨域网关转发请求给另一个域的网关，完成微服务调用。

结论

针对外部请求通过当前网络域进行微服务调用，不需要做额外的特殊处理，正常的通过网关进行微服务调用即可。

2.请求由网络域内微服务发起

1) 被调用的微服务和发起方处于同一个网络域

如果被调用的微服务在本域注册中心存在，那就成功完成一次调用。

2) 被调用的微服务和发起方处于不同的网络域

相当于一次跨域的微服务调用，过程如下图。域内找不到需要调用的微服务时，将请求转发给跨域网关，跨域网关转发请求给目标域的API网关，完成微服务调用。

3.如何将请求转发给跨域网关

概述

跨域网关本身也需要注册到注册中心，微服务在发起服务发现时，如果域内找不到需要被调用的微服务实例信息，服务发现寻找跨域网关的实例地址，将请求转发给我跨域网关。

跨域网关注册到注册中心的优点：

1. 无需自己维护实例信息，负载均衡。
2. 网关优雅上下线。
3. 可以通过 sdk 实现服务发现。

实现方式

服务发现

基于com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList实现自定义的服务发现规则。

域内服务发现时，增加对跨域网关的发现逻辑。优先服务发现微服务信息，无法找到时再寻找网关。通过优先级的配置，决定请求转发给微服务还是跨域网关。

跨域网关

针对跨域网关，需要考虑请求来自哪里。

1. 微服务。
2. 域内API网关。

来自微服务的请求，请求路径为被调用的微服务API。来自域内API网关的请求路径前缀为微服务名，后面加上微服务的API路径。所以跨域网关需要对不同来源的请求做不同的处理。

跨域网关的处理逻辑如下图

对于来自微服务的请求，在请求头加上特殊header，标识发起方微服务名是什么。跨域网关收到请求时，判断请求头是否含有特殊的header，如果没有说明请求来自域内API网关，直接根据请求路径转发给其他域的网关即可。如果含有特殊header，需要在请求路径前加上前缀，前缀为特殊header的值，再转发给后端微服务。

4.跨域网关如何确定请求转发到哪个域的API网关

所有接入的微服务系统，都已经在管理平台登记。所有的登记的微服务都配置位于哪一个网络域，可以利用登记信息，获取所有微服务的网络域地址，在跨域网关里维护所有微服务的域信息。

跨域网关收到请求时，根据被调用的微服务名，找到微服务所在的网络域，将请求转发给对应的网络域的API网关。不同的域网关地址可以在配置中心维护。

TIP: 跨域网关在转发时，要注意不能将请求转发给跨域网关所在域的API网关，防止循环调用。
通过上述的设计，跨注册中心的微服务调用理论上已没有问题。