本文由阿里技术专家吉远撰写于 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 多正本 + 主备库架构提供媲美大机的高可用性。
- 技术晋升：胜利实现客户外围零碎数据库从集中式向分布式架构的转变，满足 7 ×24 小时继续服务，高可用容灾达到 5 级，通过“同城双活 + 异地灾备”的两地三核心架构，确保外围业务 RPO 为 0。
- 能力积淀：设计出一套针对大行外围零碎的分布式数据库单元化架构及规范部署计划，同时满足同城和异地容灾需要，并造成外围产品的最佳实际，为业务将来倒退提供了无力技术保障。
- 新的篇章：阿里云首个国有大行外围 IBM 大机下移的零碎，全栈阿里云技术，专有云 + 分布式数据库 + 散布式微服务单元化业务革新，证实阿里云平台是可能承载银行的外围零碎，具备相对标杆和示范效应。