某银行权益类系统基于“业务容器化+数据库多租户”架构实现Oracle信创替换并建设同城双活实践分享

科技   2024-11-06 07:35   海南  

【摘要】本文介绍了某银行权益类系统如何基于信创数据库、信创虚拟化、信创容器云、全闪SAN存储等技术实现Oracle替换。在面临性能、可用性和可扩展性挑战的背景下,该系统通过迁移至信创容器云服务、采用TDSQL分布式数据库等措施实现了全面升级优化。通过基于专业存储的存算分离架构, 微服务架构、多副本部署、灵活的流量切换方案以及高可用部署方案,系统提升了性能、容灾能力和服务能力。同时,文中还介绍了Oracle迁移到TDSQL的工具和方法,以及系统升级改造的挑战和解决方案。这些举措将有助于提高系统的稳定性和可靠性,推动银行业务的数字化发展。

【作者】一树,某股份制商业银行技术经理,负责IT基础平台建设和维护工作。专注于容器云、微服务、DevOps、数据库、信创等领域的探索和研究。

一、背景说明

在银行业数字化发展的浪潮和金融信息系统自主可控的要求下,我行积极推动金融科技布局,努力推进全业务流程信创适配改造工作。在此背景下,我们于2022年开始实施该权益类系统信创升级改造工作,由于该系统承载大量客户的权益账户信息,每天进行较为复杂的批量处理任务,同时对外提供大量的API服务调用。这就需要在系统上线过程中能够较为平滑切换到信创技术栈架构,并在日常的运行过程中,能够具有高并发的处理能力,并在发生故障或灾难情况下能够通过自动切换方案,尽量减少业务影响,保障业务稳定高效开展。


二、系统原架构和痛点分析

该系统原基于Intel X86非信创虚拟机进行部署,数据库采用Oracle Data Guard(DG)架构,未采用分库分表的策略,操作系统为RHEL,应用为行内开发平台的单体架构,且数据库和应用均只部署在一个机房中。这导致系统在后期的业务经营发展中面临较大的性能、可用性以及可扩展性的挑战。

随着业务的扩展和账户数据量的不断增加,数据库的负载逐渐加重。这种集中式存储方式会导致数据库的I/O性能和处理能力容易达到一定瓶颈,随着业务的快速发展与扩展,系统交易量提升,业务数据膨胀,进而引发一系列性能问题。如实时查询速度明显减缓,批量处理时间显著延长,系统在进行大规模数据处理时效率低下,可能会导致批量数据产出延迟,通过增加系统资源也并没有较好的性能表现。

另外由于数据库和应用程序均部署在同一机房内,这种方式带来了单点故障风险。一旦机房内的硬件设备出现严重故障,或者网络出现问题,整个系统可能会立即停摆,导致系统整体不可用。这种情况对业务运营带来严重的影响,甚至可能导致数据丢失和业务中断。

当迫于上述二者的压力,需要对系统进行扩容时,该系统架构下扩容方案复杂、成本较高。

为了解决上述问题,结合信创要求,我们计划对系统进行全面升级优化。首先,将非信创虚拟机迁移至基于ARM架构信创容器云服务中,以应对高并发和大规模数据处理的需求,实现资源快速横向和纵向扩容,同时可以提升其灾难恢复能力。其次,通过多种数据库选型评估,采用TDSQL分布式数据库进行改造。通过借助TDSQL分布式能力,降低单一数据库的负载压力。采用多活数据中心部署,实现数据库及应用的跨机房容灾备份,降低单点故障风险。以上两个系统组件均可实现资源自由伸缩,简化应对系统扩容时方案的复杂度,减少技术性扩容操作对系统业务的影响。此外,新系统建设中也引入缓存、消息队列、Flink技术,提高了实时查询速度,优化批量处理能力。通过这些改进措施,实现提升系统的性能、稳定性和可靠性,为用户带来更好的体验的目标。


三、容灾方案架构图

