云原生应用如何实现高可用_云原生高可用架构说明

云原生高可用需“多副本+自愈+隔离+可观测”四层联动，缺一不可；须配liveness/readiness/startup探针、PDB、Init Container，确保Service/Ingress流量对齐，客户端超时重试+熔断，依赖组件（mysql/redis等）必须高可用，可观测性是前提。

云原生应用的高可用不是靠单个技术堆出来的，而是靠“多副本 + 自愈 + 隔离 + 可观测”四层联动实现的。没这四层，光写个 Deployment 设 3 个副本，照样会挂。

怎么让 kubernetes 真正自动救活你的服务？

很多人以为设了 replicas: 3 就高可用了，但 Pod 崩溃后 K8s 能不能及时拉起、会不会反复 Crash、有没有卡在启动依赖上，全看探针和调度配置是否到位。

• 必须配 livenessProbe 和 readinessProbe：前者决定要不要杀掉重启，后者决定要不要从 Service 流量池里摘掉；不配或配错（比如 initialDelaySeconds 太小），会导致服务刚起来就被干掉，陷入 CrashLoopBackOff
• 用 startupProbe 替代过长的 initialDelaySeconds：golang 应用冷启动慢时，直接设 60 秒延迟不如用 startup 探针精准判断“真就绪”
• 加 PodDisruptionBudget（PDB）：滚动更新或节点维护时，防止所有副本被同时驱逐，比如 minAvailable: 2 能保底留两个实例在线
• Init Container 做前置检查：比如用 curl -f http://redis:6379/ping 确认 Redis 已就绪再启动主容器，避免应用启动失败反复重启

为什么多副本还总连不上？Service 和 Ingress 的常见断点

服务明明跑了 3 个 Pod，kubectl get pods 全 Running，但 curl 却超时——问题大概率出在流量链路的某一层没对齐。

• Service 的 selector 必须和 Pod 的 labels 完全一致：大小写、key 名、拼写一个字符都不能错；建议用 kubectl describe service xxx 查 Endpoints 字段，为空就是没匹配上
• Ingress 的 serviceName 和 servicePort 要跟后端 Service 的名字和端口严格对应；nginx Ingress 默认只处理 http，https 需额外配 tls 块和 Secret
• 跨命名空间调用要写全名：my-svc.my-ns.svc.cluster.local，光写 my-svc 只在同 Namespace 有效
• golang HTTP Server 必须监听 0.0.0.0:8080，不能只绑 127.0.0.1，否则 Pod 内部网络通，Service 流量进不来

微服务之间怎么避免“一崩带全垮”？

单体拆成微服务只是第一步，没做隔离和容错，故障照样会顺着调用链炸开。真正的解法是把“依赖不可靠”当成默认前提来设计。

• 客户端必须设超时和重试：Golang 用 context.WithTimeout 控制单次调用，gRPC 默认无超时；HTTP 调用别信服务端的 Keep-Alive，自己控连接池和最大重试次数
• 用熔断器（如 gobreaker）防雪崩：连续 5 次失败就打开熔断，后续请求快速失败，给下游留恢复时间；别等线程/连接耗尽才反应
• 关键路径避免强依赖：比如订单创建不等用户中心返回完整资料，先存 ID，异步补全；查不到时走降级逻辑（返回空头像、默认昵称）
• istio 的 DestinationRule 配 outlierDetection：比代码层熔断更轻量，且对所有语言透明，适合统一治理

数据库和中间件不高可用，应用再稳也没用

你把服务做到 99.99%，结果 MySQL 主从切换花了 5 分钟，整个系统还是不可用。云原生高可用的木桶短板，永远在依赖组件。

• MySQL 别用单节点：至少主从，生产环境推荐 MGR 或 proxySQL + 多从，确保 failover ；用 pt-heartbeat 监控主从延迟，超阈值自动告警
• Redis 建议用集群模式（Redis Cluster）或哨兵（Redis sentinel），别用单实例；连接客户端必须支持自动重连和拓扑刷新
• 有状态服务（如 kafka、elasticsearch）用 StatefulSet + 独立 PV，禁用 Deployment；每个 Pod 有稳定网络标识（pod-name-0），方便脑裂处理
• 所有中间件连接字符串里加 timeout 参数：比如 MySQL 的 connect_timeout=3、read_timeout=10，防止阻塞线程池

最容易被忽略的是“可观测性不是锦上添花，而是高可用的前提”。没有 prometheus 抓不到 5xx 突增，没有 Jaeger 追不到慢调用在哪一层，故障来了只能靠猜。日志、指标、链路三者得同时落地，缺一不可。