银行业“多活”的发展历程
受监管政策的要求，银行一般会在同城、异地或者多地进行数据中心建设，以保证系统的稳定运行，但从目前实际情况来看，“同城双活”目前仍是很多银行采用的主要形式。银行业的“多活”架构在发展过程中存在三种典型的方式，可以形象的归纳为：“基本的活着”、“更好的活着”和“平等的活着”。
什么是“基本的活着”？在信息化建设的早期，银行通过将不同的业务系统部署在不同的数据中心，以保证不同的数据中心都处于活动状态。但是该模式一般逻辑上还是存在主中心的概念。例如，将核心业务系统、支付系统部署在主中心，而另一个中心部署和处理相对不太关键的业务系统。
什么是“更好的活着”？还是以核心系统为例，核心系统在同城两个数据中心同时部署，共同对外提供服务，实现应用层的多活，但是该模式还是存在一个主库，所以在同城另外一个中心发起的交易存在跨中心的数据访问，对于SQL数较多的交易影响明显。
什么是“平等的活着”？也就是数据中心在应用与数据两个层面都完全对等，例如如下解决方案。同城两个数据库都是全量数据库，本中心的核心应用只连本中心的数据库，没有跨中心的数据访问，不同数据中心通过双向同步实现数据备份，但是针对银行业务的复杂性，该模式存在两个挑战。一是可能出现多个中心同时对同一条数据的写操作；二是双向同步受数据库限制较大。所以，这种方案行业内暂时还没实施案例，但行业对“平等的活着”的探索一直没有停止。
核心系统对“多活”的第一性诉求
在进行“多活”架构建设中，需要剖析问题的本质，抓住银行进行“多活”架构建设的第一性诉求。从“高中低”可以划分为三个诉求：
● 数据中心完全对等：数据中心同时对外提供服务，资源使用基本均衡，并且可在不同的数据中心快速切换；
● 更好的性能保证：在满足核心业务场景的前提下，尽量避免跨中心的数据访问及跨地域的交易；
● 故障的影响小：发生各种不同类型的故障时，对系统影响尽可能小，并且出现故障后可以快速恢复。
核心系统“多活”架构的建设实践
结合银行核心应用系统的建设实践，目前行业中一般采用两种方式进行“多活”架构的建设。
一种是“单元化”的解决方式：
什么是单元化？单元化的本质是数据层的分布式。通过将业务划分为独立，功能相同的业务单元，并且每个单元内部都可以处理完整的业务流程，所有单元的数据合并形成完整的数据，这是对单元化的准确描述。理论上单元化是一个架构级的解决方案，因为实现单元化的前提是需要单元寻址，通过全局路由首先确定业务需要访问和处理的单元。所以单元化相比后面提到的“轻量化”解决方案，对业务层的侵入和影响要大很多。（举例：路由服务和用户系统间的一致性需要专门处理）
单元化的架构模式目前也被一些银行所采用，其具有的优势在于，一是可以满足对“多活”模式的需求；二是便于以单元为单位实现扩展、备份和恢复；三是各单元物理隔离，线性增长明显，相互间影响较小。单元化的主要弊端在于，一是架构复杂程度高，由于“单元寻址服务”的引入，对其的稳定性、可靠性及运维都提出了较高的要求，并且还有一些共性的功能需要统一考虑。
二是业务的复杂度增加明显，架构只在入口进行数据拆分及路由，拆分带来的所有问题都需要应用来解决；跨单元查询甚至需要另外独立的系统（或者特定的非数据单元）来处理；某些没有包含拆分字段的业务需要特殊处理。
三是考虑灾备因素，单元化投入成本会更大。
另一种是通过“轻量化”的解决方式：（互联网在用）
什么是“轻量级”的解决方案？“轻量级”是相对比架构级的单元化而言。如果可以用一种“轻量级”的解决方案解决“多活”建设的诉求，其实是为银行的“多活”架构建设提供了一条新的建设路径，尤其是针对很多科技能力、科技投入相对大行较低、较少的中小银行，既满足了诉求，又降低了建设难度。
“轻量级”解决方案的优势在于，一是架构简洁，只需要对数据进行分库处理，不会对应用层带来入侵。二是针对跨中心的访问，可以通过应用层跨中心路由实现，规避跨中心的数据访问，并轻量级解决跨分库查询的问题。三是应用实例完全对等，单个故障几乎无影响，实现高可靠性。但同样对跨中心路由的性能、稳定性、一致性等的要求较高，如果只是简单的逻辑计算，该缺点可以忽略。
综合两种解决思路，明显“轻量级”解决方案硬件资源投入小、架构简单易维护、对应用侵入小，同时也可以支撑亿级以上的数据量。所以，笔者认为单元化只是现阶段银行分布式转型中的一种过渡方式，在云原生时代，轻量级的解决方案更符合技术和架构的发展趋势。
虽然两种方式都可以解决银行“多活”建设过程中的问题，但是结合上面对“多活”建设的第一性诉求，“轻量化”的解决方案不仅可以实现数据中心的完全对等，并且可实现本中心内调用，无跨异地交易，更好的保证了性能。同时，在应用层可以实现故障面更小的影响，满足银行进行“多活”建设的最高诉求，既故障影响最小。
参考：
金融信创 | 神州信息银行核心系统多活架构实践 - 知乎
