CN112905568A - 一种基于存储过程设计优化的热部署方法 - Google Patents

Abstract

本发明公开了一种基于存储过程设计优化的热部署方法，属于银行核心技术领域，解决因部署数据库版本时需要重启应用服务，导致业务中断的问题。主要方案包括当核心应用接收服务请求调用时，数据库层设置公共处理模块功能，据维护的系统级参数进行判断是否在进行版本部署，若检查到在窗口维护期，交易失败；若检查到不在窗口维护期，继续进行业务逻辑处理，后续业务逻辑处理时，若发生异常，针对数据库对象失效异常进行捕获并封装成有特定含义的错误码返回，其他异常按照原有异常封装进行报错，上层调用根据该错误判断进行交易回滚，并返回给调用方，请求调用结束。调用方根据返回的该错误码判断是否为包失效异常，若是，则重新发起相同交易请求。

Description

一种基于存储过程设计优化的热部署方法

技术领域

一种基于存储过程设计优化的热部署方法，用于解决生产环境数据库版本部署不停机问题，属于金融行业核心应用技术领域。

背景技术

现在的很多应用都是支持24小时不间断提供服务的，在不停机更新版本时，不影响服务调用。作为主要业务逻辑依赖数据库存储过程设计的系统，如何保证不停机部署数据库版本时，服务调用不发生异常是面临的一个难题。为解决该问题，热部署概念被提了出来。结合系统自身特点，基于数据库存储过程设计优化的热部署方法也属于热部署的一种。

目前热部署有多种方案，但大多数都是基于Java的应用服务器，包括EJB服务器和Servlet容器的热部署。另外基于蓝绿版本发布的也可以实现24小时不间断的提供服务。

但第一种方法，不适用于业务处理逻辑依赖于数据库存储过程的系统。第二种方法，需要搭建两套相同的蓝绿环境，使用成本增加，且改造难度稍大，影响范围较广。

发明内容

针对上述研究的问题，本发明的目的在于提供一种基于数据库存储过程设计优化的热部署方法，解决应用数据库版本部署时需要停机重启的问题，在不停机部署数据库版本时，由于包发生改变导致交易异常失败。

为了达到上述目的，本发明采用如下技术方案：

一种基于存储过程设计优化的热部署方法，其特征在于，不需要重启应用直接部署数据库版本，部署完成后应用仍然可正常对外提供服务：步骤如下：

步骤1：部署数据库版本前，先在数据库中窗口维护参数表中维护版本部署时间，在维护版本部署时间内，版本维护窗口参数置为Y-有效；

步骤2：数据库版本部署时间维护好后，开始部署数据库版本，使用自动化版本部署工具部署数据库版本包，部署完成后自动进行包编译，至此版本部署结束；

步骤3：将版本维护窗口参数由效状态更新为N-失效；

数据库版本部署完毕后，解决不停机部署数据库版本可能导致的包失效问题的具体步骤如下：

步骤4：当应用接收渠道服务请求调用时，调用jdbc api建立数据库连接，数据库层进行交易接入窗口维护期检查逻辑，若版本维护窗口参数为有效，则检查服务请求时间，如接收到的服务请求时间在在维护版本部署时间内，则直接返回报错“系统正在维护，请稍后重试”；否则认为检查通过，则继续执行；

步骤5：继续执行业务逻辑调用，根据数据库层接口功能定义参数表，接口调用引擎按照事先定义好的业务片段调用顺序依次执行，在调用各个业务片段前设置对应的回滚点 savepoint，然后按照顺序依次调用各业务片段，每个业务片段调用时进行异常捕获，针对包失效进行异常封装处理，若未发生异常，则交易结束，若发生异常且为包失效异常，则交易失败，封装异常返回错误码，并进行交易回滚至设置的回滚点savepoint，并登记交易流水且交易失败原因登记为包失效；

