全球首例银行“大型机”下移背后

20 年 12 月 24 日，在腾讯云数据库品牌升级的时刻，我们也有幸邀请到了平安银行技术负责人李中原分享平安银行分布式数据库 TDSQL 实践，讲述全球首例银行“大型机”下移背后的故事，以下是平安银行技术负责人李中原的演讲全文：

尊敬的各位领导，各位来宾大家下午好，我是平安银行技术负责人李中原，今天由我代表平安银行给大家分享平安银行在分布式系统建设中的经验。

我的分享有四个部分，第一个是分布式 PssS 平台项目，第二个是同城多活的建设，第三个是自动化运维建设，最后是弹性扩容的能力建设。

A+信用卡核心是国内首例由大型机直接下沉到分布式系统的核心系统，信用卡建设的契机是在我们一级卡量精准服务，性能突破，成本控制，并且快速创新能力受到底层服务框架制约的情况下，行领导提出需要建设一套全新的能够实现快速业务交付以及灵活、富有弹性的新的信用卡核心系统。

于是 2018 年 12 月份我们开始启动了信用卡 A+项目，整个项目历时两年，于今年 10 月 31 日正式投产。由于今年双 11 规则是从 11 月 1 日开始，所以新系统上线的第二天就要承接双 11 巨大的压力，但在这个基础上我们的系统最终还是非常平稳的上线。

基于信用卡建设的契机，我们同时建设了一整套的企业级全栈式服务化的技术中台，这个技术中台主要是 PssS 层，其中主要的核心组件有大约九个，而数据库组件可以说是核心中的核心，选用了腾讯云 TDSQL 数据库，基于 PssS 平台建设的信用卡核心系统，整体的处理能力较原有系统提升了十倍，理论上具有无限横向扩展能力，而且成本是原系统 1/3 不到，保守估计未来五年可以节约成本 14 亿。

信用卡 A+系统采用单元化 DSU 分布式架构，基于私有云和 PssS 平台建设，应用微服务化，拆分解耦。DSU 整体设计逻辑采用按客户维度进行分片，由 GNS 去负责解析，完成分片，由 DLS 实现分片的路由，分片内部实现自包含，所谓自包含就是说我们所有的客户的业务均可以在单个分片完成，包括交易授权、用卡业务，也包括我们的批量业务。

在 DSU 之外，为了满足聚合查询、分析、归档需求，我们同时建设一套 sharding 版的 TDSQL，用于实现聚合的查询，我们支持全量、增量以及实时的数据同步，同时为了完成数据归档，我们建设了一套 Hadoop 集群作为归档数据平台。

接下来第二部分是同城多活，这是我们反复打磨，不断极限测试的一个部分。首先这个是我们 DSU 部署架构，部署架构中采用了非常典型的两地三中心，一主五备的架构，它的架构的特点是同城备机强分步，同机房异步，不管什么场景下，包括硬件、软件各种场景的故障均实现了 RPO 为 0，完成跨机房、强同步和一键切换。

第二个是异地容灾模式，半小时是在对系统包括数据库做极限压力的时候它的最大的一个值。其实我们上线到目前为止两个月我们观察到的 RTO 和 RPO 的值远没有到半小时，其中还包括跑批的时间。

我们的同城多活是建设所有组件的同城多活，我们架构中第一个组件就是 LVS，LVS 由于本身技术特性不能实现跨数据中心的高可用架构，这个过程中我们跟腾讯的研发团队反复的沟通协商，最终我们建设了一个 LVS Group 的概念，通过这样一个概念把两个数据中心的 VIP 绑定在一起，对我们的业务提供服务，通过这样的模式最终实现了 LVS 的同城多活。

正常业务的访问场景是业务流量进入系统的时候通过域名访问我们的数据库，同城部署的时候应用不需要做任何修改，它的域名和端口都是相同的，由我们的 GSLB 组件解析，生成不同机房不同的 LVS VIP，根据我们的流量权重的配置转发到相应的网关，再由网关专发到数据库主库，读写分离场景中转发到备库。

这个架构最大的特点有两个，第一个就是我们所有组件是同城多活的，另外一个我们的应用流量是本地访问的，最大限度减少了机房之间的访问交互。

