本文由阿里技术专家吉远撰写于2022年2月。
项目背景
长久以来，IOE技术架构成为银行业核心的标准配置和唯一选择，它们组成的系统一度被视为大型金融企业后台的“黄金架构”，某银行客户A类一级核心业务系统采用的就是成熟的“商业系统+集中式架构”的构建方式：IBM大型机、Db2数据库、EMC存储。
然而，今天在云计算/云原生等新兴技术普及趋势下，传统集中式架构正在面临前所未有的挑战，业务痛点具体如下：
- 业务迭代慢：商业软件架构和技术封闭，生态不足，迭代缓慢，应对金融创新乏力，因此很难服务于瞬息万变的国内市场环境及千变万化的用户需求。
- 性能低扩展性差：集中式架构扩展性和弹性能力差，无法支撑在类似“双11”等高并发场景下对系统负载产生的巨大压力，交易缓慢。
- 稳定性风险高：线上金融业务有 7*24 小时服务不间断要求，传统架构在运行监测、问题定位上响应缓慢。同时，针对应用、资源或机房级故障，不能快速恢复业务。
- 维护成本高：基于 IBM 的大型主机和 Db2 数据库的集中式系统的总成本（购置/扩容+维护服务）远超基于X86的分布式系统，成本压力愈发明显。
- 无法自主可控：金融行业作为自主可控的行业之一，IOE厂商对国有银行形成事实上的垄断，在核心系统领域受制于人容易“卡脖子”，不符合当前国家推进自主可控的顶层设计。
因此，原有系统已经到了支撑能力的天花板，新系统的构建迫在眉睫。
单元化分布式架构设计
作为国有大行核心去IOE并且是上阿里云的首个大机下移试点项目，在没有可借鉴对象的大背景下，如何将核心系统从传统大机架构平滑切换到分布式架构本身就是一个巨大挑战，尤其是在已经拥有亿级用户基数的情况下，如何既能充分发挥分布式架构的高可扩展性，又能满足金融业务严苛的安全、稳定、可靠要求，是新核心系统建设首要面临的问题。
经过和客户对焦，最终明确新一代分布式架构 6 大设计目标，在金融业务场景下满足高可用、高标准、低风险的要求。同时，在互联网场景下需满足高性能、高弹性、低成本的诉求。具体如下图：
图1 分布式架构设计目标
客户核心系统分布式设计，整体部署采用“同城双活+异地灾备”的两地三中心架构，实现同城 RPO=0，RTO 分钟级，异地 RPO 分钟级的容灾目标。其中底层数据库采用 OceanBase 数据库设计的单元化架构，具体如下图：
图2 同城三机房单元化架构
单元（即单元化应用服务产品层的部署单元），是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。单元化架构就是将单元作为部署的基本单位，在全站所有机房中部署多个单元，每个机房内单元数目不固定，任一单元均部署系统所需的全部应用，数据则是全量数据按照某种维度划分后的一部分。
单元化的本质，就是把数据流量，按照一定纬度进行拆分。使得一个单元能够闭环提供完整的服务能力。但这个服务能力面向的是拆分后的部分数据流量，且只服务于这部分流量。
单元化解决的问题
- 容量问题：IDC资源紧张，集中式单机数据库连接瓶颈。
- 多机房容灾：控制故障爆炸半径
- 用户体验：就近访问，提升用户请求访问速度
单元化设计原则
- 核心业务必须是可分片的（交易、支付、账务）
- 必须保证核心业务的分片是均衡的，比如客户号、会员号作分片维度
- 核心业务要尽量自包含，单元内全部收敛掉，调用要尽量封闭
- 整个系统都要面向逻辑分区设计，而不是物理部署
应用单元化设计
应用App部署在第一机房和第二机房，2个机房，互为主备。
1个Gzone单元，双机房应用无状态对等部署，数据仅有一份，需要跨机房访问。
10个Rzone单元，双机房单元互备共20个Rzone，应用/数据访问自闭环，应用故障爆炸半径控制在10%以内。
- GZone（Global Zone）：部署了不可拆分的数据和服务，这些数据或服务可能会被 RZone 依赖。GZone 在全局只有一组，数据仅有一份。 设计：网关、配置、参数、路由等全局服务。
- RZone（Region Zone）：最标准单元定义的 zone，每个 RZone 都是自包含的，拥有自己的数据，能完成所有业务。设计：交易、支付、账务等核心可分片的业务。
数据库单元化设计
- 客户核心系统按照「用户编号」维度对数据分片。将全量数据按照1%的粒度划分成100个数据分片，即按照「用户编号」ID 末 2 位作为标识（00-99）。
- 按「用户编号」为主体划分 5 个单元化集群，每个集群 20 个租户，总共百租户/百库/百表 ,每个租户对应一套分片库/表；1 个全局化集群，存放非单元化公共信息。划分5个单元化集群最大好处就是当数据库出现极端故障时，损失了一个单元化集群的能力，只影响 20% 的用户，整体影响面可控。
- 每个集群 5 个zone（即5个副本） , 主副本根据单元化访问需求分配到主机房和备机房的 4 个zone上，第三机房不承担业务流量，机房之间网络延时在 2ms 以内。
- 由于分布式多副本数据一致性协议要将每一个事务的数据强同步到多数派副本中，这种部署模式下必然导致频繁的跨机房同步操作。为了保证数据库的写性能，对机房之间的网络质量有比较高的要求，通常要求任何两个机房之间的网络时延不超过2毫秒（ms）。
- 数据库内部没有跨zone/跨节点的分布式事务，所有分布式事务需求在应用单元内部解决，通过“本地消息表”，补偿机制达到最终一致性；
你可能会疑惑，OceanBase集群标准部署是同城三机房三副本，而这个项目为什么要使用同城三机房五副本呢？原因是这样的：虽然业务上规划了第一机房和第二机房两个机房，但是客户要求以稳为主，核心系统对时延要求很高。同城机房基本也不允许跨机房访问。因此，为了避免OceanBase集群第一机房宕机，而导致leader切主到第二机房，我们在第一和第二两个机房各部署了2个副本。另外，三机房五副本等部署方式，可以在同一时间容忍2台observer 机器出现异常，为业务提供了更高的安全性和可靠性。
图3 OceanBase数据库单元化架构
单元化数据统一访问
客户核心系统通过 SOFA ODP 分库分表中间件/OBProxy 代理提供的统一入口来访问 OceanBase 数据库单元化集群，它屏蔽了分库分表、多集群及OBServer分布式的复杂性，将 SQL 语句路由到该应用单元对应的 Leader 副本上， 对用户使用完全透明；不过需要特别注意的点是，通过「用户编号」分片后，所有 SQL 必须通过带“分片键”进行数据操作，否则全表扫描 SLB 和 ODP 会被打爆。每个单元会拆分一个SLB（负载均衡服务）实例挂载ODP，ODP后对应后面的所有的OBserver。
图4 ODP单元化架构设计
这边重点讲下部署架构，客户核心系统对性能有非常高的要求，在上云过程中经历了几次演进。一次从 ODP 和 OBProxy 分开部署演进到 2 个进程合并一起部署到容器，主要解决网络多一跳耗时和快速弹性扩容问题，并且后续会往 OBSharding 单个C程序演进，解决性能问题。另一次，从一个 SLB 实例挂载后端所有 ODP 实例拆分成每个单元对应一个 ODP SLB ，解决的问题是：1） 在大流量情况下，单个 SLB 流量容易被打满；2）由于应用长连接原因，会导致负载不均，这样对某个 ODP 造成非常大压力，甚至出现 JAVA FullGC；3）某个 ODP SLB出现故障时，不会影响其它单元，符合单元化设计思想。
分布式数据库OceanBase部署与容灾
同城单机房到三机房改造
按照整体设计，我们在主城市规划了三个机房，但是每个机房采购及部署到位时间是不一致的。为了不影响应用上线计划，在第一机房主机房机器ready后，我们就开始部署OceanBase集群。首先部署好第一机房单机房三副本集群，提供给客户进行测试验证，同时等待第二和第三机房机器到位，待机器ready后，我们通过OceanBase特有的增减副本以及副本类型在线转换的功能，实现数据的平滑搬迁，最终实现同城单机房三副本到同城三机房五副本的架构转化，整个过程对应用透明，应用无感知，充分体现了OceanBase 强大的弹性伸缩能力。
图5 OceanBase三机房调整-1
图6 OceanBase三机房调整-2
图7 OceanBase三机房调整-3
OceanBase主备集群方案
传统IT系统高可用的实现主要是以主备的方式。这种方案目前有非常广泛的应用，由于经历了时间的验证，行业的认可度比较高。主备双机也可以作为容灾的一种选择。目前运行的很多系统，其容灾方案是以主备的方式构建的。虽然OceanBase通过其多副本特性完美解决了容灾的方案，对于重要度极高的系统，仍需要规避整个集群出现不可预知的故障时，导致服务不可用的情况。因此，OceanBase也提供了与传统构架类似的复制功能，利用REDO日志，使主集群和备集群实现数据同步。在极端情况下，如当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务。备库提供最大可用、最大性能、最大保护三种保护模式，可以根据实际情况选择，最大限度降低服务停机时间。
Oceanbase 主备集群三种保护模式
- 最大性（Maximum Performance）。这是默认的保护模式。它在最大限度地确保主集群性能的同时，还能保护用户的数据。在这种保护模式下事务只需等REDO日志在主集群持久化成功就可以立即提交。REDO日志会异步的同步到备集群，但是不会阻塞主集群事务提交。因此，主集群群的性能不会受备集群的同步延时影响。
- 最大保护（Maximum Protection）。这种保护模式提供了最高级别的数据保护，可以确保主集群出现故障时不会发生数据丢失。在这种保护模式下，事务需要等REDO日志在主集群和强同步的备集群上都持久化成功才能提交。最大保护模式下只支持配置一个强同步的备群，其它备集群只能处于异步同步模式。如果强同步的备集群不可用，主集群会停止写服务。
- 最大可用（Maximum Availability）。这种保护模式在不牺牲集群可用性的前提下提供了最高级别的数据保护。默认情况下，事务要等REDO日志在主集群和强同步的备集群上都持久化成功才能提交。当感知到强同步的备集群出现故障时，主集群不再等日志强同步成功，和最大性能一样优先恢复主集群服务，保证集群可用性。直到强同步的备集群恢复服务，主集群会自动恢复为强同步模式，提供最高级别的数据保护。最大可用模式下只支持配置一个强同步的备集群，和其他备群只能处于异步同步模式。
OceanBase异地部署方案
金融行业对业务连续性及对IT风险的应急要求非常高，容灾体系建设至关重要。对A类核心系统，既要能够满足同城双活，又要具备异地灾备的能力。为了满足客户异地容灾需求，我们在异地灾备机房搭建了一套异地备集群，采用OceanBase 主备集群架构，并借助首次发布的OCP管控主备集群版本进行快速跨城部署，实现了异地容灾切换时间跨越式提升（从小时级提升至分钟级），切换方式由原来的黑屏切换转换成白屏切换，极大地提高了应急切换的响应时间、安全性和便捷性。
图8 OceanBase 异地容灾部署
容灾测试演练
因为客户是第一次在核心系统上使用OceanBase分布式数据库，对稳定性和安全性提出了非常严格的要求，要求我们对全场景进行容灾演练，通过业务容灾演练满足核心A类业务投产要求。为此我们不仅在架构上设计了主城市同城三机房五副本的高可用架构，我们也和应用一起编写了详细的测试案例，来检测我们的高可用方案。通过验证我们在主城市2个副本同时宕机的情况下，完全可以做到RPO=0，RTO<30s，赢得客户信任，提升了客户面对灾难时能切敢切的信心。
图9 OceanBase容灾测试案例
核心系统割接整体迁移方案
客户核心系统整体上采用停写迁移的方式进行数据移植，整个迁移过程中，数据从大机导出，要先导入临时库表，通过联表查询导入目标库，涉及多次数据导入导出。经过前期精心的设计准备，以及多轮生产环境移植演练，迁移时间控制在小时级别。同时为了稳定期间，客户分三个阶段进行白名单切流迁移验证，每个阶段，都会进行数据对账和业务逻辑验证，以保证数据和业务的正确性。
图10 核心系统割接整体迁移方案
价值
- 客户收益：核心系统从大机下移，节省大量软硬件费用，并获得远超大机的水平扩展能力，得益于OceanBase的动态扩缩容能力，从容应对大促业务峰值，借助Paxos多副本+主备库架构提供媲美大机的高可用性。
- 技术提升：成功实现客户核心系统数据库从集中式向分布式架构的转变，满足7x24小时持续服务，高可用容灾达到5级，通过“同城双活+异地灾备”的两地三中心架构，确保核心业务RPO为0。
- 能力沉淀：设计出一套针对大行核心系统的分布式数据库单元化架构及标准部署方案，同时满足同城和异地容灾需求，并形成核心产品的最佳实践，为业务未来发展提供了有力技术保障。
- 新的篇章：阿里云首个国有大行核心IBM大机下移的系统，全栈阿里云技术，专有云 + 分布式数据库 + 分布式微服务单元化业务改造，证明阿里云平台是能够承载银行的核心系统，具有绝对标杆和示范效应。