解决方案架构师郭援非:OceanBase助力金融ECIF“大机下移”分布式

简介: 随着“以客户为中心”逐渐成为金融业的战略重心,整合企业各系统分散客户信息的ECIF(Enterprise Customer Information Facility,企业级客户整合系统)应运而生。ECIF 通过整合企业现有业务系统中的所有客户信息,实时保留客户的最新信息,为各应用系统以联机交易的方式提供实时的、完整的、共享的、一致的客户信息,建立起企业级的客户信息识别系统,在全企业范围内为客户信息的使用和管理提供服务,已成为金融业“以客户为中心”的战略性基础系统。

image.png

全渠道业务发展与集中式先进性不足的矛盾


过去,ECIF 通常采用集中式架构。随着国民经济发展以及金融业务渠道创新,ECIF 在数据量和业务量呈现持续增长的趋势,集中式数据库由于采用 Shared Disk 架构,在扩展性上存在先天不足,无法为业务有效提供数据容量和处理能力的扩展。


业务快速迭代与分库分表改造成本的矛盾


随着数据量爆发式增长、数据类型愈发多样化,以及互联网营销下的高并发场景频现等,ECIF 传统架构面临着众多新挑战。为在短期内有效应对这些挑战,分库分表架构逐渐被应用。


分库分表架构虽然可以解决数据水平扩展的问题,但带来对应用系统的改造要求,以及运维上的高成本。业务方无法聚焦在业务发展与快速创新,而是要花费大量精力重构应用来支持分库分表架构。


分布式趋势与“都想要”的矛盾


业务发展呼唤采用分布式架构数据库,但在具体选型中,决策者往往对传统集中式与分库分表两种架构的优点都难以割舍。


一方面,传统集中式数据库不需要因为分库分表而对应用做侵入性修改;另一方面,分库分表数据库在处理能力和数据量方面可以提供很好的扩展能力,能够更好地支持业务发展。那么,有没有一种数据库,可以把两者的优点兼顾呢?

image.png

数字化转型进入“深水区”,金融业需要建设能满足未来长远发展的 ECIF 架构。作为战略性基础系统,ECIF 除了需要满足高可用容灾、高性能处理、数据强一致等基本需求,还需考虑高水平扩展、应用高透明、运维高透明、高兼容性等附加需求,确保 ECIF 能高效提供完整、真实、及时的客户数据源。

image.png

高可用容灾


ECIF 整合了企业现有业务系统中的所有客户信息,对业务连续性有很高的要求。支撑 ECIF 的数据库在部署架构上需要支持 RPO=0,RTO<30s。


分布式架构下的高可用容灾,相当于把数据副本分散到多个篮子,若其中一个篮子出现问题,并不影响其他数据。实施分布式架构必须满足故障自动发现与隔离、单节点故障自愈、支持业务无中断升级、支持多版本灰度发布等能力。


OceanBase 提供丰富多样的高可用容灾能力,包括双机房主备模式、三机房多活、两地三中心、三地五中心等。所有参与灾备的服务器处于同一个数据库集群, 集群的分布式事务会自动调度事务提交,保证事务强一致,保障 RPO=0;当集群中少数机器失败,集群服务会自动做服务切换,不需要手工介入,保障 RTO<30s。


高性能处理


作为战略性基础系统,ECIF 被其他许多业务所依赖调用,对数据库的性能表现,特别是在高并发场景下的快速响应时间有很高的要求。


OceanBase 作为完全自研的原生分布式数据库,凭借众多技术创新,性能表现卓越,在被誉为“数据库世界杯”的 TPC-C 和 TPC-H 测试上都刷新了世界纪录。OceanBase 为 ECIF 系统提供优越的联机事务处理与分析查询性能。特别的,对于 ECIF 系统交易响应时间,OceanBase 可以提供与传统集中式数据库持平甚至更短的响应时间。


高水平扩展


随着银行渠道的多元以及国民经济发展,ECIF 架构需要具备高水平扩展的能力,稳定支撑客户数据的增长。


传统集中式数据库集群不支持动态扩展和收缩,需根据业务发展提前规划系统容量。OceanBase 支持 ECIF 的数据容量与处理能力相应地扩展,使用普通的 PC 服务器即可构建超高吞吐的集群,无需分库分表,可任意按需扩展。


应用高透明

为把主要精力聚集在业务高质量发展上,ECIF 系统要求分布式数据库可以提供对应用的高透明性,最好能做到“原来单机数据库怎么用,现在分布式数据库就怎么用”。


作为原生分布式数据库,OceanBase 为确保应用的高透明,提供了一系列稳定可靠的技术,包括全局一致性快照、全局索引、自动事务两阶段提交、二级分区等,有效保证 ECIF 业务应用逻辑不必因为引入分布式数据库而大量修改。

image.png

某国有银行的 ECIF 承载着全球数亿用户的基础信息,属于核心基础服务,每天的业务交易笔数极其庞大。原先采用的集中式数据库,不仅成本昂贵,而且无法满足业务的快速发展。


OceanBase 为该国有银行的 ECIF 提供同城三机房五副本加主备库的部署模式,实现了机房级多活,以及机房级容灾与城市级容灾能力。

image.png

借助 OceanBase,该国有银行的 ECIF 最终实现从集中式下移分布式架构,交易平均响应时间达到毫秒级,强有力地支撑业务持续创新,大幅节省软硬件、 服务、开发等成本。


某城商行ECIF分布式全栈国产化


某城商行的数字化一直走在同行前列,线上业务量每年基本都有一倍的增长。ECIF 是该城商行面向客户服务的重要基础系统,是其整体IT规划中的重要一环。为支撑未来稳步增长,该城商行要求全行客户信息具备唯一性、正确性和时效性。


该城商行 ECIF 的分布式升级,采用国产芯片服务器和国产原生分布式数据库 OceanBase,验证了全栈国产化分布式系统在功能、性能、稳定性等方面的能力。完全自主研发的 OceanBase,不基于任何开源数据库技术,有效降低安全风险和供应风险。

image.png


OceanBase 为该城商行的 ECIF 提供同城三机房五副本的部署方式,基于 Paxos 分布式一致性协议,实现少数服务器节点或网络故障后的无损容灾和同城多活,做到 RPO=0,RTO<30s。

image.png


OceanBase 分布式数据库助力某国有银行和某城商行 ECIF 的分布式升级,是 OceanBase 深入金融行业内部的实践缩影。OceanBase 兼顾分布式架构的扩展性与集中式架构的应用透明优势,用一套引擎同时支持 TP 和 AP 的混合负载,具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准和主流关系数据库、对应用透明,高性价比等特点,目前已助力全国 1/4 的头部金融客户完成分布式改造,未来也将持续点对点优化解决方案,敬请期待。

相关文章
|
4月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
871 3
|
8月前
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
312 5
|
3月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的&quot;神经网络&quot;,强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
11月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
780 8
|
7月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2579 57
|
9月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
376 14
文生图架构设计原来如此简单之分布式服务
|
7月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
401 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
9月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
846 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
9月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。
|
11月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
1201 41

热门文章

最新文章

推荐镜像

更多