高可用架构

高可用架构

互联网分层架构

负载均衡

Nginx

定义

Nginx 是一个强大的 Web 服务器软件，用于处理高并发的 HTTP 请求和作为反向代理服务器做负载均衡。具有高性能、轻量级、内存消耗少，强大的负载均衡能力等优势。

优点

配置异常简单：非常容易上手。配置风格跟程序开发一样，神一般的配置

非阻塞、高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数

Nginx还能做Web服务器即Cache功能。

内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个 Nginx 进程才消耗150M 内存（15M*10=150M）

内置的健康检查功能：如果 Nginx 代理的后端的某台 Web 服务器宕机了，不会影响前端访问

节省带宽：支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头

稳定性高：用于反向代理，宕机的概率微乎其微

缺点

Nginx 仅能支 持http、https 和 Email 协议，这样就在适用范围上面小些

对后端服务器的健康检查，只支持通过端口来检测，不支持通过 ur l来检测。不支持 Session 的直接保持，但能通过 ip_hash 来解决

LVS

即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以实现LINUX平台下的简单负载均衡

抗负载能力强，性能高，能达到F5的60%，对内存和cpu资源消耗比较低，在负载均衡软件里的性能最强的

工作在网络4层，通过VRRP协议（仅做代理使用），具体的流量是由liunx内核来处理，因此没有流量的产生。

稳定，可靠性强，自身有完美的热备方案（Keepalived+LVS）

配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。

基本上能支持所有应用，因为 lvs 工作在 4 层，所以它可以对几乎所有应用做负载均衡，包括 http、数据库、聊天室等等。

更多负载均衡策略比如：动态加权轮循，加权源地址哈希，加权URL哈希加权等参数哈希已经实现

不支持正则处理，不能做动静分离

如果是网站应用比较庞大的话，LVS/DR + Keepalived 实施起来就比较复杂了

HAProxy

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上.

能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机

支持通过URL健康检测

本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

支持心跳检测

keepalived

它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。

反向代理层

nginx/HAproxy+keepalived

系统入口，反向代理

描述

是通过反向代理层的冗余来实现的。以nginx为例：有两台nginx，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。

故障转移

当nginx挂了的时候，keepalived能够探测到，会自动的进行故障转移，将流量自动迁移到shadow-nginx，由于使用的是相同的virtual IP，这个切换过程对调用方是透明的。

(lvs+keepalived)或（f5+keepalived）+nginx/HAproxy集群

LVS（Linux virtual server）实施在操作系统层面，f5（特别贵）实施在硬件层面，它们的性能都比nginx高很多。 这种实现方式能解决全球99.9999%的公司的访问量。LVS比Nginx/HAproxy要更稳定，转发效率也高

站点应用层

实现核心应用逻辑，返回html或者json

是通过站点层的冗余来实现的。假设反向代理层是nginx，nginx.conf里能够配置多个web后端，并且nginx能够探测到多个后端的存活性。

当web-server挂了的时候，nginx能够探测到，会自动的进行故障转移，将流量自动迁移到其他的web-server，整个过程由nginx自动完成，对调用方是透明的。

服务层

dubbo

如果实现了服务化，就有这一层

通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。

当service挂了的时候，service-connection-pool能够探测到，会自动的进行故障转移，将流量自动迁移到其他的service，整个过程由连接池自动完成，对调用方是透明的（所以说RPC-client中的服务连接池是很重要的基础组件）。

Spring Cloud

微服务多个实例注册到注册中心

缓存层

缓存加速访问存储

方式

双读写

利用客户端的封装，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，这个切换过程对调用方是透明的。