步骤6：消费方接收到该特定含义的错误码后，重新发起相同服务调用请求，新的服务请求会建立新的会话连接，再次调用发生变更的数据库包对象时该包已是重新编译过的则不会检测到包失效异常；

上述技术方案中，在部署数据库版本前已存在的请求会话连接，即在部署数据库版本前还存在服务请求没有执行完成，若交易接口的某个业务片段调用发生了包变更的数据库对象时会检测到包发生了变更而提示包失效异常。

上述技术方案中，系统基于交易重复控制机制，即不允许同一个交易渠道当日具有相同流水号的服务请求，针对由于包失效导致的交易失败场景，检查交易流水登记簿，若重新发起的相同交易请求，即与上一笔服务请求流水号相同，失败原因为包失效，允许继续交易，依次完成步骤1-4。

上述技术方案中，在部署数据库版本前，先进行版本维护时间参数配置。

上述技术方案中，所述系统窗口维护期检查，是在服务请求调用前就已经配置好，并保存在数据库中，其中，配置表包括渠道类型和交易检查方法。

上述技术方案中，所述接口功能定义参数表是在服务调用前已经配置好，即一个完整接口功能划分为各个业务片段，每个业务片段都事先定义好了执行顺序，如上述所述，交易接口定义的业务片段执行顺序按照P/A/0/D/E/C，各业务片段按照功能依次划分为预处理/有效性检查/授权/警告/提交片段，不同的片段完成不同的功能逻辑，按照从前往后的顺序依次执行。

上述技术方案中，所述步骤4中系统窗口维护期检查的具体步骤如下：

步骤4.1：在每次上线数据库版本时，先维护窗口期参数，如下午9:30到10:30，则维护窗口维护期参数，设置部署开始时间为21:30，结束时间为22:30；

步骤4.2：当应用接收到服务调用请求后，按照系统检查参数表的配置，调用窗口维护期检查，若检查到当前服务请求的时间在窗口维护期，则直接返回“系统正在维护，请稍后重试”；若接收到的服务请求时间不在21:30至22:30期间，检查通过，继续执行。

上述技术方案中，接口各片段的包失效异常捕获和消费方重新服务请求的实现步骤如下：

步骤5.1：若接收到服务调用请求，进行交易重复提交控制处理，若检查到请求交易状态失败，且失败原因为包失效，则继续业务逻辑处理，若检查到流水重复，且为成功或失败，且失败原因不为包失效，根据原流水交易状态返回已存在相同交易正在处理/交易失败/被冲正等：

步骤5.2：接口调用引擎中对调用接口功能定义中的各个业务片段进行包失效异常捕获，并对该异常进行封装，定义为具有特殊含义的错误码返回，并登记交易流水登记簿；

步骤5.3：消费方接收到该特定含义的错误码后，重新发起相同服务调用请求，新的服务请求会建立新的会话连接，再次调用发生变更的数据库包对象时该包已是重新编译过的则不会检测到包失效异常，交易成功。

上述技术方案中，交易重复控制机制的实现步骤如下：

步骤6.1：若接收到服务调用请求，进行交易重复提交控制处理。根据服务请求流水号查询流水登记簿，若检查到已存在相同流水号的交易请求且请求状态为失败，失败原因为包失效，则继续业务逻辑处理；若没有检查到相同流水的交易请求，则继续处理；若检查到流水重复，且为成功或失败，失败原因不为包失效，交易失败，返回“存在相同交易已处理”。

本发明同现有技术相比，其有益效果表现在：

一、本发明通过采用参数化配置，实现部署版本时对外维护公告提醒，且减少传统版本部署重启服务的时间，节约版本部署时间百分之九十左右。

二、本发明在服务调用业务逻辑处理前进行系统级功能检查，检查通过后执行接口定义的业务片段，若业务片段发生包失效异常，则封装成具有特定含义的错误返回给服务调用方，服务调用方根据该错误码重新进行服务调用请求，整体处理流程清晰明确，实现起来较为简单。

