前言
本文探讨了高可用性的核心概念及其实现方法。强调通过冗余设计、故障发现与处理机制、技术方案和资源隔离等策略，来确保服务的持续可用。
1. 高可用的本质是什么
冗余！冗余！冗余！
2. 什么会导致服务不可用
- 硬件故障
网络、存储 - 软件故障
代码 Bug、发版、超大流量 - 不可抗力
火灾、水灾等
3. 如何实现高可用
3.1 故障发生
故障发生分为 3 个部分：故障发现，故障处理，故障复盘
- 故障发现
要求服务具备良好的可观测性，可以接入 Prometheus 或其他监控框架，如 Cat。同时需接入第三方告警系统，例如夜莺和睿象云。 需要在 1 分钟内实现故障发现。发现故障后，警告信息可以通过邮箱、飞书和微信等渠道发送；对于严重告警，则应直接通过电话进行通知。 - 故障处理
开发人员应在5分钟内响应告警信息并进行处理。恢复服务应作为第一优先级，而问题根因的排查则为第二优先级。此外，服务需具备可回滚的能力，以确保快速恢复。 需要注意的是，服务的负责人并不总能及时响应告警。当严重告警信息无人处理时，应进行告警升级，将告警信息发送给团队领导（TL）。 - 故障复盘
4层5why + 1落地。从流程机制层面、质量校验层面、产品业务层面、系统设计层面思考5个为什么。为什么会发生，为什么没在质量验证时被发现，发生后如何防御，如何避免再次发生，有没有改进点。
在总结以上思考后，应落地故障快速处理文档，为后续人员提供参考，确保在故障再次发生时，能够迅速有效地进行处理。
3.2 技术方案（故障避免）
从 容量评估、流量防护、容错管理、容灾管理 4 个方面来避免故障发生。
3.2.1 容量评估
服务应进行全链路压测，以全面评估服务的整体容量。这是实施流量防护的前置要求
3.2.2 流量防护
- 在网关层接入 WAF，以防范攻击
- 根据容量评估结果实施限流措施
3.2.3 容错措施
容错措施有多种，常见的包括：
- 熔断机制
- 兜底处理
- 超时配置
- 非核心逻辑出错时，不应影响业务的正常运行。例如，应捕获非核心流程的异常，以确保业务的连续性
- 减少对其他服务的依赖
- 代码、配置和服务应具备快速回滚能力
- 风险较高的功能上线时，需支持灰度发布或快速启停
- 服务上线时采用灰度发布策略
- 服务至少有 2 个副本
- 在不同可用区内部署对等数量的服务，避免某一个可用区挂掉后，服务不可用
- 优先在同可用区内进行 RPC 调用
3.2.4 容灾管理
网上有许多方案可供选择，例如同城多活、两地三中心和异地多活等。个人认为，从成本和实施难度的综合考虑，同城多活是比较适合大多数中小公司的方案。
3.3 资源隔离（降低故障影响）
资源隔离可分为服务内资源隔离与服务外资源隔离。 服务外资源常见如：MySQL、Redis、域名等。 服务内资源常见如：线程池、队列
这里简单一笔带过，后续文章会深入讲解。
4. 结语
在技术方案中，许多知识点（如熔断、限流等）尚未深入探讨。这部分内容将在后续文章中详细分析。