程序员笔记 | API网关如何实现对服务下线的实时感知

上篇文章《Eureka 缓存机制》介绍了Eureka的缓存机制，相信大家对Eureka 有了进一步的了解，本文将详细介绍API网关如何实现服务下线的实时感知。 

一、前言

在基于云的微服务应用中，服务实例的网络位置都是动态分配的。而且由于自动伸缩、故障和升级，服务实例会经常动态改变。因此，客户端代码需要使用更加复杂的服务发现机制。

目前服务发现主要有两种模式：客户端发现和服务端发现。

服务端发现：客户端通过负载均衡器向服务注册中心发起请求，负载均衡器查询服务注册中心，将每个请求路由到可用的服务实例上。

客户端发现：客户端负责决定可用服务实例的网络地址，并且在集群中对请求负载均衡, 客户端访问服务登记表，也就是一个可用服务的数据库，然后客户端使用一种负载均衡算法选择一个可用的服务实例然后发起请求。

客户端发现相对于服务端发现最大的区别是：客户端知道（缓存）可用服务注册表信息。如果Client端缓存没能从服务端及时更新的话，可能出现Client 与 服务端缓存数据不一致的情况。

二、网关与Eureka结合使用

Netflix OSS 提供了一个客户端服务发现的好例子。Eureka Server 为注册中心，Zuul 相对于Eureka Server来说是Eureka Client,Zuul 会把 Eureka Server 端服务列表缓存到本地，并以定时任务的形式更新服务列表，同时zuul通过本地列表发现其它服务，使用Ribbon实现客户端负载均衡。

正常情况下，调用方对网关发起请求即刻能得到响应。但是当对生产者做缩容、下线、升级的情况下，由于Eureka这种多级缓存的设计结构和定时更新的机制，LoadBalance 端的服务列表B存在更新不及时的情况(由上篇文章《Eureka 缓存机制》可知，服务消费者最长感知时间将无限趋近240s），如果这时消费者对网关发起请求，LoadBalance 会对一个已经不存在的服务发起请求，请求是会超时的。

三、解决方案

3.1 实现思路

生产者下线后，最先得到感知的是 Eureka Server 中的 readWriteCacheMap，最后得到感知的是网关核心中的 LoadBalance。但是 loadBalance 对生产者的发现是在 loadBalance 本地维护的列表中。

所以要想达到网关对生产者下线的实时感知，可以这样做：首先生产者或者部署平台主动通知 Eureka Server, 然后跳过 Eureka 多级缓存之间的更新时间，直接通知 Zuul 中的 Eureka Client,最后将 Eureka Client 中的服务列表更新到 Ribbon 中。

但是如果下线通知的逻辑代码放在生产者中，会造成代码污染、语言差异等问题。

借用一句名言：

“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”

Gateway-SynchSpeed 相当于一个代理服务，它对外提供REST API来负责响应调用方的下线请求，同时会将生产者的状态同步到 Eureka Server 和 网关核心，起着 状态同步 和 软事物 的作用。

思路：在生产者做 缩容、下线、升级 前，spider 平台（spider为容器管理平台）会主动通知 Gateway-SynchSpeed 某个生产者的某个实例要下线了，然后 Gateway-SynchSpeed 会通知 Eureka Server 生产者的某个实例下线了；如果Eureka Server 下线成功，Gateway-SynchSpeed 会直接通知 网关核心。

设计特点

无侵入性、方便使用。不用关心调用方的基于何种语言实现，调用者只要对 Gateway-SynchSpeed 发起一个http rest请求即可，真正的实现逻辑不用侵入到调用方而是交给这个代理来实现。