三、本发明通过数据库参数化配置实现，使用灵活简单。

四、热部署是一种方法，即部署代码时不需要重启应用，直接部署数据库代码，部署完成后应用仍然正常对外提供服务，为了解决这个问题提出了文中提到的改造步骤。不停机部署数据库版本时可能因为包发生改变，导致某个业务片段执行时调用某个对象即存储过程或方法时，该存储过程或方法所在包因为部署版本发生了改变会报oracle系统级错误“包失效”而导致服务调用失败，因此执行每隔片段时针对该异常错误“包失效”进行捕获，并封装成具有特定含义的错误返回给渠道，渠道重新发起相同服务请求时就不会报此错。

附图说明

图1为本发明的包编译后程序失效改造流程示意图；

图2为本发明中版本部署窗口维护检查的实现流程图；

图3为本发明中服务请求调用流程改造示意图。

具体实施方式

下面将结合附图及具体实施方式对本发明作进一步的描述。

热部署是一种方法，是指在不停止应用服务的前提下部署版本，部署完版本不需要重启应用，且应用提供的服务仍然可以正常访问。

请求调用是指消费方发起的服务调用，例如：通过手机银行转账，手机银行就会给银行核心应用发起一笔转账的服务请求，银行核心应用收到该笔请求后，完成转账操作。

基于存储过程设计优化的热部署方案，主要是为了解决当前应用数据库版本部署后需要重启应用的问题，且由于目前生产环境部署机器较多，部署版本后重启应用消耗时间较长且会导致服务中断，基于系统自身特点，在存储过程设计上进行改造优化。

系统在接收消费方的服务调用请求时，首先根据窗口维护参数判断交易请求时间是否在窗口维护期，若是则直接返回“系统正在维护，请稍后重试”；在非窗口维护期部署数据库版本后，因为涉及存储过程包更新，原有会话检测到某个包更新后会提示包失效，导致交易失败，通过接口调用引擎中各个业务片段的异常捕获处理，将包失效异常封装成具有特定含义的错误码返回给渠道调用方，渠道根据该错误码判断由于服务方包失效交易失败重新发起相同服务请求，重新发起的请求调用会建立新的会话连接，不会检测到包变更提示包失效。

具体实现步骤如下：

一种基于存储过程设计优化的热部署方法，其特征在于：步骤如下：

步骤S1：维护数据库版本部署窗口参数；

步骤S2：使用自动化部署工具部署数据库版本；

步骤S3：交易接口接入窗口维护检查业务片段配置；

步骤S4：交易请求防重控制；

步骤S5：接口定义业务片段异常捕获；

步骤S6：重新发起交易请求；

S1具体说明：

1，设计一张数据库版本部署窗口维护参数表，涉及版本部署开始时间，结束时间和是否生效字段，在部署数据库版本前维护该参数表；

2，在交易接口接入公共系统检查参数表中配置窗口维护检查业务片段，该片段用于检查接收的服务请求时间是否在窗口维护期，若请求时间在窗口维护期，则直接拒绝服务请求，若不在窗口维护期，则继续执行。

S2具体说明：

1：数据库版本部署时间维护好后，开始部署数据库版本，使用自动化版本部署工具部署数据库版本包，并自动完成包编译，至此版本部署完毕；

2：将版本维护窗口参数有效状态更新为N-失效。

S3具体说明：

1，当应用接收到服务调用请求后，如通过手机银行发起一笔转账交易，当该笔转账交易请求发送到银行核心应用后，首先检查是否维护了版本部署窗口维护期参数，若存在，则检查该笔转账请求的时间是否在窗口维护期，若是则直接返回“系统正在维护，请稍后重试”，该笔转账失败；若接收到的服务请求时间不在窗口维护期，继续执行，完成转账逻辑业务处理。

S4具体说明：

