购物车
我要投稿
版权投诉
2025-2030年中国食品级芦荟提取物市场专题研究及市场
2025-08-11
2025版腾讯云商业银行核心系统分布式转型白皮书
- 2025-07-31 23:20:51上传人：lo**R.
-
Aa 小 中 大
在当下“不断变革、持续创新”的时代里，变革与创新对银行业信息科技的影响是不可忽视的。随着互联网以及移动支付的飞速发展，银行业务持续飞速发展和变革，在过去十几年中，主要经历以下三大转型：一、网点转型：从传统物理网点向“线上云网点”转型，大量必须在现场网点柜台办理的业务，可以通过远程视频银行实现流程闭环
- 式事务协调等问题。
- 多中心多活
- 根据监管要求，银行的关键业务系统需要建设容灾体系以应
- 多不可抗力灾害。实践中，银行通过定期灾备切换演练、将
- 只读交易定向引流至灾备机房运行，或向灾备机房部署可控
- 灰度流量等方式，持续验证容灾体系的有效性与日常可用性。
- 同时，容灾机房还需符合物理距离要求等监管标准。
- 跨地域容灾
- 13 - - 14- 14
- 2.4.4 业务连续性
- “面向弹性容错 ”是分布式系统设计时常被采用的设计思想，
- 即在面对高故障率和不稳定的基础设施时，业务连续性的保障
- 需要从整体性视角考虑， 应用系统为此需要考虑多种故障场
- 景，进而做出故障自隔离、自动扩缩容等自恢复机制。
- 弹性故障恢复
- 应用在分布式下的技术架构包括：交易处理策略、分布式事务处理策略、应用侧扩容策略、聚合查询策略、灰度发布策略。
- 2.4.2 技术架构策略
- 指的是一次交易从网关进入到内部应用集群时，应用集群之
- 间服务调用的机制和故障处理策略。这包括点对点直达调用
- 还是通过消息传递调用，以及相应的负载均衡策略。同时，
- 还包括应用实例故障时的熔断与降级策略等。
- 交易处理策略
- 灰度本质上是希望控制指定流量到指定的集群中处理，多用
- 于验证新版本功能，或验证新的数据库、中间件及基础设施。
- 对资源要能按照标签隔离开，流量也能按照标签进行路由，
- 再集成管控面进行控制管理。
- 灰度发布策略
- 针对分布式集群中的应用扩容升级，对于运行在云平台上的
- 核心应用，可以通过实现无状态的应用实例来支持自动扩缩
- 容；对于运行在传统 IDC 内的核心应用，可通过手工脚本方
- 式实现应用实例的扩缩容。就银行核心场景而言，指定统一的、
- 标准的扩容模式，对于银行核心系统的稳定运行非常重要。
- 应用侧扩容策略
- 为配合新核心的建设，需要一套行之有效的研效体系支撑，才能发挥分布式系统敏捷、自治的特性。除了传统DevOps需要具备的集成、
- 反馈等自动化能力之外，还需要以项目视角，从需求出发到设计，再到研发、测试、发布三个关键环节，打通各环节数据和管控面，形成
- 一体化的持续跟踪、反馈、提升体系。除了工具层面，更应在文化、分享、度量、自动化、精益管理等多个维度进行对标和增强，实现动
- 静结合、双速开发等全链路的效能提升。
- 2.4.5 研发效能
- 2.4.3 服务模型策略
- 微服务的颗粒度是业内经常争议的话题。若颗粒度过大，将
- 无法充分体现微服务的低耦合与自治性；若颗粒度太细，则
- 可能对性能、稳定性、链路监控和运维产生不良影响，甚至
- 导致大量分布式事务场景的出现。
- 服务粒度
- 指的是采用分布式架构后，带来的事务一致性问题。由于分
- 布式架构下的场景较为复杂，需要决策是由应用侧来保障事
- 务，还是交由分布式数据库来保障。值得注意的是，任何一
- 种事务处理机制都会存在损耗和场景限制。在指定分布式事
- 务策略时，需要结合实际情况进行综合考虑和决策。
- 分布式事务策略
- 数据被切分之后，如何满足聚合查询的要求，需要定制相应
- 的策略。当底层数据被分散到多个数据分片之后，原本在单
- 一数据源上进行的聚合查询需要被下推到多个不同的数据分
- 片上进行。最后再将这些分片的结果传回进行汇总、排序等
- 计算。这个过程中对网络和聚合计算节点的要求非常高。
- 聚合查询策略
- 从应用设计到研发测试上线的整个生命周期，需要具备全方
- 位的实施方法论。其中包括对需求产出的业务组件到微服务
- 组件的映射，流程与实体等业务模型的识别、定义、分解等
- 内容，应用架构的构件定义、组装、发布的端到端方法论。
- 落地工艺
- 在分布式核心系统中，需具备一系列技术组件，用于隔离底
- 层分布式技术复杂度，并对底层技术产品进行隔离。此层需
- 要具备良好的南北向接口，帮助核心系统通过分层隔离来实
- 现自主可控。
- 技术组件
- 为了保证分布式核心系统的运维效率和连续性，需要建设专门的分布式运维平台，并在规划新核心时就一并启动规划。在一些实践中，出
- 现过由于运维平台启动较晚，导致新核心相关设计出现反复的问题。此外，分布式系统的运维与传统主机的方式截然不同，需要从快速修
- 复模式转变为快速隔离，系统需要自发现并隔离故障节点，以保证业务连续性。因此，标准化的指标采集与分析工作，多维度的监控与告
- 警，CMDB和标准化运维动作都需要围绕分布式系统进行重新梳理和设计。最后，在规划时需要考虑大数据和AI故障智能分析与预测的能
- 力，这将是未来分布式运维的发展趋势。
- 结合腾讯参与的多个新核心落地案例与多家客户的调研访谈，围绕着六大设计要点，归纳总结出两种主流技术架构路线：标准微服务架构
- 和单元化技术架构。
- 2.4.6 分布式运维
- 银行机构日益重视核心系统的高可用性。同城双活架构是主
- 流设计，即同一城市的两个机房同时接入并处理业务请求，
- 任一机房故障时，另一机房可秒级接管业务流量。而大型银
- 行机构则规划采用异地多活架构，即在异地多个机房同时响
- 应业务请求。但与互联网业务不同，银行核心业务的异地协
- 同面临特殊挑战，如服务目录异地同步时效性、跨地域分布
- 式事务协调等问题。
- 多中心多活
- 根据监管要求，银行的关键业务系统需要建设容灾体系以应
- 多不可抗力灾害。实践中，银行通过定期灾备切换演练、将
- 只读交易定向引流至灾备机房运行，或向灾备机房部署可控
- 灰度流量等方式，持续验证容灾体系的有效性与日常可用性。
- 同时，容灾机房还需符合物理距离要求等监管标准。
- 跨地域容灾
- 13 - - 14- 14
- 客户如何选择3.2
- 标准微服务方案中，技术能力更多采用产品来实现，在技术路线选择上没有单元化方案丰富。但由于方案成熟度高，建设难度和成本都相
- 对较低，建设过程中更多关注业务和应用架构的设计，比较适合体量一般的银行。
- 单元化方案中，技术能力多采用自研+产品标准能力实现，更关注自主可控，尽可能不去依赖产品自身能力，避免绑定。建设难度和成本
- 都相对更高，更适合体量较大的银行，以及有多活架构规划或追求同业架构先进性的银行。
- 单元化是微服务架构的强化，两者在核心六大设计要点上存在一些差异，主要集中在数据切分、扩容与路由、交易处理机制、灰度实现机
- 制等能力的实现方式。
- 我们将分别对标准微服务架构和单元化架构路线的关键设计点进行介绍。
- 本节主要从核心应用厂商的视角，介绍业界较为常见的核心系统微服务架构。
- 微服务架构可以带来像应用解耦、独立自治等诸多优势，但正如上一章提到的，微服务并没有解决所有问题。如服务拆分后的服务编排问
- 题、分布式事务问题，或者数据拆分后的聚合查询问题等。在银行核心如此严谨的领域，微服务的使用一定要综合考虑各种场景，充分听
- 取多方意见，从中找到平衡点。如果一味从理论角度推进，往往得不偿失。
- 考虑到微服务颗粒过细所带来的整体复杂度，通常在设计时会按照标准的业务领域进行组件的设计和开发，但在发布时会将多个相关的组
- 件进行合并发布。以此来减少组件间的调用链路，提供系统稳定性和性能，简化运维复杂度，包括减少分布式事务的产生。
- 举例：通常核心会被拆为账务、公共、历史3类微服务群，不同厂商的微服务领域划分会略有不同，结合行内核心系统现状后也会有所
- 调整。
- 腾讯云分布式核心
- —标准微服务架构路线3.3
- 3.3.1 腾讯云银行核心标准微服务架构
- 目标方案
- 标准微服务
- 方案
- 数据切分策略 技术架构标准 微服务实现策略 业务连续性 研发效能 分布式运维
- 以应用软件包内置
- 领域为服务颗粒度
- 应用软件包内置的
- 技术组件
- 应用厂商的交付
- 实施工艺
- 同城双活+异地灾备
- 两地三中心
- 持续集成与发布
- 快速反馈与迭代
- 双速开发+自动测试
- 过程可视化+
- 精益管理
- 标准化指标采集
- 大数据分析告警
- 可视化+自动化
- 配置与流程管理
- 实例级故障自恢复
- 中心级故障告警+
- 人工决策切换
- 地域级故障告警+
- 人工决策切换
- 客户号哈希
- 分布式分片架构
- 纯数据库扩容
- 业务/公共/历史
- 客户号自定义路由
- 独立分片架构
- 自定义扩容
- 业务/公共/历史
- 单元内随机负载
- 自定义就近调用
- 应用处理分布式事务
- 全局路由+微服务平台
- 实现灰度单元
- 以业务建模产出
- 为服务颗粒度
- 咨询公司的
- IT实施工艺
- 以外购+自研的
- 形式形成技术组件
- 近期：两地三中心
- 远期：异地多中心
- 实例级故障自恢复
- 单元级故障自恢复
- 中心级故障告警+
- 人工决策切换
- 地域级故障告警+
- 人工决策切换
- 持续集成与发布
- 快速反馈与迭代
- 双速开发+自动测试
- 过程可视化+
- 精益管理
- 标准化指标采集
- 大数据分析告警
- 可视化+自动化
- 配置与流程管理
- 单元化运维管理
- 机房内随机负载
- 优先同机房调用
- 应用+数据库处理
- 分布式事务
- 数据库处理聚合查询
- 微服务平台
- 实现灰度发布
- 单元化方案
- 主要包含银行核心业务所涉及的账
- 务服务模块，如：存款、贷款、卡
- 业务、支付结算、客户凭证、库存
- 现金与凭证管理等。
- 账务微服务群
- 主要包含支持核心业务所需要的公
- 共服务模块，如：机构、柜员、利
- 率、费率模块等，以及像产品中
- 心、客户中心、定价中心等能力中
- 心服务。
- 公共微服务群
- 主要包含历史查询业务所需的相关
- 服务。
- 历史微服务群
- 微服务层
- 数据库层
- 外部请求 [->服务网关接入]
- 服务注册 服务发布 服务删除 服务限流 熔断降级
- 历史微
- 服务群
- 公共微服务群 账务微服务群
- 机 构 柜 员
- 利 率 模 型 汇 率 模 型 产 品 目 录
- 存 款 产 品 工 厂
- 卡 产 品 工 厂
- 存 款 业 务
- 借 记 卡 业 务
- 客 户 凭 证 管 理
- 结 算 业 务
- 客 户 信 息 副 本
- 会 计 内 部 户
- 库 存 凭 证库 存 现 金
- 外 围 统 一 接 口历 史 查 询 业 务
- 费 率 模 型 税 率 模 型
- 分布式数据库
- 公共DB 账务DB 账务历史库DB
- 公共用户 账务用户 历史用户
- 同步 同步
- 服务治理中心
- 1817 - 17
- 上一篇餐饮行业产品上新报告（2025年6月）
- 下一篇没有了！
报告网所有机构报告是由用户上传分享，未经用户书面授权，请勿作商用！
