高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。
image.png
具体来说，系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段，以及故障发生时，逐一进行分析：
- 架构阶段：考虑系统的可扩展性和容错性，避免出现单点问题。例如多地单元化部署，即使某个IDC甚至地市出现故障，仍不会影响系统运转
- 编码阶段：保证代码的健壮性，例如RPC调用时，设置合理的超时退出机制，防止被其他系统拖垮，同时也要对无法预料的返回错误进行默认的处理
- 测试阶段：保证CI的覆盖度以及Sonar的容错率，对基础质量进行二次校验，并定期产出整体质量的趋势报告
- 发布阶段：系统部署最容易暴露错误，因此要有前置的checklist模版、中置的上下游周知机制以及后置的回滚机制
- 运行阶段：系统多数时间处于运行态，最重要的是运行时的实时监控，及时发现问题、准确报警并能提供详细数据，以便排查问题
- 故障发生：首要目标是及时止损，防止影响面扩大，然后定位原因、解决问题，最后恢复服务
对于日常运维而言，高可用更多是针对运行阶段而言的，此阶段需要额外进行加强建设，主要有以下几种手段：
- 预防：建立常态压测体系，定期对服务进行单点压测以及全链路压测，摸排水位
- 管控：做好线上运行的降级、限流和熔断保护。需要注意的是，无论是限流、降级还是熔断，对业务都是有损的，所以在进行操作前，一定要和上下游业务确认好再进行。就拿限流来说，哪些业务可以限、什么情况下限、限流时间多长、什么情况下进行恢复，都要和业务方反复确认
- 监控：建立性能基线，记录性能的变化趋势；建立报警体系，发现问题及时预警
- 恢复：遇到故障能够及时止损，并提供快速的数据订正工具，不一定要好，但一定要有
在系统建设的整个生命周期中，每个环节中都可能犯错，甚至有些环节犯的错，后面是无法弥补的或者成本极高的。所以高可用是一个系统工程，必须放到整个生命周期中进行全面考虑。同时，考虑到服务的增长性，高可用更需要长期规划并进行体系化建设。
网友评论