爱奇艺基于SpringCloud的韧性能力建设

国际站后端业务不断扩展，支撑的服务实例规模也越来越大。并且在此过程中，支持了双云及多地部署。

这也给服务治理带来了挑战，如何应对同城多机房路由、多地容灾等场景，并解决微服务优雅上下线等问题，是国际站业务拓展亟需解决的课题。

本文将从设计、开发、实践各个维度，叙述爱奇艺解决上述问题的思路和实践。

01

SpringCloud客户端路由

客户端就近路由

什么是就近路由？在业务多机房部署场景中，内部服务如果存在大量的跨机房、甚至跨地域的网络调用，则请求时延会显著加大，会直接影响到服务质量，甚至是用户体验。

但是在一般的微服务架构中，路由策略并不支持这种机房或者地区的多级别判断。所以实现自定义的客户端负载均衡路由变得迫在眉睫。

在常规单机房部署的时候，如下图中的dc1中，consumer只会请求到provider1，整个链路并没有什么问题。但是当需要多机房多区域部署的时候，瓶颈就出现了。假设有下图的简单部署场景：

1. provider分别部署在同zone的dc1、同region的dc2和不同region的dc3

2. 各自注册到所在dc的注册中心

可以预想到会有以下几个问题：

1. 如果consumer能从注册中心获取到所有provider列表，那么它会轮询请求，这样正常情况下就会跨机房访问

2. 如果consumer不能从注册中心获取到provider2和provider3，那么在容灾情况下，provider1挂了，不能故障转移到provider1和provider2

这里就有了智能路由的概念，也就是就近路由，如何满足需求呢？需要做到以下几点：

1. 各consumer能获取到其他dc的实例列表，也就是注册中心需要支持多dc

2. 正常情况下，consumer的流量只会请求到同dc的provider1（通道1），而不会跨机房访问

3. 当同dc的provider出现不可用情况下，会首先降级到不同dc但是同region的provider2（通道2），如果provider2也不可用，才会降级到不同region的provider3（通道3）

在讨论实现之前，先同步一下我们后面要用到的idc、zone及region的概念。

• idc、zone及region

这里先给出 AWS 的 Region 和 AZ 示意图，如下：