运维高可用架构的 6 大常规方案

在介绍高可用架构的方案之前，先说一下什么是高可用架构，高可用架构应具备但不限于以下特征：

1. 主从切换

   很好理解，当其中一台机器的服务宕机后，对于服务调用者来说，能够迅速的切换到其他可用服务，从服务升级为主服务，这种切换速度应当控制在秒级别（几秒钟）。

   当宕机的服务恢复之后，自动变为从服务，主从服务角色切换。主从切换一定是要付出代价的，所以当主服务恢复之后，也就不再替换现有的主服务。

2. 负载均衡

   当服务的请求量比较高的时候，一台服务不能满足需求，这时候需要多台机器提供同样的服务，将所有请求分发到不同机器上。

   高可用架构中应该具有丰富的负载均衡策略和易调节负载的方式。

   甚至可以自动化智能调节，例如由于机器性能的原因，响应时间可能不一样，这时候可以向性能差的机器少一点分发量，保证各个机器响应时间的均衡。

3. 易横向扩展

   当用户量越来越多，已有服务不能承载更多的用户的时候，便需要对服务进行扩展，扩展的方式最好是不触动原有服务，对于服务的调用者是透明的。

业务中接触到的6种高可用方案如下：

LVS+Keepalive

LVS的全称是linux visural server，即虚拟的linux机器，这个名称再恰当不过了。该方案的实现大概是这样的。

在多台linux机器上安装IPVS和keepalive，IPVS实际上是一个虚拟的linux服务，具有linux机器的部分功能，各个机器上分别启动一个Linux虚拟服务（虚拟机），这些linux虚拟服务（虚拟机）设置为同一个IP（称之为虚IP），这样在一个内网中就只能有一个linux虚拟服务能够抢占到这个虚拟IP。所有的请求都指向这一个虚IP，假如抢占到虚IP的机器挂了，这时候其他linux虚拟服务就会有其中一个抢占到虚IP，对于服务调用者来说，仍然可以访问到服务。keepalive的作用就是用来检测linux虚拟服务是否正常的。头条插入代码实在不方便，需要详细的配置方案的可以私信我。

NIGNX

Nginx本是一个反向代理服务器，但由于丰富的负载均衡策略，常常被用于客户端可真实的服务器之间，作为负载均衡的实现。

说一下什么是反向代理和正向代理：

正向代理：被代理的是客户端，比如通过XX代理访问国外的某些网站，实际上客户端没有权限访问国外的网站，客户端请求XX代理服务器，XX代理服务器访问国外网站，将国外网站返回的内容传给真正的用户。用户对于服务器是隐藏的，服务器并不知道真实的用户。

反向代理：被代理的是服务器，也就是客户端访问了一个所谓的服务器，服务器会将请求转发给后台真实的服务器，真实的服务器做出响应，通过代理服务器将结果返给客户端。服务器对于用户来说是隐藏的，用户不知道真实的服务器是哪个。

关于正向代理和反向代理，听起来比较绕，仔细理解，体会也不难明白到底是什么意思。

用nginx做实现服务的高可用，nginx本身可能成为单点，遇见的两种解决方案，一种是公司搭建自己的DNS，将请求解析到不同的NGINX，另一只是配合keepalive实现服务的存活检测。

Zookpeer

想必接触过分布式服务的应该对zookeeper都有所了解，最起码也听说过吧！zookeeper本身实现了高可用，zookeeper本身的高可用及原理在这儿不详细介绍，这里只介绍如果通过zookeeper管理服务。

zookeeper本身可以存储数据，服务启动之后可以向zookeeper注册，调用者可以到zookeeper上发现服务。提供服务的一直保持与zookeeper的通信，通过心跳证明服务的可用性。当服务挂掉之后，对应注册的接点会消失，这时候调用者就不能找到已经失效的服务。

关于zookeeper实现服务高可用，以后会详细介绍。

由客户端实现的高可用方案

以memcache 为例，客户端同时与好几个服务保持连接，按照一定的规则去调用服务，当服务挂掉之后，重新调整规则。当然，如果服务器不做主从备份的话，可能会造成部分数据丢失。感兴趣的可以关注以后发的关于对memache的详细介绍的文章。

服务之间通信实现高可用

这种经典的案例就是redis了，各个redis之间保持通信，当主服务挂掉之后从服务就会升为主服务。对于客户端来说几乎是透明的。

通过中间件实现高可用

这里暂时不详细介绍，说一下我了解的几个中间件：mycat 实现mysql高可用的中间件。

早期版本redis不支持集群，那时候redis的高可用也是基于中间件来做的。