单元化架构的思考

银行业"多活"的发展历程

受监管政策的要求,银行一般会在同城、异地或者多地进行数据中心建设,以保证系统的稳定运行,但从目前实际情况来看,"同城双活"目前仍是很多银行采用的主要形式。银行业的"多活"架构在发展过程中存在三种典型的方式,可以形象的归纳为:"基本的活着"、"更好的活着"和"平等的活着"。

**什么是"基本的活着"?**在信息化建设的早期,银行通过将不同的业务系统部署在不同的数据中心,以保证不同的数据中心都处于活动状态。但是该模式一般逻辑上还是存在主中心的概念。例如,将核心业务系统、支付系统部署在主中心,而另一个中心部署和处理相对不太关键的业务系统。

**什么是"更好的活着"?**还是以核心系统为例,核心系统在同城两个数据中心同时部署,共同对外提供服务,实现应用层的多活,但是该模式还是存在一个主库,所以在同城另外一个中心发起的交易存在跨中心的数据访问,对于SQL数较多的交易影响明显。

**什么是"平等的活着"?**也就是数据中心在应用与数据两个层面都完全对等,例如如下解决方案。同城两个数据库都是全量数据库,本中心的核心应用只连本中心的数据库,没有跨中心的数据访问,不同数据中心通过双向同步实现数据备份,但是针对银行业务的复杂性,该模式存在两个挑战。一是可能出现多个中心同时对同一条数据的写操作;二是双向同步受数据库限制较大。所以,这种方案行业内暂时还没实施案例,但行业对"平等的活着"的探索一直没有停止。

核心系统对"多活"的第一性诉求

在进行"多活"架构建设中,需要剖析问题的本质,抓住银行进行"多活"架构建设的第一性诉求。从"高中低"可以划分为三个诉求:

● 数据中心完全对等:数据中心同时对外提供服务,资源使用基本均衡,并且可在不同的数据中心快速切换;

● 更好的性能保证:在满足核心业务场景的前提下,尽量避免跨中心的数据访问及跨地域的交易;

● 故障的影响小:发生各种不同类型的故障时,对系统影响尽可能小,并且出现故障后可以快速恢复。

核心系统"多活"架构的建设实践

结合银行核心应用系统的建设实践,目前行业中一般采用两种方式进行"多活"架构的建设。

一种是"单元化"的解决方式:

什么是单元化?单元化的本质是数据层的分布式。 通过将业务划分为独立,功能相同的业务单元,并且每个单元内部都可以处理完整的业务流程,所有单元的数据合并形成完整的数据,这是对单元化的准确描述。理论上单元化是一个架构级的解决方案,因为实现单元化的前提是需要单元寻址,通过全局路由首先确定业务需要访问和处理的单元。所以单元化相比后面提到的"轻量化"解决方案,对业务层的侵入 和影响要大很多。(举例:路由服务和用户系统间的一致性需要专门处理)

单元化的架构模式目前也被一些银行所采用,其具有的优势在于 ,一是可以满足对"多活"模式的需求;二是便于以单元为单位实现扩展、备份和恢复;三是各单元物理隔离,线性增长明显,相互间影响较小。单元化的主要弊端在于,一是架构复杂程度高,由于"单元寻址服务"的引入,对其的稳定性、可靠性及运维都提出了较高的要求,并且还有一些共性的功能需要统一考虑。

二是业务的复杂度增加明显,架构只在入口进行数据拆分及路由,拆分带来的所有问题都需要应用来解决;跨单元查询甚至需要另外独立的系统(或者特定的非数据单元)来处理;某些没有包含拆分字段的业务需要特殊处理。

三是考虑灾备因素,单元化投入成本会更大。

另一种是通过"轻量化"的解决方式:(互联网在用)

什么是"轻量级"的解决方案?**"轻量级"是相对比架构级的单元化而言。**如果可以用一种"轻量级"的解决方案解决"多活"建设的诉求,其实是为银行的"多活"架构建设提供了一条新的建设路径,尤其是针对很多科技能力、科技投入相对大行较低、较少的中小银行,既满足了诉求,又降低了建设难度。

"轻量级"解决方案的优势在于,一是架构简洁,只需要对数据进行分库处理,不会对应用层带来入侵。二是针对跨中心的访问,可以通过应用层跨中心路由实现,规避跨中心的数据访问,并轻量级解决跨分库查询的问题。三是应用实例完全对等,单个故障几乎无影响,实现高可靠性。但同样对跨中心路由的性能、稳定性、一致性等的要求较高,如果只是简单的逻辑计算,该缺点可以忽略。

综合两种解决思路,明显**"轻量级"解决方案硬件资源投入小、架构简单易维护、对应用侵入小,同时也可以支撑亿级以上的数据量。**所以,笔者认为单元化只是现阶段银行分布式转型中的一种过渡方式,在云原生时代,轻量级的解决方案更符合技术和架构的发展趋势。

虽然两种方式都可以解决银行"多活"建设过程中的问题,但是结合上面对"多活"建设的第一性诉求,**"轻量化"的解决方案不仅可以实现数据中心的完全对等,并且可实现本中心内调用,无跨异地交易,更好的保证了性能。**同时,在应用层可以实现故障面更小的影响,满足银行进行"多活"建设的最高诉求,既故障影响最小。

参考:
金融信创 | 神州信息银行核心系统多活架构实践 - 知乎

相关推荐
Tom Boom2 小时前
【3. 软件工程】3.1 软件过程模型
职场和发展·系统架构·软件工程
CryptoPP15 小时前
基于WebSocket的金融数据实时推送系统架构设计对接多国金融数据API
websocket·网络协议·金融·系统架构·区块链
OpenVINO生态社区3 天前
【汽车传感系统架构:借助传感获取安全】
安全·系统架构·汽车
牛马程序员小邓3 天前
系统架构师备考——软件工程基础知识篇(软件测试&净室软件工程&基于构件的软件工程)
系统架构·软件工程
一枝小雨3 天前
ARM异常处理流程与中断机制总结,与常见丢中断情况
arm开发·嵌入式硬件·架构·系统架构·arm
韩曙亮4 天前
【系统架构设计师】数据库系统 ② ( 分布式数据库 | 分布式数据库 特点 | 分布式数据库 分层模式 | 两阶段提交协议 - 2PC 协议 )
数据库·分布式·系统架构·分布式数据库·软考·dbms·两阶段提交协议
Cool----代购系统API4 天前
从系统架构、API对接核心技术、业务场景设计及实战案例四个维度,深度解析1688代采系统
系统架构
财神爷的小跟班o4 天前
跨境TRS投资操作指南与系统解决方案
金融·系统架构·区块链
mit6.8245 天前
[OS_4] 数学视角 | 多状态 | 模型检查器 | 程序验证(math)
开发语言·算法·系统架构
逍遥德5 天前
pom.xml与.yml,java配置参数传递
xml·java·spring boot·后端·系统架构