---
title: 国有大行和股份制银行核心系统解决方案 - OceanBase 分布式数据库解决方案
description: OceanBase 目前已覆盖全部政策性银行、5/6 国有大行，以及部分股份制商业银行，助力大型银行核心业务系统升级。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

[首页](https://www.oceanbase.com/zh) [解决方案](https://www.oceanbase.com/zh/solution/home) 国有大行和股份制银行核心系统解决方案

# 国有大行和股份制银行核心系统解决方案

- 容灾能力
- 平衡故障半径与应用侵入性
- 租户级扩缩容

方案咨询 [方案概述](#intro "方案概述") [业务挑战](#background "业务挑战") [方案架构](#arch "方案架构") [方案优势](#benefit "方案优势") [客户案例](#customerCase "客户案例") 方案咨询

## 方案概述

近年来，国有大行与股份制银行的核心系统从大机/小型机下移后，都改变了原有的嵌入式一体化核心应用架构，变成了微服务架构或者微服务与单元化结合的架构，便于构建实现分布式扩展、多机房多活的核心业务系统。OceanBase 目前已覆盖全部政策性银行、5/6 国有大行，以及部分股份制商业银行，助力大型银行核心业务系统升级。  

## 业务挑战

高可用要求极为严格 为了保障业务连续性，国有大行和股份制银行通常要求多活部署，典型部署模式包括两地三中心，甚至是三地五中心，对数据库的架构能力带来极大挑战。 扩展性要求高 应用的单元化拆分，对数据库的扩展性提出更高要求。 性能挑战大 单元化架构复杂性带来性能挑战，要求数据库能高效地处理各种复杂的业务 SQL。 总体拥有成本挑战 尽管国有大行和股份制银行每年的 IT 投入不菲，但是资源并非无限充足，要求在相同的架构设计在尽可能少的硬件上实现，以及硬件数量带来的机房建设成本，包括水电网络等。

## 方案架构

国有大行和股份制银行的核心业务系统，如贷记卡、借记卡、核心渠道等，通常采用下面的单元化架构解决方案，该方案支持多机房多活容灾，能有效控制爆炸半径，同时支持数据库与业务单元联动切换，保证业务连续性。

![方案架构](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*eQ0qSK8mEEYAAAAAAAAAAAAADiGDAQ/original) ![方案架构](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*eQ0qSK8mEEYAAAAAAAAAAAAADiGDAQ/original)

## 方案优势

![](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*JA9OT4hKUBkAAAAAAAAAAAAAARQnAQ)

#### 容灾能力

基于 Paxos 多副本 redo log 物理复制，获得性能和可用性的完美平衡；Paxos 选主，故障自愈，两地三中心架构下保障机房级容灾，RPO = 0。 ![](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*wM1eT4XyYJYAAAAAAAAAAAAAARQnAQ)

#### 平衡故障半径与应用侵入性

基于 OBSharding，分片可落在多个 OceanBase 集群上，降低故障半径，同时应用代码无需感知分片物理源，降低应用侵入性。 ![](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*kmXJSb9QPU0AAAAAAAAAAAAAARQnAQ)

#### 租户级扩缩容

数据库层面支持单元内扩容，各租户动态扩缩容，对业务没有影响，每个租户可以扩展到多个节点，理论上没有上限；百租户百库百表，意味着最多可以扩展到 100 个机房，符合终态设计思维；支持通过增加/减少副本的方式实现机房搬迁，适应机房拓扑变化。

## 客户案例

[![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*whPCRrQD1xoAAAAAAAAAAAAADiGDAQ/original) 国内首个贷记卡核心系统“大机下移”分布式](https://www.oceanbase.com/customer/bankcomm)[AI](https://www.oceanbase.com/obi) 咨询热线