高可用（HA）即High Availability，是分布式系统架构设计中一个重要方面。业界通常用n个9来衡量系统的可用性，具体如下表所示：
通过上表可以发现，1个9和2个9的系统年故障时间是按天算的，日故障时间是按小时算的，也就是每年总有那么几天或每天总有那么几个小时系统不可用，满足该指标的系统只能算基本可用，也是最容易达到的，基本上靠人工运维的方式就能实现。3个9的系统年故障时间从3天锐减为8小时，系统具有较高可用性。4个9的系统年故障时间为50多分钟，这种系统不能依靠人工运维方式实现高可用，而是需要系统具有自动恢复能力。5个9的系统年故障时间为5分钟，满足该指标的系统具有极高的可用性，不过实现的难度和代价也是非常大的，只有公司的核心业务系统或国家级基础设置才会确保满足5个9甚至6个9的指标，比如支付宝，微信支付，国家金融系统等，其他非核心系统满足4个9的指标已经够用了。
可用性差异在于面对各种故障时，系统的高可用架构设计方案做的是否足够好。在架构设计之初，要避免单点故障，路由、防火墙、负载均衡、反向代理及监控系统等在网络和应用层面上必须全部是冗余设计，以此来保证最佳的可用性。下面介绍一些提高系统可用性的常规方法。
1.服务冗余
主备模式是传统的服务冗余方法之一，根据策略又可分为N+1、N+2 等模式。N+1的主备模式，即将两个设备绑成设备对儿。针对频繁变更的系统，单纯的主备模式不够用，由此建议至少部署N+2个实例。N+2的主备模式能够保证一个实例发生变更时，如果第二个实例发生故障，至少还有一个实例保证业务不中断。
2.负载均衡
负载均衡已经是高可用架构中重要手段，通过按权重负载均衡、按地域就近访问等手段提升系统的整体性能，避免因为过载而导致整个系统全地域失效。
3.服务无状态化
所谓无状态化是指每个服务实例的服务内容和数据都是一致的，如果服务是无状态的，可对服务随时进行扩缩容。目前微服务的主流趋势，有利于服务在各个容器云平台上的部署。如果服务是有状态的，那么逻辑处理是依赖于数据的，应该将“有状态”的数据部分剥离出来，借助擅长数据同步的中间件使数据实现集中管理，保证数据的一致性，如下图所示：
4.服务拆分
将一个大的系统拆分成多个独立的小模块，各个模块之间相互调用，是减少故障影响范围的主要手段，如下图所示。将复杂的业务进行拆分以降低复杂度。读写分离是拆分的一种方式。写请求依赖主数据设备，读数据依赖备数据设备。当出现故障时，可以只开发读服务，写服务暂时关闭，从而减少了故障的影响面。但需要关注数据的一致性问题。
5.服务降级
服务降级是当故障发生时减少故障所造成的损失，常见的流量管理手段有限流和熔断。限流可以结合业务进行自定义配置，优先保证核心服务的正常响应，非核心服务可直接关闭。熔断是客户端在发出请求后，无法在固定期限收到预期目标，从而采取服务降级的手段。
6.服务监控
完善的监控系统对整个系统的可靠性和稳定性是非常重要的，可靠性和稳定性是高可用的一个前提。
没有回复内容