在进行系统开发的过程中，由于业务的需要通常可能会形成“服务A>服务B>服务C>…>服务N”这样的调用链，不同的业务场景对于服务的依赖是有强弱之分的。只有结合业务场景的需要，对服务间的依赖关系做出合理性的判定，才能基于这份依赖关系对服务限流、服务容量、服务报警、代码影响范围、服务发布顺序等做出合理的评估，将系统的评估工作更加精细化，从而保证系统的稳定运行。避免因为系统的依赖问题，导致服务不可用，用户体验降低，企业资损等的可能。
一、定义
强依赖：假定服务A依赖于服务B，服务B出现故障不可用时，服务A也不可用，通常服务A会返回错误信息，我们称这种依赖为强依赖。
弱依赖：假定服务A依赖于服务B，服务B出现故障不可用时，服务A仍然可用，通常服务A会返回正确信息，只是与服务B相关的信息会不返回或者做默认处理，我们称这种依赖为弱依赖。
通过下面的流程图，我们来分析一下强弱依赖。从图中可以看到，在服务A中调用了服务B和服务C，但是他们的处理逻辑是不一样的。
1、调用服务B：如果调用成功，则接着调用服务C；如果调用失败，则服务A直接结束。这种场景我们称之为服务A强依赖于服务B。
2、调用服务C：不管调用成功还是失败，服务A会接续执行后续逻辑处理。这种场景我们称之为服务A弱依赖于服务C。
代码实现样例：
package org.learn.depend;
public class DependDemo {
public void serviceA(){
try {
System.out.println("it`s serviceA");
/// serviceA 强依赖于 serviceB
serviceB();
try {
/// serviceA 弱依赖于 serviceC
serviceC();
} catch (Exception e){
e.printStackTrace();
}
System.out.println("it`s completed");
} catch (Exception e){
e.printStackTrace();
}
}
public void serviceB(){
System.out.println("it`s serviceB");
}
public void serviceC(){
System.out.println("it`s serviceC");
}
}
二、如何鉴定强弱依赖
在正常的业务场景下，评估服务对业务的主功能是否有影响。如果有影响则认为该服务是强依赖的，反之则是弱依赖的。
在电商场景中，下单服务对于库存服务的依赖就属于强依赖，下单时必须校验是否有库存，只有在库存充足的情况下才可以下单。在库存服务不可用时，我们无法确认是否有库存，此时下单服务强依赖于库存服务，在下单时应该返回库存相关的错误信息。
在电商场景中，下单服务对于短信提醒服务的依赖就属于弱依赖。在短信提醒服务不可用时，依然可以进行正常下单，只是用户没有收到短信提醒，但不影响整个下单流程。此时下单服务弱依赖于短信提醒服务。
三、强依赖分析
服务A强依赖于服务B，当服务B不可用时，服务A要对服务B进行流量保护，防止过大的流量导致系统奔溃。同时要保证服务A不能瘫痪，在服务B恢复可用时，服务A也可以及时恢复可用。比如服务B不可用时，服务A对服务B进行多次重试，导致服务B直接奔溃。由于重试导致服务A中存在大量的待处理请求，最终导致服务A奔溃。
一般建议对服务B做降级处理，根据请求超时时间、并发请求数、请求失败数、请求返回的错误码做降级处理。服务A返回统一的错误信息。
四、弱依赖分析
服务A弱依赖与服务B，当服务B不可用时，服务A仍然可以正常运行，通常情况下我们将业务场景中的非必要服务作为弱依赖。在代码的处理上，可以分为一下集中方式：
1、服务A的主流程不依赖服务B的返回结果。
该场景可以有两种解决方式：
1）可以启动单独的线程进行服务B调用。
2）在当前线程中发消息，在消息消费线程中访问服务B。
2、服务A的主流程依赖服务B的返回结果。
与强依赖处理有些类似，一般建议对服务B做降级处理，根据请求超时时间、并发请求数、请求失败数、请求返回的错误码做降级处理。同时使用默认值来代替服务B的返回结果，默认值的设置需要根据具体的业务场景进行分析。
五、注意
在系统设计时一定要考虑系统的强弱依赖，着重注意一下几点：
1、在系统设计时要全面分析系统的强弱依赖关系，在系统上线后可以通过工具采集线上流量进一步分析依赖关系。
2、在强弱依赖发生变换时，要充分评估此项变更的风险，避免资损。
3、针对强依赖的服务，需要制定良好的应急预案进行兜底，同时应该提供良好的用户体验。
文章内容仅代表个人观点，如有不正之处，欢迎批评指正，谢谢大家。