微服务架构-雪崩效应
微服务化产品线，每一个服务专心于自己的业务逻辑，并对外提供相应的接口，看上去似乎很明了，其实还有很多的东西需要考虑，比如：服务的自动扩充，熔断和限流等，随着业务的扩展，服务的数量也会随之增多，逻辑会更加复杂，一个服务的某个逻辑需要依赖多个其他服务才能完成。一但一个依赖不能提供服务很可能会产生雪崩效应，最后导致整个服务不可访问。 微服务之间进行rpc或者http调用时，我们一般都会设置调用超时，失败重试等机制来确保服务的成功执行，看上去很美，如果不考虑服务的熔断和限流，就是雪崩的源头。 假设我们有两个访问量比较大的服务A和B，这两个服务分别依赖C和D,C和D服务都依赖E服务 A和B不断的调用C,D处理客户请求和返回需要的数据。当E服务不能供服务的时候，C和D的超时和重试机制会被执行 由于新的调用不断的产生，会导致C和D对E服务的调用大量的积压，产生大量的调用等待和重试调用，慢慢会耗尽C和D的资源比如内存或CPU，然后也down掉。 A和B服务会重复C和D的操作，资源耗尽，然后down掉，最终整个服务都不可访问。 常见的导致雪崩的情况有以下几种： 程序bug导致服务不可用，或者运行缓慢 缓...
