企业高可用服务架构研究与应用

2022-09-09巩俊辉

电子技术与软件工程 2022年13期

巩俊辉

（中国电建集团西北勘测设计研究院有限公司信息中心陕西省西安市 710065）

系统的高可用性是可用性与成本间的一种平衡，系统的高可用性涉及到系统的各个方面，需要统筹平衡。高可用性是指一个系统在正常运行条件下，系统不中断运行的能力，通常是将正常运行时间与统计总时间的比值作为具体的量化指标。系统要保证完全可用是不可能完成的任务，系统高可用性就是对可用性达到指标的度量，一般指达到99.99%以上，具备自动恢复能力的高可用，而更高层次的极高可用性是理想状态。

企业级应用系统实现高可用的方法一般通过采用符合安规的软硬件设备，组建高容错应用集群，采用负载均衡、数据备份、主备架构、多活服务等技术来实现。本文基于企业级的应用服务，从实用性与可行性方面论证企业高可用性架构建设。

1 基础分析

企业信息化服务具有多样化，差异化特点，包括Web服务、移动应用、服务组件、微服务、桌面应用等各种类型的应用服务，各自都面临着服务治理、管理等问题，服务之间通常存在大量的信息交互，系统间相互影响，企业构建高可用的应用服务以保证即便在服务器软硬件故障时，信息依然能够正确保存并可被访问，是企业信息化建设的一项重要内容。

现代企业信息系统的基础设施平台，基本都采用私有云或者公有云平台，云平台服务基于虚拟化技术，广泛使用网络、存储、服务器等硬件冗余技术，所构建的基础平台具有较高的硬件可靠性，冗余技术通常分时间冗余、信息冗余、结构冗余、冗余附加技术，本文主要从软件方面研究系统的高可用性架构设计。

结合本企业的应用实践，企业内部署了包括自动化办公、设计、人事、合同、党建、科技、辅助决策等一系列的信息系统，服务于企业的生产、经营以及员工工作、生活的方方面面。这些系统中，生产、办公、经营等高价值信息系统对可用性的要求相对比较高，所以针对这些高价值系统，有必要设计构建高可用的服务架构。

2 高可用技术及方案研究

信息系统服务的高可用性从形式内容方面进行分析，主要有以下几类：

2.1 高可用架构

高可用的架构，目标是保证服务器在出现硬件故障时，仍可使用，数据可以保存并且能够被访问，主要解决方案是包括数据和服务的冗余备份，以及失效转移机制实现高可用架构。具体对于应用服务系统而言，就是在服务器故障时，通过冗余设计，可以将服务切换到其他可用的服务器上；对于数据来说，就是存储损坏时，可从冗余备份存储读取、恢复数据。

2.2 高可用应用

高可用的应用，对于无状态应用服务与有状态的应用服务，具体实现为：对于无状态服务的失效转移，比如数据接口、API 服务等，本身不依赖于服务会话，可以直接通过服务负载均衡实现高可用性，当负载均衡服务检测到无效服务后，会自动进行失效转移；而对于使用Session 等有状态服务，比如Web 应用，其通常在应用中使用上下文对象会话（Session）识别用户，此类服务在负载均衡的集群环境中，重要的是保证Session 正确性，相关的处理机制相对比较复杂，具体实现是通过服务集群的Session 管理实现，可采用Session 复制、Session 绑定，以及Session 服务器技术保证会话分发可用。具体原理如下：

（1）Session 复制，实现相对简单易行，是通过在集群应用之间同步Session 对象，当其中有任何一个应用服务宕机时，并不会导致其他服务的Session 对象丢失，各个应用服务均有Session 独立复本，可以正常的从本地获取信息，此方案缺点是Session 复制操作会占用大量服务资源，适合于应用规模较小的情况。

（2）Session 绑定是利用负载均衡服务对源地址进行Hash 计算，将同一源地址的请求在整个访问期间分发到同一个服务上，即点对点绑定，但此技术方案不完全符合高可用的需求，即当某个服务失效时，其会话Session 将丢失，与其绑定的客户端的后续业务也无法继续进行。

（3）Session 服务器技术是利用独立的服务管理Session，各应用服务在读写Session 时，都是通过统一的Session 服务进行操作，也就是将Session 与应用服务分离开，通过Session 独立管理实现会话访问，此方案符合高可用的构建需求，但需要构建Session 服务。

另外，还可以利用浏览器特性，即客户端在访问服务时，通过Cookie 记录Session，并在会话中传输Cookie 数据以保证会话的有效，此方案需要在请求中传输Cookie，这即影响访问性能，也存在安全隐患，不建议采用。

2.3 服务高可用性

在应用系统中，通常需要后端服务来完成数据交换。做为公共的信息服务，此类服务大多独立分布式部署，供具体的应用进行远程调用。为保障服务的高可用，通常采用策略管理保证可用性：

（1）对服务进行分级管理，保证核心的服务具有更高的优先级。

