随着金融行业数字化转型的需求，银行核心系统的升级改造成为重要议题。本合集中四篇文章，从项目背景、实施过程、技术创新点等角度，全面解析了杭州银行上线的首个云原生、分布式、全栈国产化的银行核心业务系统。
杭州银行新一代核心系统的成功上线具有标杆性意义，它标志着国内银行业核心业务系统进入了新的技术时代，代表着我国银行业在科技领域的信息自主安全可控、技术架构现代化和系统投产切换工艺均达到了一个新的水平。此次成功投产再次印证了 TiDB 分布式数据库在银行核心系统数据库建设、确保业务连续性以及支持业务敏捷高效创新等方面具备关键的能力。
TiDB × 杭州银行
首个云原生、分布式、全栈国产化银行核心业务
系统投产上线
日前，杭州银行新一代核心业务系统成功投产上线。新核心系统是业内首个实际投产的云原生、分布式、全栈国产化的银行核心系统，是金融科技领域突破关键核心技术应用的重大实践。
新核心系统自上线以来运行安全稳定，大幅提升了业务处理效率，已支撑日均交易量 1000+ 万笔，平均交易耗时小于 100 毫秒，较原核心业务系统缩减 54%，日终跑批的处理速度为原核心业务系统的 2.1 倍，能够有效支撑未来业务的快速发展。标志着杭州银行核心业务系统实现完全自主可控和架构升级，是建设“数智杭银”的重要成果，为杭州银行数字化转型发展注入新动能，为同业建设核心系统架构转型提供了标杆案例和解决方案。
点击此处丨查看原文
分布式数据库国产替代，杭州银行在挑战什么
分布式数据库替换之“杭银路径”：找到合适的，你就去做，只要用了就有经验，只要有经验就能够改造。
2022 年 6 月，杭州银行新核心项目正式启动。同年 11 月，TiDB 被列为核心系统数据库第一选择方案。2023 年 5 月，杭州银行完成系统功能开发和外围系统的改造，在随后几个月的各项测试验证后，11 月 18 日，杭州新一代新核心系统正式投产上线。新核心系统是业内首个实际投产的云原生、分布式、全栈国产化的银行核心系统。
为什么是现在？
对于杭州银行而言，从 1996 年建行起，银行核心系统的建设发展经历了两个主要阶段：1999 年，第一代核心系统正式投产，它实现了杭州银行各网点业务系统的联网互通；2012 年，第二代核心系统投产，它实现了从以账户为中心到以客户为中心的转变。
到了 2022 年，杭州银行正式启动新一代核心系统重构，力求以全栈国产化、分布式、云原生的架构作为新核心的建设底座。基于全栈国产化，杭州银行实现了在办公管理类、终端技术类、一般业务类和核心关键业务系统的国产化能力搭建；基于云原生、分布式的架构建设，杭州银行搭建了面向客户、内核成熟、灵活扩展、稳定高效、自主可控的第三代分布式核心系统。
关于建设云原生分布式核心业务系统的必要性，李炯曾在 2023 年 6 月撰文分析了三点原因：一是系统基础功能重构；二是技术升级换代；三是自主可控。
“不依赖于云的数据库”
这里的自主可控其实有两层含义：一是降低对非国产化数据库的使用占比；二是保持自身技术的可控和独立性，而不是“黑盒”，不依赖于产品定制或某个产品特性，因为“特性”有时对解决客户问题带来方便，但也增加了对企业的依赖度。
国产数据库的换道超车，还需珠峰检验
截至目前，杭州银行新一代分布式核心系统上线已有月余。结合最近几个重要节点包括月末处理、年度结息、年终处理的验证来看，杭州银行对 TiDB 给出了较高的评价：“在高吞吐、低延迟、高可用、自动伸缩，以及围绕整个上线的整体服务方面，是超出预期的。”这还远远不够。
正如上文提到的，对于银行核心系统数据库的选型，分布式数据库只是作为一类。国产分布式数据库技术已逐渐成熟，不仅能够取代传统的国外数据库系统，还能在核心系统方面进行替代，从而支持银行的核心运营需求。但银行拥有大量系统，真正需要分布式数据库作支撑的可能也只有一部分。银行需要有不同层次、不同类型的数据库厂商参与，并进行管控，而不是简单的一刀切。
点击此处丨查看原文
“分布式透明化”在杭州银行核心系统上线之思考
随着金融行业数字化转型的需求，银行核心系统的升级改造成为重要议题。杭州银行成功上线以 TiDB 为底层数据库的新一代核心业务系统，该实践采用应用与基础设施解耦、分布式透明化的设计开发理念，推动银行核心系统的整体升级。
银行核心系统的演进及观察
银行核心系统，也称为 Core Banking，是银行处理存款、贷款业务为主的核心 IT 系统。作为支撑业务营运的关键系统和银行信息化的重要组成部分，被称作银行 IT 系统的“心脏”。
从历史演进来看，银行核心系统经历了从手工时代到 PC 时代，到联网联机、数据大集中，再到以客户为中心的发展历程。在推动分布式核心发展中，以“微服务、单元化”为代表的架构设计理念成为主流。
随着近十年国产分布式数据库的快速发展，其成熟度、稳定性等已趋于完善，开始在金融核心系统为代表的重要业务系统中尝试使用。当然，这一新架构产品对架构、开发、运维等都带来很多变化。特别是架构、研发层面，之前业务系统在设计上多是以集中式数据库能力为基础进行的，对于分布式架构存在诸多差异。
TiDB 在杭州银行新一代核心实践
● 从架构角度来看，首要问题就是解决所谓透明化问题，即对数据库建模、设计、开发过程仍可沿用之前的实践，尽量减少因引入分布式数据库所造成的差异。
● 从研发角度来看，针对数据分片后不可避免的分布式事务问题，在框架层尚无成熟完善的分布式事务解决方案下，充分利用底层数据库的分布式事务能力来解决，这样开发简化很多。
● 从运维角度来看，引入分布式数据库会带来不小的挑战，当然同时也有着明显收益。
点击此处丨查看原文
金融企业区域集中库的设计构想和测试验证
区域集中库的架构设想
随着业务的创新和发展，MySQL 存量节点多，管理难度大，资源利用率低，背离了规模部署、高效运维、敏态供给的云化发展理念，在生产运行的各阶段中存在不少的能力短板，比如：
部署建设阶段
● 以业务发展目标或者每日批量压力高峰进行数据库资源规格评估，可能存在资源浪费和发展不同步的可能性。
● 不同的版本、部署方案、变量参数和管理平台共存， 配置的碎片化不利于团队知识管理，阻碍标准化发展。
生产运行阶段
● 应用数模设计阶段缺少主键约束造成主从同步延迟，影响从库数据时效，高可用机制可能存在不稳定。
● 业务应用重复订阅全行统一的人员、机构和客户等主数据推送，浪费存储容量，占用数据库和网络资源。
● 数据库面对下游业务的数据供给需求，复制链路构成较为复杂的网状结构，管理和维护成本较高，客户上限制了数据价值的进一步挖掘。
数据库整合场景测试
2.1 资源管控
● 集群资源的评估
● 不同规格 RU 对联机交易的影响
● 资源组 BURSTABLE 属性对调度的影响
● 在线调整 RU 对联机交易的影响
2.2 读写分离
● 会话的读写分离
● 物理备份的读写分离
2.3 业务管理
2.3.1 SQL 黑名单功能
● 资源组的自动策略
● 手工配置黑名单
2.3.2 业务会话标识功能
● 会话变量
● 会话属性
2.3.3 细粒度监控功能
2.4 测试小结
通过以上的测试，基本上验证了利用分布式数据库实现区域集中库的设想：
1.资源隔离特性具备数据库规格限制，支持用户、会话及语句等粒度。在线调整即时生效的特点，可以基于不同业务资源消耗的时间窗口进行资源“调度”，实现资源利用效益最大化。
2.Learner 角色副本可用于数据抽取、查询和备份等场景，保证生产隔离，节省“从集群”的资源开销。
通过规则和已知的 SQL 指纹对不良 SQL 能实现有效防范。
3.通过业务会话标识和细粒度监控功能，基本满足应用整合后的观测需求。
集群 RU 评估方法、Query Limit 策略添加扫描行数或 RU 资源使用监控、资源组添加时间计划等有待继续改进。
区域集中库的优势和使用设想
区域集中库是将数据库整合落地在数据库层，通过标准化部署和细粒度资源配置，得到更高的服务可用性、规格弹性和资源利用率。两种整合方式的适用情况对比如表
综合各个能力项对比结果，评估区域集中库在建设和运行成本、服务质量上均具有较大的优势。在使用过程中，需要配套管理措施：
1. 开发建设典型业务压测模型（如转账交易）作为标尺，根据该模型得到集群交易性能上限，按典型业务性能设计成多个规格，再由需求方根据该模型评估业务交易性能需求规格和业务批量窗口特点进行对接。
2. 统一管理区域集中库的全行主数据，数据团队只需要接入一次数据，实现资源集约使用。
3. 利用单副本的 Learner 节点实现读写分离，对接备份、ETL 抽取、数据查询平台等非业务的数据需求。
4. 与行内的低代码开发平台进行对接，通过框架的配置功能使用数据库的会话属性和业务会话标识功能，实现更加有效的 SQL 定位和管理。
5. 引导应用运维自助查看资源组监控和细粒度日志。
点击此处丨查看原文
点击进入金融专区！
与 PingCAP 一同打造创新的金融数据基础平台，
加速数字化和智能化转型！
