【架构实战】健康检查与故障转移机制
一、为什么需要健康检查在分布式系统中服务实例可能因为各种原因变得不可用而调用方却毫不知情继续向故障实例发送请求导致大量失败。常见的服务不可用场景-进程假死Java进程存在但无法响应请求Full GC、死锁-资源耗尽CPU 100%、内存OOM、连接池耗尽-网络故障网络分区、防火墙规则变更-依赖故障数据库、缓存等依赖服务不可用-代码异常未捕获的异常导致服务降级健康检查的价值- 及时发现不健康实例- 自动从负载均衡中剔除故障节点- 故障恢复后自动重新加入- 为故障转移提供决策依据二、健康检查的分类### 1. 主动健康检查 vs 被动健康检查| 类型 | 说明 | 优点 | 缺点 ||------|------|------|------|| 主动检查 | 定期主动探测服务状态 | 及时发现故障 | 增加额外请求 || 被动检查 | 根据实际请求结果判断 | 无额外开销 | 发现故障较慢 |最佳实践两者结合使用### 2. 检查层次L1: 进程检查进程是否存在L2: 端口检查端口是否可连接L3: HTTP检查接口是否正常响应L4: 业务检查核心业务逻辑是否正常## 三、Spring Boot健康检查### 1. Actuator健康端点xmldependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId/dependencyyamlmanagement: endpoints: web: exposure: include: health,info,metrics endpoint: health: show-details: always health: db: enabled: true redis: enabled: true### 2. 自定义健康检查javaComponentpublic class DatabaseHealthIndicator implements HealthIndicator { Override public Health health() { // 检查数据库连接 return Health.up().withDetail(database, MySQL).build(); }}## 四、Nginx健康检查nginxupstream backend { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s;}## 五、Kubernetes健康检查### 1. 存活探针Liveness ProbeyamllivenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 102. 就绪探针Readiness ProbeyamlreadinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 10 periodSeconds: 5### 3. 启动探针Startup ProbeyamlstartupProbe: httpGet: path: /actuator/health port: 8080 failureThreshold: 30 periodSeconds: 10## 六、故障转移机制### 1. 客户端故障转移RibbonjavaBeanpublic IRule ribbonRule() { return new RetryRule(new RoundRobinRule(), 3);}### 2. Feign重试配置javaBeanpublic Retryer feignRetryer() { return new Retryer.Default(100, 1000, 3);}### 3. Sentinel熔断降级javaSentinelResource(value getUserInfo, fallback getUserInfoFallback)public UserInfo getUserInfo(Long userId) { return userClient.getUser(userId);}七、最佳实践### 1. 健康检查设计原则-快速响应健康检查接口应在100ms内返回-轻量级不要在健康检查中执行复杂逻辑-分层检查区分存活检查和就绪检查-避免级联健康检查不应触发其他服务的健康检查### 2. 故障转移策略快速失败 → 重试 → 熔断 → 降级 → 告警## 八、总结健康检查与故障转移是高可用架构的核心机制-多层次检查进程→端口→HTTP→业务-主被动结合主动探测 被动感知-快速响应及时发现故障快速切换-自动恢复故障恢复后自动重新加入**实施建议**1. 所有服务都要实现健康检查接口2. K8s部署必须配置三种探针3. 设置合理的超时和重试策略4. 建立完善的监控告警体系个人观点仅供参考数据染色的方法
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2468364.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!