谈谈资金管理系统高可用架构设计

引子

如果我们调研一个客户的业务操作人员，让他谈谈对资金系统的可用性的期望？客户大概率的回答可能是：“我期望这个系统随时都可用，不要出任何问题”，直觉上我们都期望一个系统永远在线，不出问题。那么从工程的角度如何对高可用（High availability，即 HA）去科学的定义呢？业界一般用几个九来衡量系统的可用性，如下：

通过具体的数据量化后，我们对所谓的“高可用”的预期就更清晰化了，对照这个表格，我们就可以来分析，我们的业务能接受一天里系统能够有多久时间，处于不可用的状态。

一、资金管理系统场景分析

资金系统的常规业务架构

高可用的量化，和企业对资金系统的可用性的期待，对构建合适的系统架构非常有必要，现实中往往会有两种不合理的现象：

● 企业投入大量软、硬件资源，构建高可用的系统，但是无论用户数、还是业务量都不需要这种配置，浪费资源。

● 部分企业的IT负责人对高可用架构的难度和投入认识不足，软、硬件的投入完全无法支撑对系统的可用性期待。

二、如何设计高可用

1、架构分析

我们都熟悉一句俗话叫着“不能把鸡蛋放到同一个篮子里”，这个也道出了高可用设计的一个真谛那就是【冗余】，但是光有【冗余】还是不够，在高可用的架构设计里是存在“主备”的概念的，当“主”出现问题，“备”需要顶上，但是这个过程不能依赖人工，因为没有人能够时时刻刻去监控机器是否正常，这个时候就需要设计【自动故障转移】。简要总结：【冗余，自动故障转移】是高可用架构设计的需要解决的两个核心要点。

那么一个系统的哪些部分需要去冗余呢？又如何去做自动故障转移呢？这个就需要对系统的整体组成部分进行分析，拜特科技资金管理系统目前的整体结构大致如下图，我们就结合这个示意图，从整个请求链来分析如何进行实现：

可以看到架构主要分以下几层：

● 接入层：主要由 F5 硬件或 LVS 软件来承载所有的流量入口；

● 反向代理层：Nginx，主要负责根据 url 来分发流量，限流等；

● 网关：主要负责流控，风控，协议转换等；

● 业务服务：完成核心业务微服务；

● 存储层：也就是 DB，如 Mysql，Oracle 等；

● 中间件：ZK，ES，Redis，MQ 等。

如前所述，要实现整体架构的高可用，必须要实现每一层组件的高可用，接下来我们就来分别看一下每一层的组件都是如何实现高可用的。

2、接入层&反向代理层

接入层核心组件是：LVS、Nginx、keepalived ，通过虚拟IP技术，两个 LVS 以主备的形式对外提供服务，注意 只有 master 在工作（即此时的 VIP 在 master 上生效），另外一个 backup 在 master 宕机之后会接管 master 的工作，另外LVS通过keepalived维护可以转发的Nginx列表，从而也实现了Nginx的故障转移。

3、微服务

微服务，我们以开源 dubbo 框架为例，来看下服务层的高可用是如何实现的。

微服务架构下，核心的角色包括：服务提供者、服务消费者、注册中心，整体原理：首先 Provider（服务提供者）向 Registry（注册中心，如 ZK 或 Nacos 等）注册服务，然后 Consumer（服务消费者）向注册中心订阅和拉取 Provider 服务列表，获取服务列表后，Consumer 就可以根据其负载均衡策略选择其中一个 Provider 来向其发出请求，当其中某个 Provider 不可用（下线或者因为 GC 阻塞等）时，会被注册中心及时监听（通过心跳机制）到，也会及时推送给 Consumer，这样 Consumer 就能将其从可用的 Provider 列表中剔除，也就实现了故障的自动转移，这个场景下注册中心就起到了类似 keepalived 的作用。

4、数据库

数据库层面拜特科技的客户使用的数据库以Mysql，与Oracle为主，生产上我们常用的数据库层高可用方案一般有如下几种：

● 基于共享存储的双机热备方案

基于存储的双机热备方案是基于磁盘阵列的数据库高可用方案，数据的安全性由磁盘阵列的容错机制保障，在软件存储该方案部署维护简单，数据库服务切换、VIP切换以及磁盘资源的切换过程都由第三方软件管理，用户层面只维护一台数据服务，数据也不需要再做同步。

