这样讲API网关，你应该能明白了吧( 四 ) _API网关

API 网关要做的事情就是解析这个 Token ，知道访问者是谁(鉴定) ，他能做什么/访问什么(权限) 。
说白了就是看访问者能够访问哪些 URL ，这里根据权限/角色定义一个访问列表。
如果要实现多个系统的 OSS(Single Sign On 单点登录) ， API 网关需要和 CAS(Central Authentication Service 中心鉴权服务)做连接，来确定请求者的身份和权限。
熔断降级
当应用服务出现异常，不能继续提供服务的时候，也就是说应用服务不可用了。作为 API 网关需要做出处理，把请求导入到其他服务上。
或者对服务进行降级处理，例如：用兜底的服务数据返回客户端，或者提示服务暂时不可用。
同时通过服务注册中心，监听存在问题的服务，一旦服务恢复，随即恢复路由请求到该服务。
例如：Zuul 中提供了 ZuulFallbackProvider 接口来实现熔断，它提供两个方法，一个指明熔断拦截的服务 getRoute ，一个指定返回内容 ClientHttpResponse 。
public interface ZuulFallbackProvider {/*** The route this fallback will be used for.* @return The route the fallback will be used for.*/public String getRoute();/*** Provides a fallback response.* @return The fallback response.*/public ClientHttpResponsefallbackResponse(); } 我们通过自定义的 Fallback 方法，并且将其指定给某个 Route 来实现该 Route 访问出问题的熔断处理。
主要继承 ZuulFallbackProvider 接口来实现， ZuulFallbackProvider 默认有两个方法，一个用来指明熔断拦截哪个服务，一个定制返回内容。

文章插图

API 网关熔断降级
发布测试
在发布版本的时候会采用：金丝雀发布和蓝绿发布。作为 API 网关可以使用路由选择和流量切换来协助上述行为。这里以金丝雀发布为例，看看 API 网关如何做路由转换的。
假设将 4 个服务从 V1 更新到 V2 版本，这 4 个服务的流量请求由 1 个 API 网关管理。

文章插图

那么先将一台服务与 API 网关断开，部署 V2 版本的服务，然后 API 网关再将流量导入到 V2 版本的服务上。

文章插图

这里流量的导入可以是逐步进行的，一旦 V2 版本的服务趋于稳定。再如法炮制，将其他服务替换成 V2 版本。

文章插图

金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀(Canary)测试(灰度测试) 。
其来历是，旷工下矿洞前，先放一只金丝雀探查是否有毒气，金丝雀发布由此得名。
金丝雀测试需要完善的监控设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回滚的依据。
如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。
缓存数据