淘宝系统依赖关系比较复杂。A系统依赖B系统资源，当B系统发生故障的时候，A系统势必会被拖累，导致A系统也发生故障
图：[ A]--依赖-->[B]
这里的依赖要区分两种情况
1、A强依赖于B
任何强依赖都要尽可能的转化成弱依赖，因为强依赖本身意味着一荣俱荣，一损俱损。老婆管账，但是老公又没有私房钱，对老公来说强依赖于老婆，也许是很幸福的事情。在系统角度来说这并不是好事情，比如支付系统强依赖银行的支付，一旦银行支付出现问题，那么只能干等着。所以需要尽量的扩展银行的支付通道，让单个节点影响到最小。
对于强依赖B这个场景，从稳定性来说我们还是可以做一些事情：当B发生故障，虽然A系统不能正常执行业务，但是A不能挂掉，一旦B系统恢复，A系统也要做到立即恢复。同时A有责任对B要进行流量保护，而不是对B进行摧残。
我和小赌对淘宝某一前台系统做过一次分流压测（和ab，httpload等压测不同，是直接将正常的用户请求不断引入的压测方式，本质区别是分流压测方式用户数会持续不断的增加，ab等则是固定用户数）：A系统单机的容量是4，当前的进入的流量是1。进行分流压测，不断增加单机的流量，直到该单机的流量到4，此时一切正常，流量增加到5，此时响应时间突增，减少流量到4，响应时间还是很长，持续一段时间不能自己恢复，再减少到3，系统还是没有恢复，直到减少到2之后，系统恢复。原因是系统被压垮之后，其容量发生了变化，原来容量是4，压垮之后容量变成了2.5。
此时系统会有比较频繁的fullgc产生，做个简单的分析，因为用户不断增加，而容量有不够只能堆积，导致线程数量大增，直到max-limit值，并且由于强资源，导致每个线程完成工作的时间变长，minagc发生的时候大量的eden区对象不能被回收，拷贝到s0 or s1又放不下或者超过交换次数后被拷贝到了old区。
所以摧残一个系统不好，同时也说明如果系统没有做特殊的保护，当分流的量大于了单机的容量，持续一段时间后，系统将不能很好的恢复，即便我们把分流进入的量减少到系统容量以下也不能快速恢复。
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
- 两种方式相结合使用最佳