Actuator自定义端点：应注解在Controller层还是Service层？

核心判定标准 #

判定的核心依据是端点的职责定位以及是否依赖业务逻辑复用：

• 如果端点是独立的运维监控接口，和业务逻辑无强关联，优先放在Controller层
• 如果端点需要复用现有业务逻辑、或本身是业务状态的监控，优先放在Service层

适合注解在Controller层的场景 #

• 独立运维监控接口：端点逻辑完全独立，不需要调用业务Service，仅用于暴露应用级监控信息（如节点信息、JVM状态、配置参数）
  示例代码：

  @RestController
  @Endpoint(id = "app-meta")
  public class AppMetaEndpoint {
      @ReadOperation
      public Map<String, Object> getAppMeta() {
          Map<String, Object> meta = new HashMap<>();
          meta.put("app-name", "order-service");
          meta.put("active-profiles", Arrays.toString(Environment.getActiveProfiles()));
          meta.put("uptime", ManagementFactory.getRuntimeMXBean().getUptime());
          return meta;
      }
  }
  

• 需要处理HTTP请求细节：端点需要直接操作HTTP请求参数、请求头，或依赖Spring MVC特性（如参数校验、权限拦截），放在Controller层可以直接利用Spring MVC的注解能力完成这些处理

适合注解在Service层的场景 #

• 复用业务逻辑的监控端点：端点需要获取的监控数据已经在业务Service中有成熟的获取逻辑，直接在Service方法上标注注解，避免重复代码
  示例代码：

  @Service
  @Endpoint(id = "order-monitor")
  public class OrderService {
      private final OrderRepository orderRepo;
  
      public OrderService(OrderRepository orderRepo) {
          this.orderRepo = orderRepo;
      }
  
      @ReadOperation
      public Long getTodayCompletedOrderCount() {
          LocalDate today = LocalDate.now();
          return orderRepo.countByStatusAndCreateTimeBetween(OrderStatus.COMPLETED, today.atStartOfDay(), today.atTime(23,59,59));
      }
  
      // 其他业务方法...
  }
  

• 业务强关联的监控：端点监控的是业务领域内的状态（如待处理任务数、业务指标统计），这类监控逻辑和业务逻辑耦合度高，放在Service层可以保证监控逻辑与业务逻辑的一致性，避免业务变更时监控逻辑脱节

额外注意事项 #

• 遵循单一职责原则：Controller层端点专注于HTTP接口暴露和请求处理，Service层端点专注于业务相关监控数据的计算与提供
• 不要跨职责处理：Service层端点不要直接处理HTTP请求细节，Controller层端点不要编写复杂业务逻辑，应通过调用Service层获取数据

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