主服务通过就绪探活（readiness probe）+重试机制可靠等待子服务就绪，而非依赖启动顺序或sleep；需在应用启动流程中嵌入轮询逻辑，调用子服务/health/ready接口直至成功，并设置超时与间隔；k8s中可结合initcontainer或startupprobe简化实现。
主服务等待子服务就绪，核心不是靠“启动顺序”硬编码控制，而是通过**就绪探活（readiness probe）+ 重试机制**来实现可靠等待。单纯依赖容器启动先后或 sleep 等延时方式不可靠，容易因网络、负载、初始化耗时波动而失败。
用健康检查接口轮询子服务
主服务启动时，不直接初始化业务逻辑，而是先循环调用子服务提供的 HTTP 或 TCP 就绪接口（如 /health/ready），直到返回 200 或成功连接。
- 建议设置合理超时（如总等待上限 60 秒）和间隔（如 2~5 秒），避免卡死
- HTTP 方式示例：用 curl、fetch 或 client 库发 GET 请求；TCP 方式可用 telnet 或 socket 连接测试端口通断
- 注意区分 /health/live（存活）和 /health/ready（就绪）——后者才表示可接收流量
在应用启动流程中嵌入等待逻辑
把等待子服务就绪作为主服务启动的前置步骤，而非放在配置或脚本里。例如：
- Spring Boot：在 @PostConstruct 或自定义 ApplicationRunner 中执行轮询，失败则抛异常阻止启动
- Node.js：在 app.listen() 前 await 一个 checkReady() 函数
- Golang：在 main() 启动 HTTP server 前，调用 waitForService("http://redis:9181/ready")
借助运维层能力简化依赖管理
在 Kubernetes 等平台中，可结合原生机制减少代码侵入：
- 使用 initContainer：在主容器启动前，运行一个专用容器轮询子服务，成功后退出，保障主容器只在依赖就绪后启动
- 配置 startupProbe（K8s v1.16+）：让 kubelet 在容器启动初期持续探测，直到就绪才将流量接入，间接实现等待效果
- 避免仅靠 depends_on（Docker Compose）：它只控制容器创建顺序，不保证子服务内部已 ready
设计子服务就绪接口的关键点
子服务必须提供真实反映自身就绪状态的接口，不能只是“进程存活”：
- 检查关键依赖是否连通（如数据库连接池初始化完成、Redis 可写、下游 gRPC 服务响应正常）
- 避免缓存或静态返回；每次请求应实时校验核心组件状态
- 返回结构建议含 status、checks（各依赖项明细）、timestamp，便于调试