● Mysql主从方案

近些年来，随着开源软件的发展，Mysql数据库在企业级的应用也越来越广泛，Mysql主从复制方案也越来越多的被企业采用。Mysql主从方案中Master数据库的改变会通过binlog日志传到slave数据库，slave数据库通过执行Binlog与主数据库数据同步，当Master出现故障时，可以自动或者手动通过keepalived把VIP切换到Slave，原来的Slave会变成新的Master，并对外提供服务，待原Master修复后重新恢复同步。

● Oracle RAC集群方案

针对企业资金系统应用，Oracle RAC集群方案是大型集团客户采用较多的数据库高可用方案，数据保存在磁盘阵列上，通过磁盘阵列冗余和校验保障数据高可用，数据库多个实例节点可以同时访问磁盘阵列，客户端可以连接任意一个实例节点，存取数据，可以实现数据库负载均衡。Oracle Dataguard组件可以通过日志把阵列上数据库同步到远程Standby数据库，实现异地数据容灾。

三、客户案例

1、微服务架构

某电气集团，中国工业制造业的领军品牌，历史至少可以追溯到1902年，创造了中国与世界众多第一。荣获中国工业领域最高奖项—中国工业大奖，入选《全球制造500强》、《财富》中国500强 。入选《全球制造500强》、《财富》中国500强 ，2021年ENR全球最大250强国际承包商排名全球第51位 ，下图是该客户的司库解决方案中系统部署整体架构图。

我们为该客户架构的技术方案充分结合当前主流技术架构，从接入层、业务逻辑层、数据库、中间件各层构建高可用、高性能架构，为企业的资金业务开展构建了坚实的信息化地基。

2、同城双活

某银行，开放银行云财资系统同城双活架构。

技术架构—同城双活架构

技术架构—部署方案

在该案例中，我们通过微服务、分布式数据库、中间件集群，实现了同城双机房双活金融级别高可用架构。

四、安全防护

以上我们给出的各种形式的高可用架构，前提都是建立在系统正常运行的基础上的，但是我们都知道现在整体上网络环境并不安全，例如：2022年8月28日至29日，某知名软件厂商旗下产品大面积遭受勒索病毒攻击，大量用户计算机文件被.locked后缀的勒索病毒加密。被勒索后，需要支付0.2个比特币。因此安全性防护作为系统高可用的一个容易忽视的点，同样不能掉以轻心，为此我们针对拜特科技资金系统的特性制定了以下安全性防护策略供我们的客户来参考实施。

1、标准化：

● windows系统一定要有杀毒软件，并定时更新病毒库；

● 客户服务器不下载不明软件；

● 除公司服务端口外，屏蔽不需要端口；

● 公司统一提供标准中间件产品包（包括Tomcat、Mysql、FTP、SFTP、Redis、Nginx）；

● 有外网访问的客户必须使用服务器证书。

2、建议部分：

● 数据库、应用建议安装到Linux操作系统，除银行前置机；

● 建议客户有专门安全运维人员，定时做安全检查，更新病毒库等；

● 客户推荐配置一定要有防火墙 。

3、底线操作：

● 数据库一定要有备份，并且一定要有异机备份(离线备份或不同操作系统数据备份) 建议每天备份一次；

● 各产品线备份注意T2产品可能问题及改进措施数据安全：数据库，附件（标准化推荐）、回单（增量备份）；

● 银行接口可能问题及改进措施 数据安全：日志数据（备份一个月，增量）。

本文简要的介绍了高可用架构在资金管理系统建设的落地，通过以上的分析希望能够对需要上线资金管理系统的客户有一定的指导作用，当今新技术层出不穷几乎到了“乱花渐欲迷人眼”的地步，那么在高可用这块，我们要如何去选择呢？我总结了几个关键字 “简单”、“适用”、“可演进”，高可用架构的设计不是越高级越先进越好，重点结合自己企业的实际情况，选择对的，而不是单纯的贵的。

最后，欢迎大家针对系统的安全性，可用性等相关问题跟我们探讨交流，一起让我们的资金系统更高效、更安全、更稳定。