腾讯云单元化架构体系介绍

作者：ethanyhuang

在金融科技转型的关键时期，为增强腾讯云在金融核心系统的”转型”、”上云”、”单元化”等方面的解决方案，本文基于多个金融行业一线项目，经过总结、梳理、沉淀形成符合腾讯云产品特征与交付体系的单元化架构体系。提升售前与产品能力。希望在未来几年大规模金融核心系统转型的浪潮中，能帮助一线架构师更好地理解单元化架构，进一步巩固加强腾讯云在金融核心领域取得的成果，做好技术与专家储备。

1.背景

自2018年以来，受“华为、中兴事件”影响，我国科技受制于人的现状对国家稳定和经济发展都提出了严峻考验。目前我国IT架构体系严重依赖国外产品，金融行业尤其明显。大部分传统银行的关键账务系统都架设在IBM的大型机、小型机之上，数据库使用Oracle及DB2，存储采用EMC。在美国不断加大对我国技术封锁背景下，银行IT产业自主可控的必要性和紧迫性凸显。

以银行的核心系统为例，其作为金融监管部门直接管辖的系统，率先被要求进行国产化试点与替换。银行核心作为众多银行系统中最为重要的命脉系统，承担着核心的存、贷、汇业务和监管部门的监控指标。大型银行对其核心系统的性能和稳定性要求之苛刻可谓求全责备，故银行的传统核心通常都采用IOE的技术架构。当传统核心往分布式技术架构转型的过程中充满了挑战，其中，单元化技术架构是目前所有大型银行都会在其新一代核心系统中采用的主流架构体系。本文将从技术架构发展历程开始，一步步介绍每个阶段是如何演变？为什么到微服务阶段还不足以满足大型银行系统的要求？单元化架构与微服务架构的差异？以及腾讯云的单元化解决方案。

2.技术架构发展历程 2.1 单体架构

集中式单体架构，程序和数据库都在一台主机上面。大型金融客户的核心就是在IBM的大型机或小型机上运行，主要基于Cobol语言开发。由于主机的高成本，每年客户都要不断购买MIPS（主机算力）来应对不断上升的业务量，然而对于这类架构而言，垂直扩展方式的边际成本是很高的。

图2.1 单体架构

2.2 应用与数据分离

集中式架构在业务高峰时，由于程序和数据库部署在一台服务器上很容易就出现资源争抢问题，所以第一步就是把程序和数据库分开部署。如下图所示，应对业务量上升导致的同一台主机资源争抢问题，优先采用的是将数据库独立部署来保证应用和数据库资源互不争抢。数据库所在的服务器资源配置通常更高于应用服务器，开放架构下一般是高配C86/ARM服务器。

图2.2 应用与数据分离

2.3 应用集群部署

随着业务量的增大，下一个问题便是应用侧的瓶颈。这块除了应用程序内部的性能调优外，从架构层面可以采用集群化部署模式，将大量的业务流量通过负载均衡服务来分流到多台应用服务器上处理。常见的负载均衡有F5，Nginx和云上的各种XLB服务。这个阶段的架构已经可以具备一定的横向扩容能力，需要注意的是应用需要实现“无状态”化，避免有状态数据存在本地。

图2.3 应用集群部署

2.4 读写分离

当应用侧可以实现横向扩容之后，逐渐对服务器垂直扩容的需求开始减少，因为垂直扩容的边际成本很高，收益却越来越小，大家更愿意通过扩容标准服务器来应对高并发。随着应用层实现横向扩容后，当业务进入到下一个阶段，压力又会回到数据库这边。应用横向扩容，而数据库还是单体。这个时候就需要分析当前系统的读写比。大多数系统的读写交易比是8:2，读多写少的场景可以考虑使用读写分离模式。开启数据库的主从复制能力，并将写交易路由到主库，读交易路由到从库。

图2.4 读写分离架构

我们可以设置多个从库来负载相对较多的读交易，主库与从库间通过数据库的数据复制能力来保证一致性。复制模式有分同步复制和异步复制。同步模式会损耗一定交易性能，因为需要等到多个从库请求落盘才会反馈主库，对性能敏感的写场景需要考虑业务容忍度。而异步复制会存在一定的延时，同样读交易也需要考虑业务容忍度。

2.5 前后端分离 返回搜狐，查看更多

责任编辑：