这是我们 LVS 高可用组，在一个机房整体故障的场景，GSLB 会自动检测到我们的 LVS Group 不可用并自动启动切换，切换的时候会直接在域名解析层解析到另外一个机房的 VIP，另外一个机房的 LVS 把流量往下转发。这个过程中根据我们的测试，正常基本上是几秒到十几秒就可以完成。

还有一个场景就是我们的 PROXY 在一个机房完全宕掉的情况下，GSLB 监测到 PROXY 在整个机房不可用的情况把域名切到另外一个机房。

分布式自动运维的建设，分布式数据库我个人觉得在我们运维和建设过程中可能最大的难点是它的数量特别庞大，我们对它做运维和建设的过程中可能会面临管理上难度高，升级替换困难的情况。我们把我们 TDSQL 相关的组件做这么一个分类，其实它们有机结合在一起的，核心的组件跟业务的访问造成影响的组件，包括 LVS、网关以及 TDSQL，它们的升级我们采用滚动的升级方案。

另外的组件包括集群的组件，包括 ZK 等，它们的不可用对我们的业务本身并没有影响，但是它可能会影响集群的一些功能。另外就是多源同步，影响到聚合查询，一些分析报表的情况，所有的这些组件我们都通过集群化，通过滚动升级能够实现在线的升级和扩容。

自动化运维过程中我们着力打造了一套全链路核心的部件，能够实现一键切换，这里强调一下，一键切换指的是哪怕不是很熟悉的运维，只要知道我们的规范，按照我们的要求去做就可以直接一键完成我们这个切换的操作，主要包含主备的同城切换，测试的过程中我们也反复在压测，正常的一个机房之间的切换我们控制在一分钟以内做完切换，如果希望更快的话可以更快，但是为了避免机房之间雪崩效应，对它的速度有所控制的；单个 DSU 切换时间四到五秒，除了这些，我们还包括流量的切换，以及强同步不同级别的切换方案，也包括计算资源可以实现一键的扩容。另外就是强分布的这种批量的管理和一键问题处理能力。

另外就是在做数据库自身的建设以外，我们也着力建设一些工具，这些工具主要支撑应用以及开发业务对我们系统的访问，主要包含这样几个部分：查询工具，发布工具、数据比对工具以及容量平台。

简单来说，查询工具因为是多 DSU 的部署，查询可能会有查个别 DSU 或者全量 DSU 的需求，由于银行属性，我们做了一些脱敏限制，在没有权限的情况下，查到的数据会被我们自动脱敏。

第二部分是发布工具，在 DSU 尤其是在多 DSU 的变更过程中，如果由于变更的故障导致业务故障，那这个故障其实是灾难性的，因此我们重点打造了我们的发布工具，发布工具中内嵌 SQL 审核的功能，有相应的风险管控，还提供灰度发布以及发布操作的回滚功能。

另外就是数据比对，因为我们是多 DSU 灰度发布，过程中有可能个别的 DSU 出现失败的情况，因此我们提供了数据比对的工具。

最后还有容量平台，容量平台是我们提供了一个公用的平台，主要给业务，给开发提供容量的管理，趋势的预测，并可以在我们平台上实现自动的数据归档的功能。

最后，我们来看我们弹性扩容的能力，DSU 场景下，我们认为扩容要以防为主，以治为辅，以防为主是指尽量给我们的单个 DSU 容量设限，正常的情况下给 DSU 预留一定的 buffer，包括对我们的交易以及批量业务做拆分，另外我们也支持进行横向的扩容。

扩容的场景简单来说其实有这样两个，一个是横向的扩容，一个是纵向的扩容，当然，我们要尽可能的去避免纵向扩容，但是我们在系统建设过程当中也预留了巨大的纵向扩容的能力，在我们的建设过程中我们单个 DSU 数据库实例仅占整机资源的小部分，也就是说我们有能力进行几倍的扩容，我们的扩容的重点在于 DSU 横向扩展，横向扩展简单来说就是新加 DSU。方案大体是这样，通过 GNS 层调整分片的路由规则，由新的路由规则控制我们新增的用户，以及流量的比例，实现平滑进入到新扩容的 DSU，从而实现非常平滑的扩容。

我的分享就到这里结束，感谢大家。