跨数据库进行业务系统追账/测评方法及系统
文献发布时间:2023-06-19 11:26:00
技术领域
本发明涉及银行IT技术领域,尤其涉及一种跨数据库进行业务系统追账/测评方法及系统。
背景技术
在银行系统里,如果评价一种新的数据库是否能在业务系统中使用,需要将业务系统代码移植对接到新的数据库上,然后通过业务人员进行业务测试并对确认结果正确性,并通过选取部分交易进行性能测试,看是否在系统响应时间和吞吐能力上满足业务的需要。在此种情况下,业务系统应用在新数据库上,是通过人工或模拟方式进行的测试,只有业务系统真正上线后,才能反映出在真实业务场景下业务系统对新数据库的适应情况,不能提前运行真实业务场景,因此使用新的数据库进行业务上线存在较多不可控的风险。
对数据库的性能评测,一般都是通过设计SQL语句的操作,重复运行进行测试,以标准SQL单位时间内的运行次数来评估数据库性能的高低。然而,对数据库的评价指标,能反映数据库的性能高低,但不能直观转换为业务系统的评价,例如对数据库的TPCC指标,不能直观转换为业务系统TPS指标,而业务系统的性能评价,是交易响应时间和每秒交易处理数据TPS。
在银行系统中,对业务的追账,一般都是在完全相同的业务应用系统中采用人工或报文方式进行,不能在应用相同但采用不同数据库的系统,甚至应用和数据库都不相同但实现同样的功能的系统上进行追账。该银行业务场景一般情况不会存在,追账都是在完全相同的应用系统和数据库上进行,但在采用新的数据库后或新的业务系统时,如果能够实现新老系统的并行,即在不影响原系统的情况下,在新系统中实现原业务的真实重现,并进行新系统正确性与老系统的核对,那么在新系统上线前,可以更多地进行新的系统和数据库的验证,减少上线后出现问题的可能性;这种业务真实运行也能直观反映新老系统在各方面的差别。
发明内容
本发明实施例所要解决的技术问题在于,提供一种跨数据库进行业务系统追账/测评方法及系统,以更加客观真实地评价新数据库对业务系统的适用性。
为了解决上述技术问题,本发明实施例提出了一种跨数据库进行业务系统追账/测评方法,包括:
采集步骤:采集生产核心业务系统上的业务报文信息,得到生产交易的报文数据;
报文处理步骤:对报文数据进行预处理,得到生产数据;
调度步骤:对生产数据按策略进行分组调度,为模拟生产环节发送做准备;
发送步骤:将分组后的生产数据发送至待评测的新建系统/生产备系统;发送过程中,采用多交易并行发送、按时间片控制同步、按时间戳控制发送时序的方式模拟生产环节发送;
核对步骤:实时校对新建系统/生产备系统返回的处理后的交易结果报文,以及进行日终核对处理业务数据。
相应地,本发明实施例还提供了一种跨数据库进行业务系统追账/测评系统,包括:
采集模块:采集生产核心业务系统上的业务报文信息,得到生产交易的报文数据;
报文处理模块:对报文数据进行预处理,得到生产数据;
调度模块:对生产数据按策略进行分组调度,为模拟生产环节发送做准备;
发送模块:将分组后的生产数据发送至待评测的新建系统/生产备系统;发送过程中,采用多交易并行发送、按时间片控制同步、按时间戳控制发送时序的方式模拟生产环节发送;
核对模块:实时校对新建系统/生产备系统返回的处理后的交易结果报文,以及进行日终核对处理业务数据。
本发明的有益效果为:本发明实现了待测的新建业务系统的新数据库在不影响原业务系统运行情况下真实业务环境下的运行,可以更加客观真实地评价新数据库对业务系统的适用性,并且可以实现新数据库与原数据库间的业务切换;追账功能也对更换新业务系统时对比与原业务系统的性能差别,这些原来都是需要依靠人工或使用案例进行测试的,现在可以通过追账/测评系统自动用真实业务进行测试。
附图说明
图1是本发明实施例的跨数据库进行业务系统追账/测评方法的流程示意图。
图2是本发明实施例的按时间片控制的同步处理机制的示意图。
图3是本发明实施例的跨数据库进行业务系统追账/测评系统的结构示意图。
图4是本发明实施例的交易调度分组按时间序处理机制的示意图。
图5是本发明示例1的生产核心业务系统和新建系统的TPS曲线图。
图6是本发明示例2的生产核心业务系统和新建系统的TPS曲线图。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互结合,下面结合附图和具体实施例对本发明作进一步详细说明。
本发明实施例中若有方向性指示(诸如上、下、左、右、前、后……)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等,如果该特定姿态发生改变时,则该方向性指示也相应地随之改变。
另外,在本发明中若涉及“第一”、“第二”等的描述仅用于描述目的,而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。
请参照图1,本发明实施例的跨数据库进行业务系统追账/测评方法包括采集步骤、报文处理步骤、调度步骤、发送步骤及核对步骤。
采集步骤:采集生产核心业务系统上的业务报文信息,得到生产交易的报文数据。本发明实施例的采集包括2种模式:从生产核心业务系统数据库报文流水表(即交易数据)采集;从报文日志文件中采集(即采集即交易数据)。生产核心业务系统由生产数据库和核心业务系统组成。
报文处理步骤:对报文数据进行预处理,得到生产数据。
调度步骤:对生产数据按策略进行分组调度,为模拟生产环节发送做准备。
发送步骤:将分组后的生产数据发送至待评测的新建系统(即新建的生产核心业务系统,由生产数据库和核心业务系统组成)/生产备系统;发送过程中,采用多交易并行发送、按时间片控制同步、按时间戳控制发送时序的方式模拟生产环节发送。
核对步骤:实时校对待评测的新建系统/生产备系统返回的处理后的交易结果报文,以及进行日终核对处理业务数据。
作为一种实施方式,发送步骤中,设置一个时间片参数T,所有的交易,以T为时间间隔,划分成n个批次,按时间从早到晚逐批发送;
每一批时间片批次的交易数据处理时,都进行并行发送,发送的先后次序按交易的原接收时间戳来排序和转发。
如图2所示,本发明实施例设置一个时间片参数T(毫秒),生产环境发生的所有交易,被平台以T为时间间隔,划分成n个批次,并严格按时间序进行转发。T的大小可以调整,单位时间片越小,本发明处理与生产系统的真实压力越接近。
作为一种实施方式,预处理包括关键字段预处理和报文转换。
关键字段预处理:将关键字段预处理进行预处理,保证最终交易结果与生产核心业务系统一致,关键字段为将生产核心业务系统交易完成时产生的业务重要数据,如账务流水号、客户新开账号/卡号等。涉及到关键字段的相关交易转发至待评测的新建系统/生产备系统后,要求新建系统/生产备系统必须产生一模一样的业务数据,才能保证后续的业务正常运行。为了实现这点,本发明实施例将会分析、处理和保存原生产交易返回的关键字段,并将该关键字段通过各种渠道传送到新建系统/生产备系统(即目标系统)中去,由目标系统进行特殊化处理,保证最终交易结果与原生产核心业务系统一致。
报文转换:按照待评测的新建系统/生产备系统的交易应用接口规范,转换报文格式。因为待评测的新建系统/生产备系统的交易应用接口规范与生产核心业务系统不一样,而不得不进行两种报文格式之间的转换。报文转换最终使得双方系统处理时输入业务要素保证一样。
在项目的落地实践中,追账模式下由于双方系统一般是一样的,仅仅数据库不同,所以报文数据的预处理只需要用到“关键字段预处理”这块功能。而在测评模式下,由于待评测的新建系统/生产备系统(即目标系统)一般是新建系统,不仅仅数据库不同,应用系统、报文格式规范都和原生产核心业务系统不一样,所以还需要用到“报文转换”功能。
作为一种实施方式,核对步骤之后包括运维步骤:对待评测的新建系统/生产备系统的数据库进行性能分析,所述性能分析包括业务交易使用到的SQL单条语句处理耗时、整体业务交易耗时。
请参照图3,本发明实施例的跨数据库进行业务系统追账/测评系统包括采集模块、报文处理模块、调度模块、发送模块及核对模块。
采集模块:采集生产核心业务系统上的业务报文信息,得到生产交易的报文数据;
报文处理模块:对报文数据进行预处理,得到生产数据;
调度模块:对生产数据按策略进行分组调度,为模拟生产环节发送做准备;
发送模块:将分组后的生产数据发送至待评测的新建系统/生产备系统;发送过程中,采用多交易并行发送、按时间片控制同步、按时间戳控制发送时序的方式模拟生产环节发送;
核对模块:实时校对待评测的新建系统/生产备系统返回的处理后的交易结果报文,以及进行日终核对处理业务数据。
结果校对一般采用关键字段对比的方法进行,在开发过程中,开发人员将会根据每个交易的不同,设置返回接口关键字段核对清单,本发明实施例的跨数据库进行业务系统追账/测评系统正式运行时,交易转发得到结果后,跨数据库进行业务系统追账/测评系统就会根据该清单在两系统之间逐项进行核对,如核对字段可以为:成功失败标志、交易金额、账户余额和客户姓名等。
在结果校对后,当发现其返回结果字段值和生产核心业务系统原业务返回字段值不一致时,根据已设置业务的规则,进行下一步处理,处理包括:重发、停止、跳过等。举例说明:对公客户记账类交易,交易结果不一致时可重新再做;个人客户记账类交易,如存款,交易结果不一致,原生产核心业务系统成功,待评测的新建系统/生产备系统(即目标系统)失败,这种情况则需要暂停,解决问题后,再重新发起,直到成功为止,避免该个人客户后续取款由于余额不足导致失败;而查询类交易,由于影响不大,就算结果不一致也可以直接跳过。
作为一种实施方式,发送模块中,设置一个时间片参数T,所有的交易,以T为时间间隔,划分成n个批次,按时间从早到晚逐批发送;
每一批时间片批次的交易数据处理时,都进行并行发送,发送的先后次序按交易的原接收时间戳来排序和转发。
作为一种实施方式,预处理包括关键字段预处理和报文转换,其中,
关键字段预处理:将关键字段预处理进行预处理,保证最终交易结果与生产核心业务系统一致,关键字段为将生产核心业务系统交易完成时产生的业务重要数据;
报文转换:按照待评测的新建系统/生产备系统的交易应用接口规范,转换报文格式。
作为一种实施方式,跨数据库进行业务系统追账/测评系统还包括运维模块:对待评测的新建系统/生产备系统的数据库进行性能分析,所述性能分析包括业务交易使用到的SQL单条语句处理耗时、整体业务交易耗时。
请参照图4,在业务发生后,跨数据库进行业务系统追账/测评系统进行数据采集、交易调度后,模拟生产环境当时的真实场景,将交易根据机构、柜员等进行重新分组,并发的向新建的新建系统/生产备系统发起。
实施例1:测评模式,某银行原生产核心业务系统正常运行,新建系统使用新的某国产分布式数据库,通过本发明的跨数据库进行业务系统追账/测评系统,实现将所有核心真实业务运行在新建系统中,并每天进行与原生产核心业务系统运行结果的核对,达到连续运行并做到与原核心业务99.999%的结果相同。
本发明实施例从生产核心业务系统上读取业务报文信息,将业务报文信息进行转换为新的新建系统的业务报文信息,然后根据原业务报文的发生时间进行发送时序控制,采用时间片控制同步发送或真实时间异步发送到新建系统中,并对返回的结果信息与生产核心业务系统返回的结果信息进行核对。本发明实施例除联机业务外,对联机批量类业务和日终批量类业务也会同步运行。每天业务完成后,通过本发明实施例的跨数据库进行业务系统追账/测评系统,还可以进行新建系统和生产核心业务系统两者之间的业务数据核对验证,用于评测新的核心业务的业务处理逻辑是否正确,数据库的数据处理是否正确。
本发明实施例在进行联机业务交易转发时,由于核心业务的高度并发性以及与时间序高度相关性,平台为了全场景模拟和性能测试,采用了时间片来控制业务报文的发送,在同一时间片内,对业务类型、交易柜员等进行分析,保证发送到新建系统中的业务先后顺序,在时间片业务处理完后再进行下一时间片处理,也保证了同时间段业务的同步性。时间片的大小通过参数控制,时间片的实际运行也可以进行拉长或压缩;这样可以控制比原生产核心业务系统发送得更快,这样可以观察更大压力下的真实业务在新建系统/新数据库上的运行情况。
本发明实施例通过TPS分析,可对生产核心业务系统全业务场景的模拟情况,及新建系统的性能进行评测。
示例1说明:如图5所示,图中生产系统即生产核心业务系统,本发明实施例对生产核心业务系统24小时的业务进行转发后,通过分析,新建系统和生产核心业务系统表现出来的TPS(每秒交易量)折线图是基本一致的,表明新建系统和数据库的处理能力不低于现生产核心业务系统的能力。(新建系统曲线时间轴上的延迟是由于采集数据机制需要延迟所致。)
示例2说明:如图6所示,图中生产系统即生产核心业务系统,本发明实施例对生产核心业务系统24小时的业务进行转发后,通过分析,新建系统和生产核心业务系统表现出来的TPS(每秒交易量)折线图在业务发生高峰时段不一致,新建系统低于生产核心业务系统,表明新建系统和数据库的峰值处理能力低于现生产核心业务系统的能力。
本发明实施例通过对联机业务结果分析,可验证新建系统的联机业务处理准确性,分析情况如表1所示:
表1
本发明实施例的追账/测评系统通过日终后进行的业务数据核对,可校验核新建系统的业务数据准确性,核对内容清单举例如表2所示:
表2
建设完成后,通过一段时间运行对新建系统新数据库测试成熟后,生产核心业务系统和新建系统就可以实现在线并行切换运行,即通过使用本发明实施例的追账/测评系统实现双系统双数据库并行方案。
实施例2:追账模式,某银行新建生产备系统,使用国外数据库,同步并行使用国产数据库,当运行一段时间稳定后可以在两种数据库间进行切换。
本发明实施例的追账/测评系统的追账模式是评测模式的更深层次应用,在这种模式下,追账/测评系统对接的原被评测系统也作为生产的一部分,成为生产备系统,与主系统并行运行。在日常运行中,追账/测评系统对生产主系统的场景模拟要求可以降低,但是原则上要保证主系统和备系统业务处理的一致性和准确性均到达100%,在此基础上,才能根据需要进行两个系统或数据库的切换使用。
尽管已经示出和描述了本发明的实施例,对于本领域的普通技术人员而言,可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型,本发明的范围由所附权利要求及其等同范围限定。
- 跨数据库进行业务系统追账/测评方法及系统
- 一种银行业务系统变更投产补账方法及装置