系统依赖关系比较复杂情况：
A系统依赖B系统资源，当B系统发生故障的时候，A系统势必会被拖累，导致A系统也发生故障 。这里的依赖要区分两种情况：
1、A强依赖于B 任何强依赖都要尽可能的转化成弱依赖，因为强依赖本身意味着一荣俱荣，一损俱损。
对于强依赖B这个场景，从稳定性来说我们还是可以做一些事情：
当B发生故障，虽然A系统不能正常执行业务，但是A不能挂掉，一旦B系统恢复，A系统也要做到立即恢复。同时A有责任对B要进行流量保护，而不是对B进行摧残。 如果系统没有做特殊的保护，当分流的量大于了单机的容量，持续一段时间后，系统将不能很好的恢复，即便我们把分流进入的量减少到系统容量以下也不能快速恢复。
2、A弱依赖于B 此时B如果发生了故障，那么大家都期望A继续能提供正常的服务 。
场景1：A调用B，A的主流程不需要等待B的返回结果 浏览器弱依赖：A从浏览器上发起异步请求，如果B挂了，那么只会出现页面某一个区域不显示B的内容，如果对于用户交互可以接受，那么系统层面无任何问题，商品详情页面的评论列表和购买记录就是这个情况 异步线程：A调用B的时候只发送消息，然后调用动作由另外的线程来执行，并且不需要即时反馈结果，一般作为消息通知，轨迹记录等场景使用。不过为了防止堆积，也需要控制队列的大小
场景2：A调用B，A的主流程需要等待B的返回结果 设置超时时间：如果B响应超时，则抛出超时异常，绝对大部分情况下OK；不过两种影响要考虑：1、超时时间设置过长或者过短导致的副作用 2、大量异常抛出 设置最大并发请求数阀值，一旦超过阀值就跳过访问B 两种方式相结合使用最佳。