TDSQL数据库容灾架构,见章节TDSQL部署架构图及高可用方案及性能优化实践。

四、容灾流量切换方案

健康探测是流量切换的主要抓手。

DNS和F5均提供了灵活的探测策略和流量分发策略,可根据项目具体需要进行评估选择,其中探活策略有IP层探活、端口层探活、自定义应用级探活等。流量分发策略有热备、百分比配置(如两个解析目标地址流量配置为1:1,则解析目标地址均存活时,流量按1:1向两个解析目标地址分发,当某个解析目标地址不存活时,流量解析到其他存活的目标地址)等。我们在DNS上配置了到云应用和TDSQL数据库在F5上IP的到端口级别的探活,在F5上配置了到应用和数据库PROXY的探活。当F5到应用的探活失败时,DNS到F5的探活亦失败,此时流量发生切换。同时,在不同地理位置部署DNS 服务器,确保 DNS 服务在任何单点故障的情况下仍能正常运行。

云内应用的流量控制由Ingress、Service控制,策略可自定义,通常为轮询,将请求均匀分发给多个Pods。微服务多副本以及注册中心等保证应用集群可用性,避免任一应用节点故障带来应用使用影响。

F5到数据库的探活作用在TDSQL分布式数据库PROXY上,可保证当A机房数据库PROXY故障或A机房故障时,域名可解析至B机房。无论A机房数据库PROXY、B机房数据库PROXY连接的都是TDSQL数据库的主节点。数据库层面的更具体的高可用方案详情见第六章节TDSQL部署架构图及高可用方案及性能优化实践。


五、应用的高可用部署方案

系统应用采用微服务的架构,将原单体架构应用程序根据业务模块拆分成多个独立部署、相互解耦、相互隔离的进程。应用的微服务均采用多个副本的方式部署在不同数据中心的容器云中。这种架构中,不论是机房级故障或灾难,还是容器云集群级故障或灾难,亦或是应用的单个多个副本的重启或停机,均不会对整个系统层面造成较大影响。因系统同时面临着较多的批量处理任务,需要对文件同样纳入故障或灾难的考虑范畴中,通过自研程序实现文件向两个机房的同步双向写,以达到任何一个机房出现问题,其他机房均可第一时间具备相应的文件数据,通过自动重试机制保障批量处理任务能够自主进行后续步骤处理。


六、TDSQL部署架构图及高可用方案及性能优化实践

在当今数字化转型浪潮中,数据库作为支撑业务运行的核心基础设施,其架构设计显得尤为重要。TDSQL作为一款高性能、高可用、可扩展的分布式数据库系统,其架构设计遵循了分布式和存储计算分离的设计理念,主要由计算节点(proxy)+存储节点(DB)+管理调度节点(zookeeper等)等组成。

核心的架构设计如上图所示:计算节点Proxy负责SQL解析、转写、分发、鉴权、结果聚合、结果过滤和读写分离等功能,在主数据中心和同城数据中心分别安排了两台Proxy组成集群,Proxy集群内节点无状态,作为接入层对外提供计算能力;存储节点DB负责数据的存储和管理,主数据中心和同城数据中心的多台DB服务器共同组成数据库资源池;调度节点zookeeper负责集群的高一致和可用性管理,采用“2+2+1”架构,即主数据中心2台+同城数据中心2台+灾备数据中心1台(仲裁),确保在单机房故障情况下Tdsql集群仍能正常工作;另有scheduler/manager负责资源调度,chitu/oss提供页面和接口服务,旁路模块nfs负责备份,DBbridge负责数据迁移等。

下图为基础架构图,在采用存算分离理念的架构设计中,Proxy、DB、Zookeeper等服务器的部署可以更加灵活地配置,以实现计算资源与存储资源的独立管理和优化。其总体架构分为计算资源层和存储资源层。

