服务治理：理清服务的强弱依赖，提升高可用能力

42 阅读 0 评论 28 点赞

我是靠谱客的博主长情彩虹，最近开发中收集的这篇文章主要介绍服务治理：理清服务的强弱依赖，提升高可用能力，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

在进行系统开发的过程中，由于业务的需要通常可能会形成“服务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、针对强依赖的服务，需要制定良好的应急预案进行兜底，同时应该提供良好的用户体验。

文章内容仅代表个人观点，如有不正之处，欢迎批评指正，谢谢大家。