（一）服务崩溃的诱因：
1）服务自身问题：
业务升级，同一个应用服务中加入越来越多的功能模块，导致上游调用量变大，各个功能模块之间耦合，相互依赖，一损俱损；
流量突然增加(DDos攻击，上线秒杀类型的高并发服务)，超过服务所能支撑的容量，负载均衡、容灾策略未能提供有效保护，没有有效限流策略。
2）下游服务崩溃导致服务不可用，没有做好熔断、降级策略。
3）依赖组件崩溃或升级导致服务不可用，调用服务没有及时升级版本，没有做好熔断、降级策略。
（二）服务内部问题：
1）大事物，在某事物中存在循环逻辑、rpc调用、http请求、发送消息等耗时操作。通常这会长期占有数据库的连接，导致数据库连接池爆满，使得其他请求获得数据库连接的服务不可用；
2）慢查询，查询的数据行太多，或是返回的数据列太多，或是没有有效使用索引；
3）可能产生频繁full gc的业务逻辑，如频繁从数据库中捞取大量数据；
4）陈旧代码没有及时删除，导致后期维护困难。
（三）服务间问题：
1）降级，上游服务调用下游服务时，下游服务调用超时或爆出异常或直接宕机不可用，导致上游服务也不可用，调用链路上的某个服务不可用，可能会导致上游链路上若干个服务都不可用，问题被逐步放大。此时需要有熔断策略，禁止再调用不可用的下游服务，转而提供有损服务，保证上游服务不宕机，保证上游服务所在应用的其他服务依然能够正常运行；
2）限流，时刻提防上游服务激增的的调用量。可采用线程池隔离的方法，给应用中不同的服务分配限量的线程池。
3）强依赖，强依赖转换为弱依赖。