雪崩效应

现如今SOA、微服务风愈演愈烈,越来越多的业务和资源被以服务的形式包装和发布,服务间又可能会依赖其他各种服务。由此而来不可避免的会产生很多问题。

比如一个服务,其依赖了另外30个服务。假设每个服务的可用率都有三个9(99.9%),那么我们计算一下:

99.99%^30 = 99.7%

现实很残酷,这个服务的实际可用性只能是99.7%,也就是说每个月这个服务都要好宕机8000+秒~~~

iOS培训,Swift培训,苹果开发培训,移动开发培训
正常用户请求时,服务内部依次请求A\P\H\I服务,兵返回响应结果。

iOS培训,Swift培训,苹果开发培训,移动开发培训
非常不幸,我们的I服务出了某些问题,此时我们的用户请求就被堵塞在I服务处。

iOS培训,Swift培训,苹果开发培训,移动开发培训
更加悲剧的是,后续越来越多的请求都被堵塞在I服务处,而这些被堵塞的请求会占用线程、IO、网络等系统资源,随着资源被占用的越来越多,本来不存在的性能问题也会随之而来,造成系统中的其他服务出现问题,甚至导致系统奔溃。

这也就是我们常说的雪崩效应


服务容灾

为了避免出现服务的雪崩,我们需要对服务做容灾处理。

常规的服务容灾处理思路有:

  • 资源隔离

  • 超时设定

  • 服务降级

  • 服务限流

其中每种思路又可以有不同的解决方案。

比如资源隔离可以通过将不同的服务发布在独立的docker容器或服务器中,这样即使一个服务出现问题,也不会殃及池鱼。

服务降级和服务限流可以通过前端nginx+lua来实现,当服务处理延迟或宕机时,nginx可以直接返回固定的降级/失败响应,已快速跳过问题服务。


Hystrix

Hystrix,是Netflix的一个开源熔断器,通过Hystrix,我们可以很方便的实现资源隔离、限流、超时设计、服务降级等服务容灾措施,并且还提供了强大的监控,可