究竟啥才是互联网架构 “高可用”
一、什么是高可用
高可用 HA （ High Availability ）是分布式系统架构设计中必须考虑的因素之一，它通常是指， 通过设计减少系统不能提供服务的时间 。
假设系统一直能够提供服务，我们说系统的可用性是 100% 。
如果系统每运行 100 个时间单位，会有 1 个时间单位无法提供服务，我们说系统的可用性是 99% 。
很多公司的高可用目标是 4 个 9 ，也就是 99.99% ，这就意味着，系统的年停机时间为 8.76 个小时。
百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度 HA 最高的褒奖。
二、如何保障系统的高可用
我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。 方法论上，高可用保证的原则是“集群化”，或者叫“冗余” ：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他 backup 能够顶上。
保证系统高可用，架构设计的核心准则是：冗余。
有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是 通过“自动故障转移”来实现系统的高可用 。
接下来我们看下典型互联网架构中，如何通过 冗余 + 自动故障转移 来保证系统的高可用特性。
三、常见的互联网分层架构
常见互联网分布式架构如上，分为：
（ 1 ） 客户端层 ：典型调用方是浏览器 browser 或者手机应用 APP
（ 2 ） 反向代理层 ：系统入口，反向代理
（ 3 ） 站点应用层 ：实现核心应用逻辑，返回 html 或者 json
（ 4 ） 服务层 ：如果实现了服务化，就有这一层
（ 5 ） 数据 - 缓存层 ：缓存加速访问存储
（ 6 ） 数据 - 数据库层 ：数据库固化数据存储
整个系统的高可用，又是通过每一层的 冗余 + 自动故障转移 来综合实现的。
四、分层高可用架构实践
【客户端层 -> 反向代理层】的高可用
【客户端层】到【反向代理层】的 高可用 ，是通过反向代理层的冗余来实现的。以 nginx 为例：有两台 nginx ，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是 keepalived 存活探测，相同 virtual IP 提供服务。
自动故障转移 ：当 nginx 挂了的时候， keepalived 能够探测到，会自动的进行故障转移，将流量自动迁移到 shadow-nginx ，由于使用的是相同的 virtual IP ，这个切换过程对调用方是透明的。
【反向代理层 -> 站点层】的高可用
【反向代理层】到【站点层】的 高可用 ，是通过站点层的冗余来实现的。假设反向代理层是 nginx ， nginx.conf 里能够配置多个 web 后端，并且 nginx 能够探测到多个后端的存活性。
自动故障转移 ：当 web-server 挂了的时候， nginx 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的 web-server ，整个过程由 nginx 自动完成，对调用方是透明的。
【站点层 -> 服务层】的高可用
【站点层】到【服务层】的 高可用 ，是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。
自动故障转移 ：当 service 挂了的时候， service-connection-pool 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的 service ，整个过程由连接池自动完成，对调用方是透明的（所以说 RPC-client 中的服务连接池是很重要的基础组件）。
【服务层 > 缓存层】的高可用
【服务层】到【缓存层】的高可用，是通过缓存数据的冗余来实现的。
缓存层的数据冗余又有几种方式：第一种是利用客户端的封装， service 对 cache 进行双读或者双写。
缓存层也可以通过支持主从同步的缓存集群来解决缓存层的 高可用 问题。
以 redis 为例， redis 天然支持主从同步， redis 官方也有 sentinel 哨兵机制，来做 redis 的存活性检测。
自动故障转移 ：当 redis 主挂了的时候， sentinel 能够探测到，会通知调用方访问新的 redis ，整个过程由 sentinel 和 redis 集群配合完成，对调用方是透明的。
说完缓存的高可用，这里要多说一句，业务对缓存并不一定有“高可用”要求， 更多的对缓存的使用场景，是用来“加速数据访问” ：把一部分数据放到缓存里，如果缓存挂了或者缓存没有命中，是可以去后端的数据库中再取数据的。
这类允许“ cache miss ”的业务场景，缓存架构的建议是：
将 kv 缓存封装成服务集群 ，上游设置一个代理（代理可以用集群冗余的方式保证高可用），代理的后端根据缓存访问的 key 水平切分成若干个实例，每个实例的访问并不做高可用。
缓存实例挂了屏蔽 ：当有水平切分的实例挂掉时，代理层直接返回 cache miss ，此时缓存挂掉对调用方也是透明的。 key 水平切分实例减少， 不建议做 re-hash ，这样容易引发缓存数据的不一致 。
【服务层 > 数据库层】的高可用
大部分互联网技术，数据库层都用了“主从同步，读写分离”架构，所以数据库层的高可用，又分为 “读库高可用”与“写库高可用” 两类。
【服务层 > 数据库层“读”】的高可用
【服务层】到【数据库读】的 高可用 ，是通过读库的冗余来实现的。
既然冗余了读库，一般来说就至少有 2 个从库，“数据库连接池”会建立与读库多个连接，每次请求会路由到这些读库。
自动故障转移 ：当读库挂了的时候， db-connection-pool 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的读库，整个过程由连接池自动完成，对调用方是透明的（所以说 DAO 中的数据库连接池是很重要的基础组件）。
【服务层 > 数据库层“写”】的高可用
【服务层】到【数据库写】的 高可用 ，是通过写库的冗余来实现的。
以 mysql 为例，可以设置两个 mysql 双主同步，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是 keepalived 存活探测，相同 virtual IP 提供服务。
自动故障转移 ：当写库挂了的时候， keepalived 能够探测到，会自动的进行故障转移，将流量自动迁移到 shadow-db-master ，由于使用的是相同的 virtual IP ，这个切换过程对调用方是透明的。
五、总结
高可用 HA （ High Availability ）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
方法论上，高可用是通过 冗余 + 自动故障转移 来实现的。
整个互联网分层系统架构的高可用，又是通过每一层的 冗余 + 自动故障转移 来综合实现的，具体的：
（ 1 ）【客户端层】到【反向代理层】的高可用，是通过 反向代理层的冗余 实现的，常见实践是 keepalived + virtual IP 自动故障转移
（ 2 ）【反向代理层】到【站点层】的高可用，是通过 站点层的冗余实 现的，常见实践是 nginx 与 web-server 之间的存活性探测与自动故障转移
（ 3 ）【站点层】到【服务层】的高可用，是通过 服务层的冗余 实现的，常见实践是通过 service-connection-pool 来保证自动故障转移
（ 4 ）【服务层】到【缓存层】的高可用，是通过 缓存数据的冗余 实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与 sentinel 保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性
（ 5 ）【服务层】到【数据库“读”】的高可用，是通过 读库的冗余 实现的，常见实践是通过 db-connection-pool 来保证自动故障转移
（ 6 ）【服务层】到【数据库“写”】的高可用，是通过 写库的冗余 实现的，常见实践是 keepalived + virtual IP 自动故障转移
末了，希望文章的思路是清晰的，希望大家对高可用的概念和实践有个系统的认识，感谢大家。
==【完】==
扫码关注 @谢工 的新项目GitChat，一个 互联网原创干货文章 的 “码字”平台 ，本文首发于该项目。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