1，根据接收到的服务请求查询流水登记簿，每笔交易请求都存在一个唯一标识，即请求流水号，如上述发起的转账交易，检查该笔转账请求流水号是否存在于流水登记簿中，若存在，且交易请求状态为失败，失败原因为包失效，则继续业务逻辑处理，确保因为原会话连接(数据库版本部署前已建立的转账请求连接)因为包失效而转账失败的交易重新发起服务请求时完成转账交易，实现体验上的无感知，其他失败如余额不足，则转账失败，若没有检查到相同流水的交易请求，则继续处理；若检查到流水重复，且交易状态成功，则转账失败。

S5具体说明：

1，根据数据库层接口功能定义参数表，接口调用引擎按照事先定义好的业务片段调用顺序依次执行，在调用各个业务片段前设置对应的回滚点savepoint，然后按照顺序依次调用接口定义的各业务片段，每个业务片段调用时进行异常捕获，针对包失效进行异常封装处理，若未发生异常，则交易结束。若发生异常且为包失效异常，则交易失败，封装异常返回，并进行交易回滚至设置的回滚点，并登记交易流水且交易失败原因登记为包失效。

S6具体说明：

消费方接收到上述特定含义的错误码后，重新发起相同服务调用请求。在部署数据库版本前已存在的请求会话连接，即在部署数据库版本前还存在服务请求没有执行完成，若交易接口的某个业务片段调用发生了包变更的数据库对象时会检测到包发生了变更提示包失效异常，新的服务请求会建立新的会话连接，再次调用发生变更的数据库包对象时该包已是重新编译过的则不会检测到包失效异常。

因为我们系统的主要逻辑是在数据库编写的存储过程，每次部署数据库版本(就是更新文中提到的包)，会导致部署版本前还没有释放的会话(服务调用)调用更新的包时会检测到包发生变更而报错(包失效)，按照现有逻辑返给调用方的错误他们也不知道是什么错误，客户的体验感也不好，所以针对包失效这种异常，在执行的各个业务片段都增加该异常捕获，封装成特定含义的错误码，渠道根据该错误重新发起调用，对客户来说也是无感的。

Claims (9)

1.一种基于存储过程设计优化的热部署方法，其特征在于，不需要重启应用直接部署数据库版本，部署完成后应用仍然可正常对外提供服务：步骤如下：

步骤1：部署数据库版本前，先在数据库中窗口维护参数表中维护版本部署时间，在维护版本部署时间内，版本维护窗口参数置为Y-有效；

步骤2：数据库版本部署时间维护好后，开始部署数据库版本，使用自动化版本部署工具部署数据库版本包，部署完成后自动进行包编译，至此版本部署结束；

步骤3：将版本维护窗口参数由效状态更新为N-失效；

数据库版本部署完毕后，解决不停机部署数据库版本可能导致的包失效问题的具体步骤如下：

步骤4：当应用接收渠道服务请求调用时，调用jdbc api建立数据库连接，数据库层进行交易接入窗口维护期检查逻辑，若版本维护窗口参数为有效，则检查服务请求时间，如接收到的服务请求时间在维护版本部署时间内，则直接返回报错“系统正在维护，请稍后重试”；否则认为检查通过，则继续执行；

步骤5：继续执行业务逻辑调用，根据数据库层接口功能定义参数表，接口调用引擎按照事先定义好的业务片段调用顺序依次执行，在调用各个业务片段前设置对应的回滚点savepoint，然后按照顺序依次调用各业务片段，每个业务片段调用时进行异常捕获，针对包失效进行异常封装处理，若未发生异常，则交易结束，若发生异常且为包失效异常，则交易失败，封装异常返回错误码，并进行交易回滚至设置的回滚点savepoint，并登记交易流水且交易失败原因登记为包失效；

步骤6：消费方接收到该特定含义的错误码后，重新发起相同服务调用请求，新的服务请求会建立新的会话连接，再次调用发生变更的数据库包对象时该包已是重新编译过的则不会检测到包失效异常。

