实现服务高可用奇淫技巧（一）

1. 前言 

在上一篇通知文章有说过，六月份会开始更新公众号（固然一些好的文章我也会同步到博客中来，因此你们看到有些文章的内容和公众号中的是同样的），虽然如今已到月底了，但好歹也算没有失言，遇上了末班车了。

公众号中有不少读者留言，你们很期待能继续更新《RF接口自动化系列》文章，放心，牛奶会有的，面包也会有的，本身答应你们的，含泪也有完成的。

不过本篇仍不会更新《RF接口自动化系列》的文章，放心，后续会更新，敬请期待~

 本篇会给你们介绍一下服务高可用的实现，大体也会分几篇文章进行讲解。

 

为何忽然会讲服务高可用，请看【背景】章节！

 

2. 背景

目前咱们组内的主服务器docker主机（ubuntu系统），承载运行了咱们组内（效率提高组）大部分对外提供的关键平台服务

 

先来看一张图吧

 

简单粗暴地画了一张精简图，从上图中直观地反映咱们docker主机的一个简要架构图（若是你以为真实部署架构也是如此简单， 那只能说明你仍是太年轻了），用户访问咱们的应用服务，如访问qa.xx.com应用服务(A)，通过nginx代理，由nginx反向代理到实际应用服务A中。

 

这是常规应用部署最简单的单点结构，但做为这类关键服务节点，若是某天docker主机嗝屁了，那就意味着，全部运行在docker应用服务，就没法对外提供服务，可能有的人会说，这种状况，通常来讲不会发生吧，好吧，前不久就发生的一宗由于机房中服务异常断电，重启后磁盘启动异常的案例。

 

因此就引出了本文，经过高可用的方案来解决应用单点部署当发生异常长时间没法对外提供服务的问题！

 

3. 高可用与负载均衡的区别

 

• 高可用集群中的节点通常是一主一备，或者一主多备，经过备份提升整个系统可用性。

• 而负载均衡集群通常是多主，每一个节点都分担请求流量

 

4. 实现高可用的经常使用工具

• ngnix

• lvs （Linux虚拟服务器，是一个虚拟的服务器集群系统）

• HAProxy（HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速而且可靠的一种解决方案。）

• keepalived（这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，能够实现web服务器的高可用(HA high availably)。它能够检测web服务器的工做状态，若是该服务器出现故障被检测到，将其剔除服务器群中，直至正常工做后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director failover）。Keepalived守护进程能够检查LVS池的状态。若是LVS服务器池当中的某一个服务器宕机了。keepalived会经过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。）

 

5. 高可用不能解决什么

 

高可用也就是你们常说的HA（High Availability），高可用的引入，是经过设计减小系统不能提供服务的时间，而不能保证系统可用性是能达到100%的！

 

6. 高可用实施中有哪些问题须要解决

  

高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；若是有冗余备份，挂了还有其余backup可以顶上。

保证系统高可用，架构设计的核心准则是：集群。

有了集群以后，还不够，每次出现故障须要人工介入恢复势必会增长系统的不可服务实践。因此，又每每是经过“自动故障转移”来实现系统的高可用。

 

因此，实现高可用的两个关键点：

• 集群化

• 自动故障转移

 

 

对于服务而言，一旦某个服务器宕机，就将服务切换到其余可用的服务器上；

对于数据而言，若是某个磁盘损坏，就从备份的磁盘（事先就作好了数据的同步复制）读取数据。

 

 

结合咱们上图来看，要实现高可用的须要解决几个问题：

一、服务集群化，须要增长服务物理机 （利用现有的服务机或者新增购买一台新的服务机，建议后者）

2、nginx请求代理集群（请求入口需引入集群，不然应用服务有集群，nginx挂了，照样game over，因此须要解决如何让nginx能够集群，并能自动故障转移）

三、应用服务集群（服务不能单点部署，需集群部署，一个服务提供者挂了，其它能够顶上，因此须要解决如何让应用服务能够集群，而且服务异常可自动故障转移）