计算资源层使用物理服务器作为计算节点,采用FusionCompute集群作为虚拟化计算资源的统一管理平台,承载Proxy、Zookeeper等服务器的虚拟机实例,DB节点则直接部署在物理服务器上。在存储资源层,采用华为OceanStor Dorado 全闪SAN存储系统作为独立的存储资源,为所有需要持久化存储的服务(包括虚拟机镜像、数据库数据等)提供高性能、高可靠的存储服务。存储资源与计算资源完全解耦,通过网络连接进行数据的读写操作,实现计算资源和存储资源的独立优化和高效利用提高了系统的灵活性、可扩展性。

在该架构模式下,TDSQL集群展现出了卓越的容错和容灾能力。该架构的核心在于设计了模块间的独立性与冗余机制,确保在模块级别出现突发故障时TDSQL集群的平稳运行,几乎不会对其对外提供服务的能力造成实质性影响;更进一步,该架构设计还考虑了更为极端的情况,即机房级别的故障容灾,即在面临如供电异常、自然灾害等导致整个机房故障的情况下,TDSQL集群依然能够迅速且自动地切换至正常机房,以保证对外服务的连续性和稳定性,进一步提升了集群的可靠性和用户体验。

接下来,我们将一一介绍该架构是如何实现上述的容错与容灾能力的:

1.计算节点故障:Proxy作为无状态的接入层组件,任何一台Proxy服务器都能独立地对外提供计算服务,无需依赖特定状态信息。为了增强系统的可靠性和容错能力,每个机房均配置了两台Proxy服务器,并通过F5负载均衡器进行流量分发。某一机房单台proxy发生故障时,通过F5探活,可很快将故障Proxy踢出;多台Proxy服务器故障时,业务系统也可通过网络设备连接至仍存活的Proxy,最高可支持3台proxy故障;当某一机房内的单台Proxy服务器发生故障时,被F5负载均衡器健康检查机制检测到,F5会迅速将该故障的Proxy服务器从服务列表中移除,确保用户请求被自动转发至其他健康的Proxy服务器,从而实现无缝的故障转移,最小化对业务连续性的影响;在极端情况下,若多个Proxy服务器同时发生故障,业务系统能够识别并连接到尚存活的Proxy服务器,继续提供服务,此机制支持最多三台Proxy服务器同时故障而不影响整体服务的可用性。

2.存储节点故障:数据库DB实例采用了一主三备架构,以确保数据的可靠性和服务的连续性。具体而言,主实例与跨数据中心的一个备实例间采用强同步复制技术,与同数据中心的备实例和跨数据中心的另一个备实例之间则采用异步复制技术。当单台DB服务器发生故障时,若其上只运行有备实例,则由于备实例基本不参与对外服务,对整体服务无影响;若其上运行有主实例,则由Zookeeper根据数据一致性第一原则和同IDC备实例优先切换原则自动从剩余的备实例中选举出新的主实例,更新路由表并告知所有的Proxy服务器,这样Proxy服务器就能根据新的路由信息将请求转发至新的主实例,确保数据的一致性和服务的快速恢复,整个故障检测、主备切换和路由更新过程中,RPO=0,RTO<40s。

3.调度节点故障:Zookeeper集群任一Follow节点故障,不影响Zookeeper集群的仲裁决策能力;Leader节点发生故障,则触发Zookeeper集群自动选举机制,由至少三个节点重新选举出新的Leader节点;确保Zookeeper集群在面对故障时能够迅速恢复并继续稳定运行。

4.其他模块故障:其他模块故障不影响业务可用性。

5.机房级故障:以主数据中心故障为例,在主机房全面故障的情况下,由同城数据中心的两台Zookeeper节点和灾备数据中心的Zookeeper节点共同参与,通过选举算法选举出新的Leader节点,确保集群的元数据管理和服务协调功能迅速恢复;然后同城数据中心的备实例在Zookeeper Leader节点主持下依据预设原则选举出新的主实例,已有的主实例保持不变;主实例选举完成后,Zookeeper集群更新路由表并告知所有存活的Proxy,Proxy服务器根据新的路由信息将请求转发至新的主实例;至此整个数据中心的切换完成,RPO=0,RTO<40s,确保了数据库服务的高可用性和连续性。

