什么是高可用架构

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

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的高可用也是基于中间件来做的。

总结

文章对常见的高可用方案做了简单的介绍，由于高可用涉及内容较多，短短一篇文章不能很详细的介绍，比如：前两种高可用方案只适用于无状态服务，如何将有状态服务变为无状态服务将会在后面的微服务相关的文章中介绍！