Spring Boot应用中如何在服务B的就绪探针中检测依赖服务A？

场景：Spring Boot应用中的每个服务都已暴露存活（liveness）和就绪（readiness）端点，部分服务存在依赖关系，需要在服务B的就绪探针中验证服务A是否可用。

以下是两种可行方案：

方案1：自定义Spring Boot健康指示器 #

通过扩展Spring Boot Actuator的健康指示器，把服务A的状态纳入服务B的就绪检查逻辑：

• 编写ServiceAHealthIndicator类，实现HealthIndicator接口，在方法中调用服务A的存活端点判断其可用性：

  import org.springframework.boot.actuate.health.Health;
  import org.springframework.boot.actuate.health.HealthIndicator;
  import org.springframework.web.client.RestTemplate;
  import org.springframework.stereotype.Component;
  
  @Component("serviceA")
  public class ServiceAHealthIndicator implements HealthIndicator {
  
      private final RestTemplate restTemplate;
      // 可通过配置注入服务A的地址
      private final String serviceALivenessUrl = "http://serviceA:8000/health/liveness";
  
      public ServiceAHealthIndicator(RestTemplate restTemplate) {
          this.restTemplate = restTemplate;
      }
  
      @Override
      public Health health() {
          try {
              // 调用服务A的存活端点
              restTemplate.getForEntity(serviceALivenessUrl, String.class);
              return Health.up().withDetail("serviceA", "服务A正常运行").build();
          } catch (Exception e) {
              return Health.down()
                      .withDetail("serviceA", "服务A不可用")
                      .withDetail("错误信息", e.getMessage())
                      .build();
          }
      }
  }
  

• 在application.yml中配置，将该自定义指示器加入就绪健康检查分组：

  management:
    endpoint:
      health:
        group:
          readiness:
            include: serviceA
  

  配置生效后，服务B的/actuator/health/readiness端点会包含服务A的状态，只有当服务A可用时，服务B的就绪探针才会返回成功。

方案2：直接在Kubernetes配置中检测服务A #

如果服务部署在Kubernetes集群中，可以直接修改服务B的Deployment配置，让就绪探针直接请求服务A的存活端点：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-b
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: service-b
        image: your-service-b-image:latest
        readinessProbe:
          httpGet:
            # 服务A的存活端点路径
            path: /health/liveness
            # 服务A的端口
            port: 8000
            # 服务A的Kubernetes服务名（集群内可直接访问）
            host: serviceA
          # 初始化延迟时间，避免启动时误判
          initialDelaySeconds: 15
          # 检查间隔
          periodSeconds: 5
          # 失败阈值
          failureThreshold: 3

这种方式无需修改服务B的代码，直接在基础设施层面完成依赖检查，但要确保服务B的Pod能够访问到服务A的端点（通过Kubernetes Service或ClusterIP）。

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