文章目录
- Overview
- 详细设计
- 如何区分请求来源
- 微服务请求处理
- 外部请求处理
- 跨域目标网关地址
Overview
第一版中跨域网关和路由网关属于2
个不同类型的网关,本质上跨域也是路由的一种,路由给另一个网络域网关。所以在第二版中合并跨域和路由网关功能,成为支持服务发现的路由转发和跨注册中心调用的网关。
第一版网关设计链接:
路由网关只考虑通过服务发现的方式转发请求的场景,暂不考虑其他场景。
详细设计
如何区分请求来源
主要考虑的场景为以下2
类:
- 请求来自外部(非微服务体系)。
- 请求来自微服务。
不同的请求来源,需要有不同的处理逻辑来区分处理,最后都由网关转发。
为了顺利的转发请求,需要优先考虑以下几点:
- 对于来自外部的请求,请求的路径为
http://{host:port}/{service-name}/api/xxx
,请求api
的第一段为{service-name}
,即目标微服务名,后面接上的为希望调用的对应微服务的api
。 - 来自微服务的请求,请求路径为
http://{host:port}/api/xxx
,请求api
没有{service-name}
作为前缀,内容为目标微服务的api
。 - 网关转发跨网络域请求,目标调用者为另一个网络域的网关(网关需要通过服务发现转发请求),所以转发的请求路径必须带有微服务名前缀(
/{service-name}/api/xxx
)。 - 结合上述
3
点,网关在接收到不同来源跨网络域请求后,需要统一请求API
路径,路径增加微服务名前缀,转发给另一个域网关。
针对不同来源的请求,请求的url
不同,需要有不同的格式化处理方式,区分请求来源的最佳方式是通过header
来判断,通过给不同来源的请求添加header
,让gateway
能够确定如何处理请求。
- 对于来自微服务的请求,可以增加
header
,表示当前网关接收到的请求来自微服务,需要进行跨网络域请求。 - 对于来自外部的请求,请求不存在
header
,说明来自外部。
微服务请求处理
来自微服务的请求,如果需要进行跨网络域转发,需要对请求路径增加微服务名前缀,确保网关转发后的请求能成功通过网关进行服务发现转发。
外部请求处理
对于来自外部的请求,请求的url
都是标准网关请求格式,无需做额外格式化,只需要关注以下2
类场景:
- 请求只需要通过服务发现,路由请求。被调用方微服务和网关在同一个网络域注册中心,只需要通过服务发现就能转发请求。
- 请求服务发现找不到,需要进行跨网络域调用。被调用方微服务和网关不在同一个网络域注册中心,需要通过
gateway
进行跨网络域调用,转发给另一个网络域的网关。
对于上述2
类场景,需要关注的是请求处理顺序,只有在服务发现找不到目标微服务时,才进行跨域请求转发。这一点必须严格遵守,否则请求会陷入循环跨网络域调用。
外部请求的处理逻辑如下图
跨域目标网关地址
跨域目标网关获取方式有多种,原本设计通过域找到对应域网关的F5
地址,请求转发给F5
进行路由。考虑到F5
单点和F5
维护问题,通过服务发现寻找跨网络域网关会更优雅(高可用、节点扩容等)。
跨网络域网关从目标域注册中心,进行服务发现查找网关列表,结合load balancer
获取一个网关地址转发请求。
- 跨域网关维护所有注册中心服务发现客户端实例(只发现不注册)。
- 跨域网关针对每个服务发现客户端对应一个负载均衡实例。
- 网关根据跨域请求目标微服务所在域,通过对应域的服务发现、负载均衡调用目标网关路由请求。