四、实现集群后，需保证集群间持久数据层是能保持同步一致的（mysql db、mongo db）

五、应用服务器集群的Session管理。

 

7. 高可用架构实践方案

 

整个系统的高可用，其实就是经过每一层的集群（冗余）+自动故障转移来综合实现的。

 

正如上述在须要解决的问题中，提到的：

 

一、要解决【客户端层→反向代理层】的高可用：

【客户端层】到【反向代理层】的高可用，是经过反向代理层的集群（冗余）来实现的。以nginx为例：须要准备至少两台nginx，一台对线上提供服务，另外一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。

 

【正常图】：

 

 

【其中一台nginx嗝屁了】：

 

 

自动故障转移：当nginx挂了的时候，keepalived可以探测到，会自动的进行故障转移，将流量自动迁移到另一台nginx，因为使用的是相同的virtual IP，这个切换过程对调用方是透明的。

 

 

二、要解决【反向代理层→应用服务站点层】的高可用

【反向代理层】到【站点层】的高可用，是经过站点层的集群（冗余）来实现的。假设反向代理层是nginx，nginx.conf里可以配置多个web后端，而且nginx可以探测到多个后端的存活性。

 

【正常图】：

 

【其中一台站点服务嗝屁了】：

 

 

自动故障转移：当web-server服务站点挂了的时候，nginx可以探测到，会自动的进行故障转移，将请求自动迁移到其余的web-server，整个过程由nginx自动完成，对调用方是透明的。

 

三、虽然咱们的服务应用，没有怎么用到了缓存，但仍是想补充一个小章节说一下，【服务层】到【缓存层】的高可用

缓存层的数据集群有几种方式：第一种是利用客户端的封装，service对cache进行双读或者双写，也能够经过主从同步的缓存来解决缓存层的高可用问题。

 

以redis为例，redis自然支持主从同步，redis官方也有sentinel哨兵机制，来作redis的存活性检测。

 

 

【正常图】

 

 

 

【reids-Master嗝屁了】

 

 

自动故障转移：当redis主挂了的时候，sentinel可以探测到，会通知调用方访问新的redis，整个过程由sentinel和redis集群配合完成，对调用方是透明的。

 

 

注：实际小型业务对缓存并不必定有“高可用”要求，更多的对缓存的使用场景，是用来“加速数据访问”：把一部分数据放到缓存里，若是缓存挂了或者缓存没有命中，是能够去后端的数据库中再取数据的。（固然一些大型的流量平台除外）

 

 

四、【服务层>数据库层】的高可用

数据库层通常集群化都会采用了“主从同步，读写分离”架构，

 

以mysql为例，能够设置两个mysql双主同步，一台对线上提供服务，另外一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。

 

【正常图】

 

 

【其中一台数据库嗝屁了】

 

 

 

自动故障转移：当其中一个数据库挂了的时候，keepalived可以探测到，会自动的进行故障转移，将流量自动迁移到shadow-mysql，因为使用的是相同的virtual IP，这个切换过程对调用方是透明的。

 

五、再来看看应用服务器集群的Session管理，在集群环境下，Session管理的几种常见手段：

• Session复制：集群中的几台服务器之间同步Session对象，任何一台服务器宕机都不会致使Session对象的丢失，服务器也只须要从本机获取便可

• Session绑定：利用负载均衡的源地址Hash算法，老是将源于同一IP地址的请求分发到同一台服务器上。即Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。（这种方案又叫作会话粘滞）

• Cookie记录Session：利用浏览器支持的Cookie记录Session。（因此须要保证服务集群间的域名一致来保证session id一致）

 

注：显然session复制和绑定不符合高可用的需求。由于一旦某台服务器宕机，那么该机器上得Session也就不复存在了，用户请求切换到其余机器后由于没有Session而没法完成业务处理。

 

 

 》》未完待续《《 

 

 

另外，打一个小广告，4月份与testerhome合做办了一个测试开发线下培训，我负责的课题持续集成建设与Docker容器化应用相关，目前课件对外特价优惠，感兴趣的同窗能够私聊找我哦~