服务启用/禁用最佳实践：两种实现方案的抉择与优化建议

我们有ServiceA服务，需要在部分环境配置（profile）中正常运行，其他配置下禁用（调用该服务时不执行任何操作）。目前想到两种实现方式，以下是分析及更优方案推荐：

方案1：配置isEnabled属性 #

直接在服务类中注入启用配置，每个业务方法开头判断是否启用：

public class ServiceA {
    @Value("${isEnabled:true}")
    private final boolean isEnabled;

    public void do() {
      if (!isEnabled) return;
      // 实际业务逻辑
      ...
    }
}

问题点：

• 违反单一职责原则：服务类既要处理核心业务逻辑，又要承担启用状态判断的额外职责
• 冗余且易出错：若服务有多个方法，每个方法都要重复添加if(!isEnabled)判断，遗漏的概率高

方案2：利用Spring条件注解 #

先定义ServiceA接口，再实现两个类分别对应启用和禁用状态，通过条件注解控制实例化：

// 定义接口
public interface ServiceA {
    void do();
}

// 实际业务实现
@ConditionalOnProperty(name = "isEnabled", havingValue = "true", matchIfMissing = true)
public class RealServiceA implements ServiceA {
    @Override
    public void do() {
        // 实际业务逻辑
        ...
    }
}

// 禁用时的空实现
@ConditionalOnProperty(name = "isEnabled", havingValue = "false")
public class NoOpServiceA implements ServiceA {
    @Override
    public void do() {
        // 空实现，无任何操作
    }
}

优势：

• 职责清晰：业务逻辑和禁用逻辑分离到不同类中，符合单一职责原则
• 无冗余判断：业务方法无需关心启用状态，降低出错概率

不足：

• 会新增接口和额外的实现类，若多个服务都采用此方案，类数量会增加，可能让代码结构显得繁琐

方案选择与更优实现 #

优先推荐：条件注解方案 #

虽然会增加类的数量，但职责清晰、低出错率的收益远大于类数量增加的成本。可以通过将接口、真实实现、空实现放在同一个子包下的方式，提升代码可读性，避免类分散导致的混乱。

更优简化方案：Spring AOP动态代理 #

如果觉得新增类太繁琐，可通过AOP实现统一的启用判断，无需修改原有业务代码：

1. 自定义注解标记需要启用判断的服务
2. 编写切面拦截方法，统一处理启用状态判断

示例代码：

// 自定义启用检查注解
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface EnableCheck {
    // 可指定配置项名称，默认使用isEnabled
    String configKey() default "isEnabled";
}

// 切面类，统一处理启用判断
@Aspect
@Component
public class EnableCheckAspect {
    @Autowired
    private Environment environment;

    @Around("@target(enableCheck)")
    public Object checkEnabled(ProceedingJoinPoint joinPoint, EnableCheck enableCheck) throws Throwable {
        String configKey = enableCheck.configKey();
        // 默认启用
        boolean isEnabled = Boolean.parseBoolean(environment.getProperty(configKey, "true"));
        
        if (!isEnabled) {
            // 根据方法返回类型返回默认值，适配不同返回值场景
            return getDefaultReturnValue(joinPoint.getSignature().getReturnType());
        }
        // 启用状态下执行原方法
        return joinPoint.proceed();
    }

    private Object getDefaultReturnValue(Class<?> returnType) {
        if (returnType.isPrimitive()) {
            if (returnType == boolean.class) return false;
            if (returnType == int.class) return 0;
            if (returnType == long.class) return 0L;
            // 其他基本类型可按需补充
        }
        return null;
    }
}

// 在ServiceA上添加注解即可
@EnableCheck
public class ServiceA {
    public void do() {
        // 实际业务逻辑
        ...
    }
}

这种方案的优势：

• 无侵入：无需修改原有业务方法，也不用新增大量实现类
• 统一管理：通过切面集中处理所有服务的启用判断，符合DRY原则
• 灵活性高：可通过注解参数指定不同的配置项，适配多个服务的不同启用规则

内容的提问来源于stack exchange，提问作者Flame239