文章目录
一、Overview
由于特殊的网络架构,网络被划分为多个域,不同域之间网络是不通的。不同的网络域部署了不同的系统,不同网络域的系统都需要接入微服务体系,并且需要支持不同网络域之间的微服务调用;如果微服务调用设计到跨网络域,对于微服务的调用和被调用方都应该是无感的(对他们来说不存在不同域网络隔离)。
由于不同域的网络是隔离的,所以一个跨所有网络域的全局注册中心是不合理的(因为服务调用时,还是端到端的,网络不通)。
所以现有的架构是不同的网络域内部署一套eureka
集群,单个域内的微服务注册到同域内的eureka
。问题就简化为如何支持不同注册中心之间的微服务调用。
本文就阐述一种支持跨注册中心的微服务调用架构设计。
二、TODO & NOT TODO
TODO:
- 跨网络的微服务调用。
- 不同网络域之间的微服务之间不需要开通网络规则。
三、详细设计
1.请求由外部系统通过当前网络域的网关进行微服务调用
简单的理解就是:外部系统调用了当前域的Spring Cloud Gateway
入口网关。
1)如果被调用的微服务在本网络注册中心存在
如果被调用的微服务在本域注册中心存在,那就成功完成一次调用。
2)如果被调用的微服务在本网络注册中心不存在
如果被调用的微服务不在本域,只有2
种情况:
- 本域内被调用的微服务掉线了。
- 被调用的微服务不在本域。
针对情况1
,网关服务发现找不到微服务是合情合理的,因为是微服务掉线导致的,不需要对它进行特殊处理。
针对情况2
,被调用的微服务不在本域,接入方需要优先考虑微服务所在域的API
网关,如果接入方没法做到调用微服务所在域的API
网关,则需要将请求转发给跨域网关,跨域网关转发请求给另一个域的网关,完成微服务调用。
结论
针对外部请求通过当前网络域进行微服务调用,不需要做额外的特殊处理,正常的通过网关进行微服务调用即可。
2.请求由网络域内微服务发起
1) 被调用的微服务和发起方处于同一个网络域
如果被调用的微服务在本域注册中心存在,那就成功完成一次调用。
2) 被调用的微服务和发起方处于不同的网络域
相当于一次跨域的微服务调用,过程如下图。域内找不到需要调用的微服务时,将请求转发给跨域网关,跨域网关转发请求给目标域的API
网关,完成微服务调用。
3.如何将请求转发给跨域网关
概述
跨域网关本身也需要注册到注册中心,微服务在发起服务发现时,如果域内找不到需要被调用的微服务实例信息,服务发现寻找跨域网关的实例地址,将请求转发给我跨域网关。
跨域网关注册到注册中心的优点:
- 无需自己维护实例信息,负载均衡。
- 网关优雅上下线。
- 可以通过
sdk
实现服务发现。
实现方式
服务发现
基于com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
实现自定义的服务发现规则。
域内服务发现时,增加对跨域网关的发现逻辑。优先服务发现微服务信息,无法找到时再寻找网关。通过优先级的配置,决定请求转发给微服务还是跨域网关。
跨域网关
针对跨域网关,需要考虑请求来自哪里。
- 微服务。
- 域内
API
网关。
来自微服务的请求,请求路径为被调用的微服务API
。来自域内API
网关的请求路径前缀为微服务名,后面加上微服务的API
路径。所以跨域网关需要对不同来源的请求做不同的处理。
跨域网关的处理逻辑如下图
对于来自微服务的请求,在请求头加上特殊header
,标识发起方微服务名是什么。跨域网关收到请求时,判断请求头是否含有特殊的header
,如果没有说明请求来自域内API
网关,直接根据请求路径转发给其他域的网关即可。如果含有特殊header
,需要在请求路径前加上前缀,前缀为特殊header
的值,再转发给后端微服务。
4.跨域网关如何确定请求转发到哪个域的API网关
所有接入的微服务系统,都已经在管理平台登记。所有的登记的微服务都配置位于哪一个网络域,可以利用登记信息,获取所有微服务的网络域地址,在跨域网关里维护所有微服务的域信息。
跨域网关收到请求时,根据被调用的微服务名,找到微服务所在的网络域,将请求转发给对应的网络域的API
网关。不同的域网关地址可以在配置中心维护。
TIP
: 跨域网关在转发时,要注意不能将请求转发给跨域网关所在域的API
网关,防止循环调用。
通过上述的设计,跨注册中心的微服务调用理论上已没有问题。