国际站后端业务不断扩展,支撑的服务实例规模也越来越大。并且在此过程中,支持了双云及多地部署。
这也给服务治理带来了挑战,如何应对同城多机房路由、多地容灾等场景,并解决微服务优雅上下线等问题,是国际站业务拓展亟需解决的课题。
本文将从设计、开发、实践各个维度,叙述爱奇艺解决上述问题的思路和实践。
01
SpringCloud客户端路由
客户端就近路由
什么是就近路由?在业务多机房部署场景中,内部服务如果存在大量的跨机房、甚至跨地域的网络调用,则请求时延会显著加大,会直接影响到服务质量,甚至是用户体验。
但是在一般的微服务架构中,路由策略并不支持这种机房或者地区的多级别判断。所以实现自定义的客户端负载均衡路由变得迫在眉睫。
在常规单机房部署的时候,如下图中的dc1中,consumer只会请求到provider1,整个链路并没有什么问题。但是当需要多机房多区域部署的时候,瓶颈就出现了。假设有下图的简单部署场景:
provider分别部署在同zone的dc1、同region的dc2和不同region的dc3
各自注册到所在dc的注册中心
可以预想到会有以下几个问题:
如果consumer能从注册中心获取到所有provider列表,那么它会轮询请求,这样正常情况下就会跨机房访问
如果consumer不能从注册中心获取到provider2和provider3,那么在容灾情况下,provider1挂了,不能故障转移到provider1和provider2
这里就有了智能路由的概念,也就是就近路由,如何满足需求呢?需要做到以下几点:
各consumer能获取到其他dc的实例列表,也就是注册中心需要支持多dc
正常情况下,consumer的流量只会请求到同dc的provider1(通道1),而不会跨机房访问
当同dc的provider出现不可用情况下,会首先降级到不同dc但是同region的provider2(通道2),如果provider2也不可用,才会降级到不同region的provider3(通道3)
在讨论实现之前,先同步一下我们后面要用到的idc、zone及region的概念。
idc、zone及region
这里先给出 AWS 的 Region 和 AZ 示意图,如下: