一、平安银行信用卡核心系统重构
平安银行的老信用卡核心系统是基于IBM大型机构建的典型的集中式架构核心系统，经过近10年的发展，已经越来越不能支撑业务的发展，甚至已经制约了业务的发展和创新，基于此背景，平安银行在2018年12月正式启动了信用卡核心的架构转型和系统重构的工作，新系统采用分布式单元化架构，于2020年10月底上线。
上线至今，新的信用卡核心系统经历了 “双十一”、“六一八”、元旦、春节以及大小业务促销活动，系统均平稳运行，出色的完成最初设定的六个目标。通过单元化架构，新核心系统理论上可以支持无限的扩展，用户量支持10倍以上的增长。系统和业务均实现自主可控，风控和精准服务能力大大提升。根据实际的测算，以5年为周期，新核心系统相比老系统成本节约近70%，节省费用超10亿，而且非常值得称赞的是性能提升了2-3倍。
平安银行新的信用卡核心系统采用了两地三中心的单元化分布式架构，如下图所示，根据用户维度进行单元化切分，每个逻辑单元支撑一定量的用户业务。单元内部数据库采用跨IDC强同步的数据同步模式，这意味着用户提交的事务必须被同城的备机接收到事务日志才算成功。当然，这会在一定程度上增加交易的耗时，根据压测和实际的运行情况来看，大约会增加20%左右的交易耗时。
下图是平安银行数据分片的设计方案，首先根据客户的客户号、客户账号、卡号生成唯一的客户ID，对客户ID进行hash分片，生成客户的分片信息。第二步，分片信息存储在GNS组件，GNS同时会把分片信息同步给进行路由交付的DLS组件。第三步，DLS组件实现把用户的申请交付到对应的单元。第四步，单元内部完成用户的全部业务，包括发卡、用卡、授权和批量。
分片设计的关键之一是要求分片内实现业务自包含，即用户的全部业务可以在分片内部完成，这种设计最大限度的减少了跨单元的访问。
除了单元的设计以外，数据的访问部分还充分考虑对数据聚合和分析场景的支持，如下图所示，应用数据的一部分数据会通过kafka、mq以流式消息的方式写入hadoop集群，同时数据库上的数据通过全量加binlog的方式准实时的汇聚到分布式shard库。OLAP类应用根据其对数据访问时延和分析量的大小区分为轻OLAP和重OLAP，轻OLAP主要由分布式shard库提供，完成不区分单元的日志数据查询和简单的分析报表，这类请求SQL简单、对延迟有一定的要求，分布式数据库可以完成的情况。
分布式数据库由于其数据可通过源库再生，业务上基本可以降级到单元数据库，因此其SLA相对较低；重OLAP主要是访问hadoop，主要进行相对复杂的报表分析和进行已归档数据的查询，这类请求逻辑相对复杂、对延迟要求低、可能分析大量数据甚至海量数据，分布式数据库往往也无法胜任。
二、分布式单元化数据库自动化运维
平安银行数据库的部署架构采用如下图所示典型的两地三中心的架构，其中同城两个IDC的距离超过30公里，异地IDC超过1500公里，数据采用跨IDC强同步模式，这种模式下同城备机在任何情况下都具有生产数据的完整副本，即同城RPO=0，RTO<60秒。根据反复的实际压测，RTO基本在40秒左右。
异地容灾采用异步模式，我们进行极限压测的结果是在进行一小时最大负载的交易或者批量期间，异地容灾环境的数据延迟约30分钟，我们据此评估容灾的RPO<30min，RTO<30min。实际上，根据生产运行的情况观察，异地容灾的延迟一般不超过2分钟，最大的延迟在5分钟左右。
分布式架构的数据库运维，如果要和集中式架构的运维比较的话，我认为主要有两个方面的不同。
第一个不同就是数量的不同，在传统架构模式下一台大型机、小型机的数据库需要分布式架构下几十台甚至上百台x86服务器的数据库，数量的不同会给运维带来巨大的挑战。
传统集中式架构数据库运维好比放牛，一个放牛娃就可以搞定一头牛，分布式架构数据库运维好比赶鸭子，我们期望的是一个人能赶一群鸭子，但是搞不好结果是一群人赶的鸭子满天飞。
第二个不同是运维思路的变化，我们已经不能用集中式架构的数据库运维思路建设和运维分布式架构数据库，这是因为，集中式架构数据库建设是最大限度的追求各种组件的高可用能力，无论是通过更高配置的设备，还是对设备进行集群和冗余，都只有一个目的，保证某个数据库组件的最大高可用，这样的结果是对IOE的依赖和设备越来越贵。
而分布式架构下由于x86的服务器高可用能力已经完全无法和集中式架构相比，故障率可能是百倍的增加，因此在分布式架构下数据库的运维追求的是最快的恢复速度，而非最高的可用性，最快恢复速度保证我们即便是x86服务器，我们一样可以建设出非常高的高可用性的系统。
我们认为分布式单元化架构数据库运维有一些基本要求，主要有下面几个：
数据库相关的组件都要保证无中心化节点，任何中心化节点在大压力的分布式架构都可能成为集群的瓶颈。
要保证每个单元的运维尽量标准化，标准化才能自动化，自动化保障所有单元运维的一致性。
数据库和应用都需要具备快速从故障中恢复过来的能力，尤其是应用在数据库从故障中恢复时应该具备自动快速恢复的能力。
要避免个别单元故障的蔓延，包括底层设备上的隔离，运维上的保证，如灰度发布等，以及对性能问题的监控和及时发现，避免问题影响所有单元才发现。
为了达成上面的这些能力的要求，我们建设了一整套的分布式运维工具。这些工具分四类，其中:
查询工具主要提供业务、开发、运维查询数据库的能力；
发布工具主要提供给运维进行数据库发布时进行风险管控和灰度发布以及回滚使用；
数据比对工具，主要提供给开发、运维保证生产单元之间，生产和开发、测试等环境的对象结构一致性；
容量平台主要提供给DBA、运维监控生产的容量和进行趋势的预测等。
上面的工具主要对象是开发和运维，那么给DBA使用的工具呢？DBA的工具主要进行故障的快速恢复和应急预案的支持，主要包括机房切换的能力，流量切换的能力，数据同步方案的切换，数据库计算资源的扩容，多源同步的管理，以及容灾演练。
我们在实践中发现，分布式单元化数据库运维稳定的基石主要有两个，分别是：
数据库的慢查询，我们通过对开发、测试环境的代码扫描，识别并优化慢查询，以及对生产环境的慢查询及时发现并跟踪优化的一整个闭环管理，保证生产基本没有慢查询。
保障数据量是在系统健壮运行的范围，数据量和大部分性能问题密切相关，容量可控，整个系统就基本可控。
通过这些工具，使得DBA管住了风险，掌握了容量趋势，屏蔽了个人经验对故障时效的影响，真正做到分布式数据库运维的一致性，使得一个DBA可以赶成百上千只“鸭子”。
三、分布式单元化数据库的弹性扩容
分布式架构天然的优势是横向扩容能力，我们在进行分布式架构建设时扩容能力主要考虑横向扩容，如下图所示，但是我们同时保留了纵向扩容的能力。
首先介绍我们主要的扩容方案，横向扩容。我们横向扩容采用新增单元的方式进行，扩容时只需要新增单元数据库，调整GNS路由规则，根据权重让更多新用户流入新的单元，老用户仍然保持在原有单元。整个扩容过程不需要迁移数据，不需要停机，因此也对用户无感，整个扩容逻辑如下图所示！
关于纵向扩容，我们认为分布式架构下纵向扩容正常不应该发生，我们认为单元的容量有限。容量包括存储容量和吞吐量，根据我们对单元的规划，正常情况下一个单元不应该去突破单元的容量阈值。解决问题最好的办法是“让问题不发生”，据此我们形成了纵向扩容的基本原则，“以防为主，以治为辅”。
以防为主的原则的主要内容是，单元的容量在进行规划时就预留一些BUFFER，比如我们以单元数据库CPU 60%作为上限评估我们单元的TPS、QPS，同时以此为标准反向评估批量耗时，让应用批量并发控制在数据库CPU不超过60%的情况下去保证批量用时达到业务要求。另外我们还对联机和账务进行拆分，尽可能避免他们之间的相互影响，影响用户体验。
以治为辅的原则内容是，单元数据库在不进行硬件升级的情况下可以进行数据库配置升级，我们初始上线时单个单元数据库实例只使用25%的整机资源，必要时我们可以对单元数据库进行4倍容量的升级。另外，在极端情况下，我们具备把部分遇到负载瓶颈的数据迁移到新的单元的能力，当然我们应该不会使用到这种能力。
四、分布式单元化架构的深度解析
1）优势
单元化分布式架构在我们银行已经体现出巨大的优势，这里我简单总结三个方面。
第一：系统可用率的提高，我们的信用卡新核心系统可用率已达到5个9，相比而言，传统大型机可能最多4个9，这是因为大型机虽然本身极为稳定，基本一年都不会有问题，但是一旦有问题往往需要一些时间处理。而我们的分布式架构，通过无缝的同城双活能力，不仅提升了数据的安全级别，还提高了系统可用性；我们的单元化架构已经可以做到任何数据库服务器故障不停机；另外数据的多副本，保证我们的数据库服务不会中断。
第二个优势是自主可控能力的大大提升，分布式架构下我们采用下x86的设备，整体基础架构层基本已经没有对个别设备的过度依赖。而数据库层我们采用国产厂商的数据库产品，应用层代码要么自研要么使用开源组件，也基本达到自主可控。通过技术上的自主可控带来了业务创新的自主可控，新的业务需求开发周期大大缩短。
第三个优势是理论上无限的扩展性，搭积木式的即插即用的单元模块设计，大大简化了系统横向扩容能力，前面第三节我们谈到，在进行横向扩容的时候我们可以实现真正的在线扩容，不需要停机、不会影响应用正是这种能力的体现。集中式架构最忌惮的式秒杀或者类似的业务推广活动，在分布式架构下，这个问题也被轻松的解决了。
2）劣势
任何事情都具有两面性的，分布式单元化架构优势很多，当然也会有劣势，这里我们也总结三个劣势。
第一个劣势是系统的重构工作量比较大。首先应用层和框架层为了支持分布式单元化架构，可能需要进行很多改造；其次监控系统和告警也需要相应的改造及收敛，否则很容易出现大批告警淹没正常的告警，而且太多告警会导致无法及时准确的发现真正的问题所在，需要对告警进行收敛；当然还包括运维工具的改造，如我们前面看到的一些运维工具，在集中式架构下可能是不存在的，或者使用方式是不太一样的。
通过我们自己的经验以及我们和同行的交流，分布式单元化架构存在过度单元化的问题。过度单元化可能主要有两个方面造成，一个是上下游系统业务不均衡带来的被动单元化，比如上游系统业务量很大，需要单元化，下游系统业务量比较小，不用单元化也可以支持，而且未来可能业务量也不会变得很大，但是下游系统为了和上游系统的对接不得不使用单元化架构；另外一个是由于单元化架构导致的数据库层或者应用层的资源使用率低而造成的资源浪费。
第三个劣势是如果分布式单元化架构所有单元都出现问题，解决起来可能更加困难，甚至是灾难性的。因此，保障单元的性能可控，避免个别单元的故障蔓延是非常重要的。保障单元的性能稳定要首先保障容量的可控，可以说容量是很多性能问题的催化剂。还要注意单元的访问性能和吞吐量的稳定，避免单元故障的蔓延。
了解了单元化架构的优缺点之后，自然就有一个疑问，我们如何扬长避短合理的使用分布式单元化架构呢？我认为关键有这几个地方：
合理的单元大小设计，单元过大和过小都不合适，过大容易出现性能问题以及可能需要扩容和拆分，过小会浪费资源。
所有节点去中心化，去中心化是分布式单元化架构稳定的关键之一，甚至对所有分布式架构都有这样的要求。
分布式事务的管理，我们银行在分布式事务上的设计逻辑是优先从业务逻辑上规避，另外就是从架构层支持，还不能解决的需要应用层支持，尽量避免使用数据库的分布式事务。
充分利用自动化运维，分布式架构运维的灵魂是自动化运维，要保证应用和数据库都能够快速从故障中恢复过来的能力。
最后，什么样的系统适合于使用分布式单元化架构，我们认为凡是可以进行数据和业务拆分的系统都可以使用单元化架构。比较典型的是涉及客户的交易系统，可以按照客户维度进行拆分，如卡账客，我们银行信用卡架构是这种情况。另外是可以按照地域或者子公司进行拆分的系统，比如某国有银行就采用了这样的架构。数据进行单元化拆分后，业务上能够做到自包含是单元化设计的关键。
Q&A
Q1：为了达成纵向扩容，会不会有比较大的资源浪费？
A1：我们单个实例虽然只使用了服务器的1/4资源，但是我们使用了单机多实例来进行资源复用，所以不存在资源浪费的情况。
Q2：应用和DB都单元化吗？
A2：是的，应用和DB都要单元化，而且每个单元都是一个逻辑上的小数据中心，在部署上也是会相对独立的，我们会部署到不同的机柜、使用不同的电源和网络交换机等。部署的一个基本原则是任何组件（网络、交换机、电源、机柜等）的故障最大的影响不超过集群的25%。
Q3：同城双活超过10公里，延迟会不会难以控制？
A3：我们的同城是超过30公里，采用4条裸纤，延迟在1ms左右，应用跨数据中心的时候延迟增加大约20%，我们一个交易耗时大约30-50毫秒，如果单纯看用户感受来说其实是感受不到的。
Q4：没有选择分布式事务能力的逻辑是什么？
A4：我们系统建设的目标是包括自主可控的，这个自主可控是要尽可能摆脱对某些组件和过度依赖，其实在选型的过程中是有过激烈的争论的，这个争论既有oracle和国产数据库的争论，也有分布式事务的争论。
通过调研和测试，我们认为国产数据库分布式事务能力还不够完善，另外经过多轮的测试和跟一些厂商的深入的交流，我们和开发、架构师达成了一些一致，这就是单元要尽可能自包含，过多的分布式事务系统就会变成网状的结构，失去了单元化架构的优势；另外就是通过架构层的支持，架构层的方案可以形成一种技术共享能力，以便其它系统使用，最后就是使用应用层的支持分布式事务，这比数据库分布式事务更可控。
Q5：相较传统集中式架构，分布式架构的运维有哪些差异？
A5：集中式和分布式第一个差异在于集中式追求组件的最高可用和性能，分布式追求的是组件的最快恢复速度和性能；第二个差异是在于数量的差异，原本一台服务器能够完成的任务现在可能需要数台乃至数十台，如何保障大数量的运维下的一致性和快速响应能力其实是最大的挑战
Q6：面对这些繁杂的分布式数据库运维挑战，尤其是使用生态尚未完善的国产数据库，如何尽可能高效地解决运维难题？
A6：坦率的说，国产数据库确实存在这样那样的问题，尤其生态建设方面，有的厂商甚至可能刚刚起步。我认为这主要是由于一方面，这些国产数据库最初多是自用，随着产品的得到认可而逐步推广，但是推广的时间相较于传统数据库差距甚远；另外一方面国产数据库往往会带入一些特定的场景，比如分布式，去IOE等，这些场景在厂商那里并不是最初的方向，所以厂商并没有配备完整的工具体系。还有在客户那里也往往是尝鲜性质的使用，会更加显得厂商的生态不全；还有一个原因是，国产数据库技术源头各不相同，因此使用的工具也不尽相同，加之也缺少一批专门进行工具建设的中间公司。
但是国内技术人才济济，加以时日这些问题自然水到渠成，对于目前需要使用的各位，可能要进行一些自定义开发的工作。上面材料我们也谈到，平安银行是花费大量精力去进行工具的建设，DBA这边主要包括：
开发、应用的支持上，第一做到标准化和审核；第二是把控风险，尤其是变更的风险。
管理容量和趋势，保障单元的数据库始终运行在最佳状态。
DBA的运维，其中最关键的是通过一些自动化的手段规避个人经验和能力对系统故障的处理时效等。
Q7：强同步复制是怎么实现的？
A7：强同步技术有点类似mysql的半同步，我们选择的产品厂商在源码上做了改进，基本原理是事务提交如果指定的备库未收到事务日志，则事务不能提交成功，直到备库接收到为止。如果备库损坏，比如服务器宕机，则事务日志一直不能被指定备库接收，主库会降级为只读状态，以保证数据一致性。
Q8：dml请问如何回滚的？
A8：我们的SQL审核部分是具有语法和语义解析的功能的，我们会在运行前通过反向操作备份到DBA指定的一个备份库里。如果dml操作一切正常，后续平台会有自动任务请理备份的数据，如果dml有异常，DBA直接授权开发、运维访问备份数据的权限，以此最快的修复异常。
Q9：能实现异地多活的效果么？实现了单元化的话，如何避免跨机房的数据调用呢？
A9：目前我们的业务场景还不能进行异地多活，我们今年进行过两次容灾演练，第一次数据库不切换，把异地放入流量进来，我们运行了两个小时。通过应用的反馈，业务系统成功率下降很多，整体耗时增加超过一倍，对于金融业务，尤其是交易都是同步的场景，异地多活可能还不太现实，但是对于一些互联网业务应该是可以的。第二次演练是把数据库切换到异地，并在异地运行24小时，以此检验异地环境的承载能力，这次演练总体运行平稳，少量报错在预期之内。第二个问题，分享内容里面有比较详细的说明，不再赘述。
获取本期PPT，请添加群秘微信号：dbachen
↓点这里可回看本期直播
阅读原文
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