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

底漆

如果我们调查一个客户的经营者，让他谈谈对财资系统可用性的期望？ 客户大概率的回答可能是：“我希望这个系统随时可用，没有任何问题。” 直觉上，我们都希望系统始终在线，没有问题。 那么如何从工程的角度科学定义高可用性（HA）呢？ 业界一般用几个9来衡量系统的可用性，如下：

将具体数据量化之后，我们对所谓“高可用”的期望就更加清晰了。 通过对比这张表，我们可以分析出我们的业务在系统不可用的情况下一天能接受多长时间。 状态。

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

资金系统总体业务结构

高可用性的量化以及企业对资本系统可用性的期望对于构建合适的系统架构是非常必要的。 在现实中，常有两种不合理的现象：

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

● 部分企业的IT主管对高可用架构的难度和投资认识不足，软硬件投资无法支撑系统可用性预期。

2、如何设计高可用

1.架构分析

我们都耳熟能详的一句话是“你不能把所有的鸡蛋都放在同一个篮子里”，这也揭示了高可用设计的真谛之一，那就是【冗余】，但仅【冗余】是不行的足够的。 “主”的架构设计中有一个“主备”的概念。 当“主”出现问题时，需要“备”在上，但这个过程不能靠人工，因为没有人可以时刻监控机器是否正常。 这时候就需要设计【automatic failover】。 小结：【冗余、故障自动切换】是高可用架构设计中需要解决的两个核心点。

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

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

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

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

● 网关：主要负责流量控制、风险控制、协议转换等；

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

● 存储层：即DB，如MySQL、Oracle等；

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

前文提到，为了实现整体架构的高可用，需要在每一层实现组件的高可用。 接下来我们看看各层组件是如何实现高可用的。

2.接入层&反向代理层

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

3.微服务

对于微服务比特币系统架构，我们以开源的dubbo框架为例，看看服务层的高可用是如何实现的。

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

4.数据库

在数据库层面，Bytech的客户使用的数据库主要是Mysql和Oracle。 在生产中，我们常用的数据库层高可用方案一般有以下几种：

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

基于存储的双机热备方案是基于磁盘阵列的数据库高可用方案。 数据安全由磁盘阵列的容错机制保证。 方案在软件存储、数据库服务切换、VIP切换、磁盘资源切换等方面易于部署和维护 流程由第三方软件管理，用户层面只维护一个数据服务，数据不存在需要同步。

● Mysql主从方案

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

● Oracle RAC集群解决方案

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

三、客户案例

1.微服务架构

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

我们将当前主流的技术架构与客户架构的技术方案充分结合，从接入层、业务逻辑层、数据库、中间件层构建高可用、高性能的架构，为企业资本建设坚实的信息化商业。 基础。

2.双住同城

某银行开通银行云金库系统同城双活架构。

技术架构——同城双活架构

技术架构-部署方案

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

4、安全防护

我们上面给出的各种形式的高可用架构都是基于系统正常运行的，但是我们都知道现在整体的网络环境并不安全，比如：2022年8月28-29日比特币系统架构，一个很好的-知名软件厂商产品遭到大规模勒索软件攻击，大量用户电脑文件被后缀为.locked的勒索软件加密。 被勒索后，需要支付0.2个比特币。 因此，安全防护作为系统高可用的一个容易被忽视的点，不能掉以轻心。 为此，我们根据字节科技资金体系的特点，制定了以下安全保护策略供广大客户参考执行。

1、标准化：

● Windows系统必须有杀毒软件，并定期更新病毒库；

● 客户端不下载未知软件；

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

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

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

2.推荐部分：

● 数据库和应用程序建议安装在Linux操作系统上，银行前台计算机除外；

● 建议客户有专门的安全运维人员定期进行安全检查、更新病毒库等；

● 客户推荐的配置必须有防火墙。

3、底线操作：

● 数据库必须备份，必须有异机备份（离线备份或不同操作系统的数据备份）。 建议每天备份一次；

● 在各产品线的备份中关注T2产品可能存在的问题及改进措施。 数据安全：数据库、附件（标准化推荐）、收据（增量备份）；

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

本文简要介绍高可用架构在基金管理系统建设中的实现。 通过以上分析，希望能对需要上线资金管理系统的客户起到一定的指导作用。 如今，新技术层出不穷，几乎到了“乱花渐艳”的地步。 那么在高可用方面我们该如何选择呢？ 我总结了几个关键词“简单”、“适用”、“可进化”。 高可用架构的设计并不是越先进越好。 的。

最后，欢迎大家就系统安全性、易用性等相关问题与我们共同探讨和交流，让我们的资金系统更加高效、安全、稳定。