暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 简要概述网商银行云单元架构

简要概述网商银行云单元架构

数据源的技术后花园 2024-07-11
161

云单元架构的特征

云单元架构的核心思想是把数据水平拆分思路向上提升到接入层、终端层。从接入层开始，把原来部署于一个 IDC 的系统集群，进一步分为更细粒度的逻辑部署单元，从而实现机房级扩展。
相隔 100 KM 的机房光纤网络时延大概为 2~3 毫秒，分布式架构下应用和数据库之间的请求频率高，单笔交易的处理往往涉及上百次的交互，会产生几百毫秒的网络时延，导致跨机房服务调用性能很差。
如果通过一定的手段将用户访问服务涉及的所有操作收敛在同一机房内完成，则可以避免跨机房数据访问，从而解决网络时延问题。因此，关键问题就是怎样让所有操作在一个机房内完成。
云单元架构的本质是将系统进行分布式架构改造后，通过部署方式的改进进行逻辑隔离，对单个物理数据中心进行逻辑划分，分成多个逻辑数据中心，它可以将分布于多个城市的数据中心整合起来，基于全局运维管理可以实现跨越多个数据中心的资源调度。
每一个逻辑单元都具备比原来整个机房更小的规模，但拥有完整的业务处理能力，从接入网关到应用服务器再到数据库，每个单元依据规则支撑一定的流量和数据。
分布式架构下的应用分片通常是在数据层维度的，以支撑上层无状态应用的横向扩展。而云单元架构通过把这种分片能力提升到机房流量入口位置，使整体业务处理能力能够通过一个个逻辑单元在数据中心的层级进行横向伸缩，进而实现整体架构的无限可扩展，每个逻辑单元具备以下四个重要特性。
  1. 自包含性。主要指业务功能涉及的服务和数据是单元内自包含的，每个单元都具备完成业务所需要的计算和存储等能力，比如快捷支付交易所涉及的所有计算和数据都会被封闭在一个单元中。
  2. 松耦合性。单元之间只允许进行服务调用，不允许直接访问数据库或其他存储，对于必须跨单元的操作，比如位于两个不同单元之间的用户转账交易，服务调用需尽可能少，同时在不影响用户体验的情况下，尽可能异步化。这样，即便两个单元相距较远，整个系统的响应也不会受跨单元访问导致延迟增加的影响。
  3. 故障独立性。一个单元的故障不会影响其他单元，故障影响不会跨单元扩散。
  4. 容灾性。单元之间相互备份，每个单元都保证在发生同城或异地故障时有可接管服务的单元，单元之间数据备份方式使用底层分布式数据库提供多地多中心多副本的数据一致性方案。

云单元逻辑架构

在云单元架构中，通常将逻辑数据中心（云单元）划分为 3 大类：分区单元、共享单元和全局单元。
  1. 分区单元（Region Zone， 简称 RZone）。部署按用户维度进行拆分的核心业务系统，保证核心业务用户分布在不同的单元内处理。在全行范围内，通过用户维度进行多组拆分，流量按照各组分配的权重比例被分配到各业务单元。银行典型的分区业务单元系统有存款系统、理财系统、账务系统等。
  2. 共享单元（City Zone，简称 CZone）。部署不可拆分的数据和服务，主要是为了解决跨城通信延迟过高的问题，CZone 中的数据或服务会被 RZone 频繁访问，每个城市至少部署一个 CZone 单元。典型的 CZone 系统如配置查询、产品查询系统等。
  3. 全局单元（Global Zone，简称 GZone）。部署未按用户维度进行拆分或非交易主链路的应用，提供不可拆分的数据和服务，主要是一些长尾应用或新用户注册系统，比如业务运营管理系统、运维管理系统等。

单元化流量路由

云单元架构实现的关键环节是如何让用户流量根据一定规则（如用户 ID）分配到指定的单元中进行处理。在微服务架构中，流量类型有多种，比如 HTTP 流量、RPC 流量、消息流量、数据库流量等。确保这些流量能正确流向归属的单元，需要先设计好各单元流量的分配规则，其次对这些流量所依赖的组件进行改造，如服务注册中心、网关及负载均衡设备、消息中心、调度中心等。需要一个 “规则管控中心” 对路由规则进行统一管理及下发，确保各类型流量能同时“感知”到流量规则的变化，实现流量的统一分配。
HTTP 流量实现单元化路由，解决的核心问题是怎么将用户的目标单元对应的服务地址匹配出来，并在发起请求时直接请求到目标单元的服务地址上。一般做法是为每个单元分配一个独立的域名，用户请求时根据所属 Zone 直接请求对应的域名，但这种方法域名变更是非常复杂的事情，且需要客户端“感知”路由规则的变化，改造成本过大。网商银行引入 HTTPDNS 来解决这个问题，本文不做详细描述。
RPC 即远程过程调用，现在有很多成熟的 RPC 框架如阿里的 Dubbo、蚂蚁的 SOFA、Google 的 GRPC 以及大家熟悉的开源产品 Spring Cloud 等。在非单元化场景中，各个机房的流量通常在上层就分配完成，到机房内部以后一般不会再出现跨机房 RPC 调用的情况。单元化架构下 RPC 流量的路由是 RPC 服务框架提供的，涉及单元内服务路由与跨单元服务路由两种场景。
单元化场景中的消息路由与 Kafka 类似也是围绕 Topic 展开，但是除了 Topic 之外还有消费分组、订阅单元属性等核心配置。消费分组和订阅单元属性是单元化架构下消息路由的关键，它们一起决定了消息的路由轨迹。
除了外部与内部之间、应用与应用之间的信息交互路由问题外，还有数据的路由问题。数据的路由问题重点是解决数据库和缓存如何进行单元化处理，下文重点介绍一下数据库单元化路由相关内容。

数据库单元化路由

关系型数据库是存储应用系统核心数据的最常用数据库，单元化架构中的 RZone、CZone、GZone 在数据库的选择和形态上也会有所区别。
GZone 的数据库通常是以单库的形态存在，数据访问通常有一个主节点，各单元只需要获取主库的 Server 地址并建议连接即可。
GZone 数据库单元化路由
CZone 的数据为跟 GZone 类似，通常也是以单库形式存在，但数据的访问是通过与本城市的数据库 Server 建立连接来发起请求的，每个城市通常有相应的数据库副本，主库需要保障数据能准时同步到其他城市的副本中。
CZone 数据库单元化路由
RZone 的应用通过横向扩展（分库分表拆分）来解决数据库连接限制问题，正常情况下，每个 RZone 只跟自己对应的分库建立连接并发起请求。
RZone 数据库单元化路由
每个 RZone 跟数据库的连接关系是一成不变的，在容灾场景中，为了保障经过流量调拨后故障单元的流量可被正常单元接管，通常我们要动态调整每个单元跟各分库建立的连接。比如下图中，容灾切换前，RZM00A 单元的应用只跟 00~29 分库建立连接；容灾切换后，RZM00A 的流量被调拨到 RZM01A，这时数据中间件需要动态调整各应用跟数据库的连接，RZM01A 的应用会跟 00~29 分库逐渐建立起相应的连接。
容灾场景中的数据库单元化路由
注：本文摘要自《金融级 IT 架构-数字银行的云原生架构解密》

云数据库架构数据库系统云系统应用架构
文章转载自数据源的技术后花园，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论