（2）设置服务调用的超时时间，在服务调用超时后，通过服务调度策略重试或请求转换，实现服务正常可用。

（3）通过对消息队列进行异步方式处理，减少服务并发压力和避免个别服务失效而影响整体服务请求的情况。

（4）对服务进行策略调整，普通服务降级访问，减少并发数或停止服务，从而保证重要服务的业务正常。另外，对于特别重要的服务，也可进行N 版本设计，保证服务结果的正确性。

2.4 高可用的数据

高可用数据是指提高数据的可用性，可以从数据备份、运行机制等方面，保证数据的可用性，对于应用系统服务，通常采用的是数据库集群、数据库读写分离、分布式数据等方法，实现数据的高可用性。

3 高可用应用的构建实现

在企业内高可用架构设计需要考虑软硬件条件，平衡实现。企业在包含网络在内基础硬件设施建设，通常会采用硬件设备冗余、网络线路冗余等架构设计，基础设施平台相对稳定，所以本次研究不过多对基础设施环境的高可用架构技术进行叙述，主要对更具灵活操作性的软件架构技术展开研究。

3.1 高可用实现原理

在高可用（HA）系统中，如双机热备系统就是使用两台服务器，之间互相备份，共同执行同一项服务。当其中一台服务器出现故障时，服务任务由另一台服务器自动承担接管，不需要人工干预，保证服务的持续性。一般情况下，两台服务器分为一主一备，正常情况下，主服务器为应用系统提供服务，主备两台服务器节点之间通过状态通信，即心跳检测相互获取服务状态，当主服务器出现异常，不能再正常服务时，备份服务器会自动迅速接管服务，实现应用服务的持续不间断运行。双机热备系统也是常用的关键服务高可用架构方案。

3.2 双机热备系统问题分析及解决方案

在双机热备架构中，两个服务之间的状态检测通信是非常关键的，当联系2 个节点的“心跳线”异常时，原本作为整体协调的高可用系统，就会分裂成为2 个独立的个体，由于相互失去了联系，两个节点系统都会判断对方出现服务故障，从而接管服务，造成两个节点上的HA 软件像“裂脑人”一样，争抢提供应用服务，造成共享资源冲突，从而发生严重后果，致使服务竞争或服务无效。

对付HA 系统“裂脑”的对策，目前常采用的措施一般有以下几个：

（1）添加冗余的心跳线，例如采用双心条线，尽量减少发生概率。

（2）对于共享资源启用资源锁，比如共享磁盘锁，正在服务的一方对共享磁盘加锁，当“裂脑”发生时，不会造成磁盘使用冲突，但也会存在资源解锁问题，即一方如果不主动解锁，另一方将永远无法使用共享资源，备份节点也就无法接管共享资源和应用服务。所以在HA 中需设计“智能”锁，即只在发现心跳线全部断开时才启用资源锁。

（3）设置参考仲裁，比如设置参考IP，当前节点检测到心跳断开时，同时再检测与该参考节点的通信，如果当前节点与参考节点间通信正常，才判断为冗余节点服务异常，如与参考节点通信异常，则认为自身节点故障，主动释放自身所占用的共享资源，关闭或重启自身节点服务。

当前在企业的实际应用中，通常服务是构建在云环境中，即冗余节点一般都是部署在相同虚拟主机中，发生脑裂的可能性是非常低的，但也应该通过建构检测服务，让服务器根据检测自动处理相应故障，进一步保障系统的可靠与可用。

3.3 系统选择

常用的高可用性软件系统，HeartBeat RoseHA 是一个专业的、功能完善的高可用软件，但部署和使用较为麻烦。更为常用的轻量级高可用解决方案是通过keepalived 实现主机的冗余和接管，keepalived 虽然没有HeartBeat 功能点多，但其部署和使用简单，通常只需要一个配置文件即可实现系统的高可用性。keepalived 早期面向LVS 的，后来增加了VRRP 功能，在实际应用中，也只需使用其VRRP 功能即可。通过VRRP 功能，进行服务器状态检测和故障隔离，保证业务的连续性，实现服务不间断的稳定运行，接管速度最快可以小于1 秒。相结合使用负载均衡系统，提高服务的可用性，目前常见的负载均衡主要分为硬件负载均衡和软件负载均衡。硬件负载均衡比较知名的产品有F5、CirtixNetscaler等，而软件负载均衡常见的有Haproxy、Nginx、LVS 等。

对于软件负载均衡系统，LVS 是基于OSI 第四层、传输层的转发，可以提供终端到终端的可靠连接；HAproxy 是基于四层和七层的转发，功能更加丰富灵活，负载均衡两端连接都是独立的，一定程度上提升了后端系统的安全性，Nginx 也可以做七层转发，主要用于WEB 服务器、缓存服务器，同时又是反向代理服务器。相比较这几个软件系统，对于基于URL 或目录的转发，LVS 四层转发是无法满足需求的，同时，其配置复杂，对网络依赖比较大。实际应用中，LVS 更适合有很大并发量的时候，而普通情况下，选择HAproxy 或者Nginx 即可满足业务需求。

