Last Updated on 2024-11-27 by likun.gong

解决单点

在高可用中，应该避免单点的存在

• 业务服务多副本
• controller 控制器多副本
• 多可用区部署
• NAT 多公网 IP 出口
• 数据库等中间件可以采取主从模式，单点故障时可以快速切换
• 告警单点，避免告警接口人在一个人身上，导致通知失败

资源确保

资源的量需要有保障，避免出现资源不足的情况

• 对于 K8S 中关键性的组件，确保有足够的资源。我们可以利用 Affinity 和 Taints 机制，确保关键组件运行在单独的节点池上，避免受到其他业务的影响。

• 常规业务，需要规划好 requests 和 limits，合理分配资源，配合资源监控，及时调整，避免资源浪费或者不够。

• 可以利用 Karpneter 或者 Cluster Autoscaler 等组件，动态扩展节点池，确保计算资源足够

监控完善

利用 Prometheus 和 Grafana 监控资源利用和业务相关指标，制定高优先级告警规则，及时发现问题

• 中间件监控，CPU、内存、连接数、主从读写延时、消息堆积等等指标
• 容器资源使用监控，流量敏感型服务需要添加流量监控
• 应用监控和链路追踪，从应用内部获取到处理是否有异常并及时告警
• 异常日志监控
• 网关层监控，用量波动和大批量错误发生时应及时告警
• 云产品 Quota 监控，不够时及时申请更多的 Quota

在告警的时候，需要有相应的重复机制，在一段时间内未恢复，需要再次提醒，同时也可以考虑告警上升机制。

兜底机制

在设计系统的时候，需要考虑出现问题之后如何兜底

• 重试，业务内部可以添加重试机制，例如在下载 S3 文件的时候，就可以添加重试机制
• 重连，对于中间件的连接应具备重连机制，避免中间件出现主从切换、引擎补丁安装重启之后自动重连回来
• 数据备份，开启云数据库的实时备份，可以快速恢复到备份期限内特定时间点的数据，定期检查备份的有效性
• K8S 的就绪检查（Readiness Probe）和健康检查（Liveness Probe）配置，确保健康检查不可用时触发 K8S 的重启机制
• 入口流量快速切换。应该准备备用链路，在遇到特殊情况下，可以快速增加入口流量带宽或者切换到备用入口
• 限流机制，业务应该有相应的限流机制，避免系统被突然的大流量击垮，导致无法提供服务

总结

不出问题不代表没有问题，很多时候需要系统的考虑哪里可能出问题，应该如何避免，以及出问题之后有哪些处理措施。

平时也需要多加演练，在故障发生时也能更加胸有成竹。