聊聊服务的高可用

写一篇小短文，总结一下服务高可用的常见方案和技术。

1. 什么是高可用

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

对于描述一个服务的可用性，我们通常说这个服务达到了几个9的可用性，
比如有的系统的高可用是4个9，也就是99.99%，这就意味着系统的年停机时间为8.76个小时。

2. 如何保障系统高可用

核心原则：避免单点，冗余
但是仅仅只是冗余还不够，还要有“自动故障转移”机制

其他设计原则：

• 无状态
• 减少依赖
• 全链路监控
• 熔断机制
• 资源隔离
• 服务降级
• 容量规划
• 线上压测
• 设置超时

2.1 接入层的高可用

通常我们使用Nginx作为服务的接入层，那么Nginx的高可用我们通常使用keepalived + vip来实现。

2.2 服务层高可用

如果服务是挂在Nginx后面的，那么通过Nginx本身的健康检查机制就可以实现服务的高可用。
如果是注册中心或者服务网关，那么这些组件同样有自己的健康检查机制，能够及时的探测到不健康的节点并摘除，通常是通过心跳机制，由服务端每隔一定的时间向注册中心或者网关反馈心跳信息，如果注册中心或者网关长时间没有收到服务的心跳，那么就认为该服务不正常，然后就执行下线操作，从服务集群中摘除。

2.3 数据库的高可用

数据库的高可用，如果做了读写分离，那么就会分为“读高可用”和“写高可用“。
另外还有通过MySQL官方的MHA实现高可用，这个后面专门写个文档讲MHA如何实现高可用以及一些坑。

对于“写库高可用”，也是通过HAProxy + keepalived+vip，另外在加上“双主同步”，类似一台热备数据库。当其中一台出现故障，由keepalied自动将虚拟ip路由到另一台备份的主库上。

对于“从库高可用”， 同样通过HAProxy + keepalived + vip实现。

2.4 Redis的高可用

Redis Cluster，采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

Redis + Sentinel(哨兵) 实现主从切换。

具体技术细节可以查看相关资料，就不展开了，后面有时间再写更加深入一点的文章。

3. 小结

• 冗余 + 自动故障转移 实现系统高可用
• 其他一些高可用的架构设计原则
• 接入层的高可用，通过keepalived + vip 实现
• 服务的高可用，通过Nginx、网关、注册中心自带的健康检查
• 数据库的高可用，MHA、HAProxy + keeplived + vip + 双主同步