对于HAproxy 和Nginx，在性能上，HAProxy 的负载均衡速度比Nginx 更出色，支持四层和七层两种代理模式，而Nginx 对网络的依赖小，理论上能ping 通就能进行负载功能；同时Nginx 安装和配置非常简单，测试也很方便，比较适合Web 服务应用。

在本企业的实际应用中，使用的是keepalived+Nginx 方案构建实现了企业应用服务系统的双机热备高可用系统架构。即在两台云服务器之上部署keepalived，通过keepalived虚拟IP 提供服务，VRRP 可以保证两台服务器的检测及服务接管，该架构整体性能优越，能够满足企业生产环境的高可用性要求。

4 高可用系统验证

4.1 实施环境

服务器：云虚拟机*2，CPU:8C、内存：8GB、存储：200GB

操作系统：CentOS7.9

软件：KeepAclived2.2.7+Nginx1.22.0

网络：10.0.10.2、10.0.10.3、10.0.10.4

4.2 实现过程

如图1 所示，使用keepalived+nginx 方案实现双机热备高可用的架构，其中，Nginx 服务器通过反向代理与负载均衡，实现应用服务的高可用性，keepalived 通过VRRP 实现自动故障转移，该双机热备架构可解决可用性问题。

图1 ：双机热备架构

具体部署时，keepalived 与Nginx 安装过程较为简单，这里只重点讲解关键的服务配置。

对于keepalived，主要是配置两个主机服务节点的VRRP 实例，实例配置如下：

到此，keepalived 主要配置即完成，启用服务后，即可实现VRRP 搭建，实现主机间的服务检测，表现为虚拟IP的转移，nginx 负载服务也是基于该虚拟IP 对外提供服务。

4.3 结果验证

配置好keepalived 并启动服务后，查看网络接口状态，可以看到虚拟IP 已经在主服务器生效，当停止主服务器后，可以观察到虚拟IP 自动转换到备服务器，接管服务；当主服务器恢复时，虚拟IP 会自动重新转换到主服务器。状态检测并管理故障服务器的工作全部是自动完成，不需要人工干涉，人工只需要修复有故障的服务即可。

查看节点的虚拟IP 信息和状态迁移过程，如图2 和图3所示。

图2 ：主节点虚拟IP

图3 ：备份节点VRRP 检测

4.4 Nginx深度应用

Nginx 在keepalived+Nginx 架构中，Nginx 主要承担应用服务的角色，可具体通过正向代理、反向代理，以及负载均衡配置实现高可用性。在本企业的实际应用中，Nginx 作为发布应用总线提供服务，负责了企业内所有HTTP 服务的应用代理转发与负载均衡，通过Nginx 构建的统一发布管理服务，实现了企业内Web 应用服务的集中管控，同时结合企业内部的域名解析服务，实现了Nginx 单个端口的多业务系统代理，即通过server-_name 区分实际的业务服务系统，单个server 配置示例如下：

Nginx 配置相对比较灵活，灵活应用可以实现特殊的功能需求。对于HTTP 代理，有效利用配置中HTTP、Server、Location、IF 不同层级间配置项叠加，可以简化整体配置，高效实现集中发布管理中的通用配置以及个性化配置。比如，在HTTP 段中配置：

实现全局配置项管理，而在Server 段实现个性化配置。

此外，利用Nginx 七层转发特性，合理利用能够实现诸多场景应用需求。比如通过在服务的Serve 段中配置Header信息，解决老旧系统对于特定浏览器版本依赖需求：

add_header "X-UA-Compatible" "IE=EmulateIE7";

又比如通过配置特殊URI 内容过滤实现对应用服务的安全加固：

还可以利用sub_filter 等功能实现应用代码修改等功能。

总之，通过Nginx 的深度应用，可以实现复杂场景的Web 发布管理。通过实践总结，在实现应用过程中，值得注意的是在Nginx 的不同层级的配置中，相同配置项会完全覆盖上面层级的配置内容，而不是累加的配置过程。

4.5 总结

在keepalived+nginx 架构中，keepalived 负责服务器的整体动态管理，服务器会自动管理故障机器，服务器切换非常快。将服务部署在同一云环境中，尤其同一主机时，发生脑裂的概率是非常低的，基本为0。实际可能遇到的问题是keepalived 在配置中未使用LVS 状态检测，对于nginx 服务的状态是不敏感的，当nginx 自身的服务发生问题时，并不会触发keepalived 转换服务，所以实际应用中，可以编写一个nginx 状态监听脚本/服务，以控制keepalived 实现服务器的切换，提高架构可靠性。该架构在本企业上线以来，总体性能良好，服务稳定，尚未发生过脑裂、服务宕机、异常等故障。