微服务保护和分布式事务

微服务保护

前面学过了组件Spring Cloud - 韩熙隐ario - 博客园，我们已经可以解决业务中99%的问题了。

我们还可以拥有一些高级的能力，比如：

• 服务保护：业务的优化、系统健壮性的处理和疑难问题的阶段等
• 分布式事务：服务独立，各自操作数据库，如何保证ACID。

服务保护

• 雪崩问题

雪崩问题

保证服务运行的健壮性，避免级联失败导致的雪崩问题，就属于微服务保护。

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

比如商品服务出现问题。在购物车积累了很多请求。导致资源耗尽，影响其他服务B的请求。

这样，就造成了雪崩问题

雪崩问题产生的原因是什么？

• 微服务相互调用，服务提供者出现故障或阻塞。
• 服务调用者没有做好异常处理，导致自身故障。
• 调用链中的所有服务级联失败，导致整个集群故障

解决问题的思路有哪些？

• 尽量避免服务出现故障或阻塞。【避免出错】
  • 保证代码的健壮性；
  • 保证网络畅通；
  • 能应对较高的并发请求；
• 服务调用者做好远程调用异常的后备方案，避免故障扩散【减少影响】

服务保护方案

• 请求限流：限制访问微服务的请求的并发量，避免服务因流量激增出现故障。

  避免把服务压垮。限流器。但也无法确保服务不出问题

  

• 线程隔离：也叫做舱壁模式，模拟船舱隔板的防水原理。通过限定每个业务能使用的线程数量而将故障业务隔离，避免故障扩散。

  限定每个业务使用的线程数量，将故障隔离。避免故障扩散。减少能影响的数量。

  

• 快速失败：给业务编写一个调用失败时的处理的逻辑，称为fallback。当调用出现故障（比如无线程可用）时，按照失败处理逻辑执行业务并返回，而不是直接抛出异常。

  

• 服务熔断：由断路器统计请求的异常比例或慢调用比例，如果超出阈值则会熔断该业务，则拦截该接口的请求。熔断期间，所有请求快速失败，全都走fallback逻辑。

  发现异常后，拒绝请求，所有请求快速失败，走fallback【fallback可以说是后续的过程，补充，兜底】。可以返回友好提示等内容。这样就少了远程调用和等待的过程了。

  

服务保护技术

方案有了，代码要自己写吗？

其实有现成的技术了。主要的是下面两个技术，分别由阿里和网飞开发的

	Sentinel	Hystrix
线程隔离	信号量隔离	线程池隔离/信号量隔离
熔断策略	基于慢调用比例或异常比例	基于异常比率
限流	基于 QPS，支持流量整形	有限的支持
Fallback	支持	支持
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善
配置方式	基于代码。也可以基于控制台，但基于控制台重启后失效。	基于注解或配置文件，永久生效

未完待续……