2.根据权利要求1所述的一种基于存储过程设计优化的热部署方法，其特征在于：在部署数据库版本前已存在的请求会话连接，即在部署数据库版本前还存在服务请求没有执行完成，若交易接口的某个业务片段调用发生了包变更的数据库对象时会检测到包发生了变更而提示包失效异常。

3.根据权利要求1所述的一种基于存储过程设计优化的热部署方法，其特征在于：系统基于交易重复控制机制，即不允许同一个交易渠道当日具有相同流水号的服务请求，针对由于包失效导致的交易失败场景，检查交易流水登记簿，若重新发起的相同交易请求，即与上一笔服务请求流水号相同，失败原因为包失效，则允许继续交易，依次完成步骤1-4。

4.根据权利要求1所述的一种基于存储过程设计优化的热部署方法，其特征在于：在部署数据库版本前，先进行版本维护时间参数配置。

5.根据权利要求4所述的一种基于存储过程设计优化的热部署方法，其特征在于：所述系统窗口维护期检查，是在服务请求调用前就已经配置好，并保存在数据库中，其中，配置表包括渠道类型和交易检查方法。

6.根据权利要求1所述的一种基于存储过程设计优化的热部署方法，其特征在于：所述接口功能定义参数表是在服务调用前已经配置好，即一个完整接口功能划分为各个业务片段，每个业务片段都事先定义好了执行顺序，如上述所述，交易接口定义的业务片段执行顺序按照P/A/0/D/E/C，各业务片段按照功能依次划分为预处理/有效性检查/授权/警告/提交片段，不同的片段完成不同的功能逻辑，按照从前往后的顺序依次执行。

7.根据权利要求5所述的一种基于存储过程设计优化的热部署方法，其特征在于：所述步骤4中系统窗口维护期检查的具体步骤如下：

步骤4.1：在每次上线数据库版本时，先维护窗口期参数，如下午9：30到10：30，则维护窗口维护期参数，设置部署开始时间为21：30，结束时间为22：30；

步骤4.2：当应用接收到服务调用请求后，按照系统检查参数表的配置，调用窗口维护期检查，若检查到当前服务请求的时间在窗口维护期，则直接返回“系统正在维护，请稍后重试”；若接收到的服务请求时间不在21：30至22：30期间，检查通过，继续执行。

8.根据权利要求1所述的一种基于存储过程设计优化的热部署方法，其特征在于：接口各片段的包失效异常捕获和消费方重新服务请求的实现步骤如下：

步骤5.1：若接收到服务调用请求，进行交易重复提交控制处理，若检查到请求交易状态失败，且失败原因为包失效，则继续业务逻辑处理，若检查到流水重复，且为成功或失败，且失败原因不为包失效，根据原流水交易状态返回已存在相同交易正在处理/交易失败/被冲正等；

步骤5.2：接口调用引擎中对调用接口功能定义中的各个业务片段进行包失效异常捕获，并对该异常进行封装，定义为具有特殊含义的错误码返回，并登记交易流水登记簿；

步骤5.3：消费方接收到该特定含义的错误码后，重新发起相同服务调用请求，新的服务请求会建立新的会话连接，再次调用发生变更的数据库包对象时该包已是重新编译过的则不会检测到包失效异常，交易成功。

9.根据权利要求3所述的一种基于存储过程设计优化的热部署方法，其特征在于：交易重复控制机制的实现步骤如下：

步骤6.1：若接收到服务调用请求，进行交易重复提交控制处理。根据服务请求流水号查询流水登记簿，若检查到已存在相同流水号的交易请求且请求状态为失败，失败原因为包失效，则继续业务逻辑处理；若没有检查到相同流水的交易请求，则继续处理；若检查到流水重复，且为成功或失败，失败原因不为包失效，交易失败，返回“存在相同交易已处理”。

Images