之所以在 TDSQL 上采用数据库+SAN 存储的架构,有诸多优势。在可靠性方面,这种架构能通过 SAN 存储的冗余设计和数据库自身的备份恢复机制,有效降低数据丢失风险。高可用性上,即使数据库节点或 SAN 存储链路出现故障,可迅速切换,保障业务连续性。资源利用率也得以提升,SAN 存储可灵活分配存储资源给数据库,避免资源浪费。对于故障盘,SAN 存储有成熟的管理系统,能快速定位和处理故障盘,同时数据库能配合调整存储策略,减少对业务的影响,运维也更加便捷,有统一的管理界面和流程来处理存储和数据库相关问题。另外,通过多轮的压力测试,该方案也能满足系统的性能要求。


七、Oracle迁移到TDSQL的工具和方法

Oracle数据到TDSQL的迁移有多种方式,我们主要评估了使用文件形式数据卸载装载和使用KETTLE工具这两个方式。评估的着眼点在于,1.海量业务,2.业务连续性,3.对运行生产系统的影响。基于这三点,我们最终选择了KETTLE工具进行数据迁移。

迁移分为存量迁移和增量迁移两部分。存量迁移:定义某个时间点前的业务数据,如2024年9月30日(含)前的业务数据进行迁移;增量迁移:存量时间后的业务数据和数据量较小的系统表。存量迁移可以是个长期的过程,比如系统切换前一天或者一周,持续进行。增量迁移是在存量迁移完成后,系统切换停机时短时间内执行完成。

在KETTLE工具中,可自定义执行任务,通过控制任务分段大小,控制任务执行时间,减少读操作对源系统的影响,减少写对目标数据库的影响。

在迁移设工作第一步,一定要首先确定系统分布键,通常一个系统使用一个分布键,该分布键为所有业务表(大表)均持有的字段。以客户为核心展开的系统,建议以客户号或内部客户号作为分布键(分布键位数值类型,如客户号为非数值类型则考虑新建内部客户号)。在确定了这张映射表后,后续参与迁移的表与该表关联,获取分布键。这样就确保了具有业务相关性的数据落在一个数据分片内,保证批量业务处理或联机交易处理,涉及数据库层面表关联时,具有良好的性能。这也是系统程序设计开发中必须要遵守的约定。


八、总结

本次系统升级是一个较为复杂的工程,综合应用了云计算、大数据、信创技术以及分布式技术等多种技术栈。前后也经历了很多挫折,通过项目组专家和同事的共同努力,逐个进行技术验证,问题分析,最终实现系统顺利上线运行。本次的系统升级改造,很好提升了系统性能、容灾能力和服务能力,有助于大幅提升相关业务的竞争力,推动我行技术创新发展,在符合国家信创要求的同时也为未来的发展奠定坚实基础。

参与协同同行专家:

万里鹏 -某银行单位

于洋-某银行单位

王新宇-某银行单位

吴盛哲-某银行单位

阳文灿-某银行单位

黄庆-某金融单位

专业审核:

董生 某大型银行 数据库架构师

如有任何问题,可点击文末阅读原文,到社区原文下评论交流

觉得本文有用,请转发或点击在看,让更多同行看到


 资料/文章推荐:


欢迎关注社区以下  “数据库”技术主题 ,将会不断更新优质资料、文章。地址:https://www.talkwithtrend.com/Topic/597

下载 twt 社区客户端 APP


长按识别二维码即可下载

或到应用商店搜索“twt”


长按二维码关注公众号

*本公众号所发布内容仅代表作者观点,不代表社区立场

twt企业IT社区
talkwithtrend.com社区(即twt社区)官方公众号,持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群,让您时刻和国内企业IT同行保持信息同步。
 最新文章