CN111538519A - 一种版本升级方法及装置 - Google Patents

Abstract

本发明涉及金融科技(Fintech)领域，公开一种版本升级方法及装置，第一节点在第一版本标记为升级态时，停止第一服务实例；将系统数据库的第一功能参数更新至第一本地内存；启动第一服务实例，并通过第一本地内存的第一功能参数运行第一服务实例。本方案仅通过对第一节点的第一服务实例先进行版本升级，而非对第一节点上的全部服务实例或分布式系统中的全部节点的全部服务实例都进行版本升级，方法灵活，可将版本升级失败所带来的风险降到最低；通过功能参数的方式实现各业务功能，而非现有技术中依靠运行代码来实现业务功能，故本方案可通过第一配置文件更新功能参数从而实现版本升级，避免了现有技术中通过更改代码来完成升级的复杂性。

Description

一种版本升级方法及装置

技术领域

本发明实施例涉及金融科技(Fintech)领域，尤其涉及一种版本升级方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术(例如：大数据、云计算或区块链)应用在金融领域，传统金融业正在逐步向金融科技转变，大数据技术也不例外。但由于金融、支付行业的安全性、实时性要求，也对大数据技术提出了更高的要求。

灰度发布，又称作金丝雀发布，是指黑与白之间，能够平滑过渡的一种方式。比如，软件系统在进行功能升级中，旧功能可以平滑过渡到新功能的一种发布方式。

假设一软件系统的当前版本是A版本，当对该软件系统成功升级后，它的新版本是B版本。如何将A版本的软件系统升级到B版本的软件系统，则可以采用灰度发布的方式进行：当对A版本的软件系统中的某个功能进行功能升级时，由系统使用方或者系统本身来控制一部分用户继续使用A版本的软件系统，另一部分用户开始使用B版本的软件系统，一段时间后，使用B版本的软件系统的用户没有出现任何的异常，则逐步将所有的软件系统升级为B版本。

传统的银行存款核心系统，都是基于IOE(IBM、Oracle、EMC)的单节点模型，常见方案为：

通过准备一套灰度发布环境来达到灰度发布的目的。灰度发布环境是每次发布的时候预先根据当前的线上生产环境创建的，每次发布时都需提前按照生产上的服务器版本号、运行个数，每个服务器处理请求的能力(如请求响应时间，处理请求数量等)创建一个灰度发布环境，需先在灰度发布环境完全测试通过后再进行生产发布。

可以看出上述实现方案是针对单节点的，且往往需要先创建一个灰度发布环境，在测试通过后再进行生产发布，导致发布环节复杂。

发明内容

本发明提供一种版本升级方法及装置，用以解决现有技术无法针对分布式架构的软件系统在版本升级过程进行灰度发布的问题。

第一方面，本发明实施例提供一种版本升级方法，该方法包括：第一节点在第一版本标记为升级态时，停止所述第一节点上的第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；所述第一节点启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

基于该方案，在确认第一服务实例为需要版本升级的状态时，第一节点将停止第一服务实例对外所提供的一切服务，并将系统数据库中的第一功能参数更新至第一服务实例的第一本地内存中，当第一节点启动第一服务实例后，则第一服务实例可以根据第一本地内存中的第一功能参数重新开始对外提供服务。该方案，通过在服务实例中设置本地内存，可以确保仅通过对第一节点上的第一服务实例先进行版本升级，而非对第一节点上的全部服务实例以及分布式系统中的全部节点的全部服务实例都进行版本升级，这种版本升级方法更为灵活，可以将版本升级失败所带来的风险降到最低程度；此外，本方案通过功能参数的方式实现各业务功能，而非现有技术中依靠运行代码来实现业务功能，因而本方案可通过第一配置文件更新功能参数从而实现版本升级，避免了现有技术中通过更改代码来完成升级的复杂性。

在一种可能的实现方法中，所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中，包括：所述第一节点通过缓存定义表确定需要更新至所述第一本地内存中的各功能参数表；所述缓存定义表记录有各功能参数表的属性信息；所述功能参数表记录有设定功能的各功能参数；所述第一节点从所述系统数据库中获取所述各功能参数表并加载至所述第一本地内存。

基于该方案，通过缓存定义表确定需要更新至本地内存中的功能参数表，可以快速实现系统数据库至本地内存的刷新，使得第一服务实例在重新启动后，可以用更新后的功能参数表对外提供服务。

在一种可能实现的方法中，所述通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例，包括：所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表；所述第一服务实例根据所述第一功能参数表在所述缓存定义表中的属性信息，确定通过所述第一本地内存中的所述第一功能参数表来执行所述服务请求。

基于该方案，在第一服务实例启动后，接收到前端发送的服务请求，在确定缓存定义表中具有所述服务请求对应的第一功能参数表，从而可以通过第一服务实例的第一本地内存中的第一功能参数表来对所述服务请求作出响应，合理区分系统数据库和本地内存的业务，减轻了对系统数据库的压力，也加快了服务请求的处理。

在一种可能实现的方法中，所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表之前，还包括：所述第一节点中的拦截线程确定所述服务请求需调用所述第一功能参数表。

基于该方案，通过设置拦截线程，则对于待处理的请求服务请求是通过服务实例的本地内存还是通过系统数据库来处理，可以做出有拦截线程做出判断；此外，通过所设置的拦截线程，可以确定用于对待处理服务请求作出响应的功能参数表。

在一种可能实现的方法中，所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中之前，还包括：所述第一节点的轮询线程确定所述系统数据库中的功能参数表发生了更改。

基于该方案，通过设置轮询线程，可以实现周期性地检查第一服务实例的第一本地内存中的功能参数表是否与系统数据库中的功能参数表保持一致性，并且在确定两者不一致时，轮询线程会将系统数据库中的功能参数表更新至第一服务实例的第一本地内存中。

在一种可能的实现方法中，所述第一节点在第二版本标记为非升级态时，从第二服务实例的第二本地内存中获取第二功能参数从而运行所述第二服务实例；所述第二版本标记用于指示所述第二服务实例是否需要升级；所述第二功能参数是所述系统数据库中通过所述第一配置文件更改前的记录。

基于该方案，在确认第二服务实例为不需要版本升级的状态时，第一节点仅需要从第二服务实例的第二本地内存中获取第二功能参数，以使得第二服务实例依然可以以旧版本的程序来正常对外提供服务，该方法保证了在对第一服务实例进行版本升级过程中，由于第一节点会短暂地将第一服务实例对外服务的行为停掉，因此调度系统可以将预设的准备调入第一服务实例的用户流量调入依然正常运作的第二服务实例上，让第二服务实例对用户提供服务，从而保证了在第一服务实例升级过程中，分布式系统重要依然可以有能正常运作的第二服务实例对外提供服务，将数据库变更脚本影响的交易范围和用户量最小化。

在一种可能的实现方法中，所述运行所述第一服务实例之后，还包括：所述第一节点在所述第一服务实例运行失败后，暂停所述第一服务实例，并将所述系统数据库中的第二功能参数更新至所述第一本地内存中；所述第二功能参数是根据第一回滚配置文件将所述系统数据库恢复至所述第一功能参数之前的记录。

基于该方案，在对第一服务实例进行版本升级的过程中，由于某些因素的存在将会导致第一节点上的第一服务实例无法如期、正常地实现由旧版本的程序升级到新版本的程序，也即第一服务实例在版本升级后会发生运行失败的情况，对此，本申请中仅需要通过数据回滚的操作即可以实现由新版本的程序恢复至旧版本的程序，从而保证了版本无法升级成功的第一服务实例依然可以用旧版本的程序来对外提供服务。

在一种可能的实现方法中，所述第一本地内存按照设定的表结构存储所述系统数据库中的功能参数表。

基于该方案，通过在第一服务实例的第一本地内存中存储系统数据库中的功能参数表，则可以根据第一服务实例本地的数据内容来对外提供服务；另一方面，在服务实例进行版本升级过程中，由于服务实例本地内存中可以存储系统数据库中的功能参数表，从而对于一些需要版本升级的服务实例(第一服务实例)来说，它/它们可以用系统数据库中最新的功能参数表来对外提供服务；而对于一些不需要版本升级的服务实例(第二服务实例)来说，它/它们可以继续使用自己本地内存的未更新的功能参数表来对外提供服务，从而可以实现对第一节点上的全部服务实例进行批量升级的目的。

在一种可能实现的方法中，所述第一节点为分布式系统中的多个节点中的任一个；所述分布式系统按照设定规则进行系统升级，包括：所述第一节点上的各服务实例按照第一规则进行批量升级；所述第一规则是针对服务实例的升级顺序；所述第一节点升级后，按照第二规则对第二节点进行升级；所述第二节点为所述分布式系统中除所述第一节点外的任一节点；所述第二规则是针对节点的升级顺序。

基于该方案，由于分布式系统中存在多个节点，因此先通过对分布式系统中的某一测试节点进行率先升级，从而可以在该测试节点的版本升级效果良好的情况下，实现对分布式系统中的除去该测试节点的其余节点都进行版本升级，其中，在对该测试节点进行率先升级的过程中，又是可以先通过对其上的第一服务实例进行版本升级。以上对分布式系统进行版本升级的整个流程，可以将版本升级的风险降到最大，影响的范围也最小。

在一种可能实现的方法中，所述第一节点在所有服务实例按照所述第一配置文件升级成功后，将所述系统数据库中的第三功能参数更新至所述所有服务实例各自的本地内存中；所述第三功能参数是通过第二配置文件设置的，所述第二配置文件用于对与服务实例无依赖关系的功能参数的升级。

基于该方案，当第一节点上的全部服务实例都实现了版本升级后，通过再次执行将系统数据库中的第三功能参数刷新至第一节点上的全部服务各自的本地内存中，则对于第一节点上的全部服务实例，它们彼此之间可以实现更好的配合，来对外提供服务。

在一种可能实现的方法中，所述第一节点在所有节点的所有服务实例按照所述第一配置文件和所述第二配置文件升级成功后，将所述系统数据库中的第四功能参数更新至所述所有服务实例各自的本地内存中；所述第四功能参数是通过第三配置文件设置的，所述第三配置文件用于对与上下游服务实例有依赖关系的功能参数的升级。

基于该方案，当分布式系统中的全部节点中的每一个节点上的全部服务实例都按照第一配置文件和第二配置文件升级成功后，通过再次将系统数据库中的第四功能参数刷新至全部节点中的每一个节点上的全部服务实例，从而对于分布式系统的全部节点，它们彼此之间可以实现更好的配合，来对外提供服务。

第二方面，本发明实施例提供一种版本升级方法，该方法包括：发布端通过第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；所述发布端根据第一规则，设置第一节点的第一版本标记为升级态；所述第一版本标记用于指示所述第一服务实例是否需要升级；所述发布端在确定所述第一服务实例升级失败时，通过第一回滚配置文件，恢复到所述第一配置文件对所述系统数据库进行更新之前的第二功能参数。

基于该方案，发布端根据第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；在确认第一服务实例版本升级失败后，发布端根据第一回滚配置文件，将系统数据库的功能参数修改为本次版本未升级之前的功能参数，以及将第一服务实例的第一本地内存中的第一功能参数也刷新为本次版本未升级之前的功能参数，从而保证了在第一节点上的第一服务实例升级失败后，可以在第一时间内对版本升级失败的数据进行回滚，让第一服务实例可以继续以旧版本的程序对外提供服务。

在一种可能的实现方法中，所述发布端在确定所述第一节点的所有服务实例升级成功后，通过第二配置文件对系统数据库中的功能参数进行更改，得到第三功能参数；所述发布端在确定升级失败时，通过第二回滚配置文件，恢复到所述第二配置文件对所述系统数据库进行更新之前的所述第一功能参数。

基于该方案，发布端根据第二配置文件对系统数据库中的功能参数进行修改，得到第三功能参数；在确认第一节点上的全部服务实例彼此之间配合的程度达不到第二配置文件的预设效果时，可以在第一时间内根据第二回滚配置文件对第一节点上的全部服务实例进行数据回滚，从而让第一节点上的每一个服务实例可以以第一功能参数对外提供服务。

在一种可能的实现方法中，所述得到第三功能参数之后，所述方法还包括：所述发布端在确定所有节点的所有服务实例升级成功后，通过第三配置文件对系统数据库中的功能参数进行更改，得到第四功能参数；所述发布端在确定升级失败时，通过第三回滚配置文件，恢复到所述第三配置文件对所述系统数据库进行更新之前的所述第三功能参数。

基于该方案，发布端根据第三配置文件对系统数据库中的功能参数进行修改，得到第四功能参数；在确认全部节点上的全部服务实例彼此之间配合的程度达不到第三配置文件的预设效果时，可以在第一时间内根据第三回滚配置文件对全部节点上的全部服务实例进行数据回滚，从而让全部节点上的每一个服务实例可以以第二功能参数对外提供服务。

第三方面，本发明实施例提供一种版本升级装置，该装置包括：停止单元，用于在第一版本标记为升级态时，停止第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；更新单元，用于将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；运行单元，用于启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

基于该方案，在确认第一服务实例为需要版本升级的状态时，第一节点将停止第一服务实例对外所提供的一切服务，并将系统数据库中的第一功能参数刷新至第一服务实例的第一本地内存中，当第一节点启动第一服务实例后，则第一服务实例可以根据第一本地内存中的第一功能参数重新开始对外提供服务。该方案，通过在服务实例中设置本地内存，可以确保仅通过对第一节点上的第一服务实例先进行版本升级，而非对第一节点上的全部服务实例以及分布式系统中的全部节点的全部服务实例都进行版本升级，这种版本升级方法更为灵活，可以将版本升级失败所带来的风险降到最低程度；此外，本方案通过功能参数的方式实现各业务功能，而非现有技术中依靠运行代码来实现业务功能，因而本方案可通过第一配置文件更新功能参数从而实现版本升级，避免了现有技术中通过更改代码来完成升级的复杂性。

在一种可能的实现方法中，所述更新单元，具体用于：通过缓存定义表确定需要更新至所述第一本地内存中的各功能参数表；所述缓存定义表记录有各功能参数表的属性信息；所述功能参数表记录有设定功能的各功能参数；从所述系统数据库中获取所述各功能参数表并加载至所述第一本地内存。

基于该方案，通过缓存定义表确定需要更新至本地内存中的功能参数表，可以快速实现系统数据库至本地内存的刷新，使得第一服务实例在重新启动后，可以用更新后的功能参数表对外提供服务。

在一种可能实现的方法中，所述运行单元，具体用于：所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表；所述第一服务实例根据所述第一功能参数表在所述缓存定义表中的属性信息，确定通过所述第一本地内存中的所述第一功能参数表来执行所述服务请求。

基于该方案，在第一服务实例启动后，接收到前端发送的服务请求，在确定缓存定义表中具有所述服务请求对应的第一功能参数表，从而可以通过第一服务实例的第一本地内存中的第一功能参数表来对所述服务请求作出响应，合理区分系统数据库和本地内存的业务，减轻了对系统数据库的压力，也加快了服务请求的处理。

在一种可能的实现方法中，所述运行单元，具体用于：通过拦截线程确定所述服务请求需调用所述第一功能参数表。

基于该方案，通过设置拦截线程，则对于待处理的请求服务请求是通过服务实例的本地内存还是通过系统数据库来处理，可以做出有拦截线程做出判断；此外，通过所设置的拦截线程，可以确定用于对待处理服务请求作出响应的功能参数表。

在一种可能的实现方法中，所述更新单元，还用于：通过轮询线程确定所述系统数据库中的功能参数表发生了更改。

基于该方案，通过设置轮询线程，可以实现周期性地检查第一服务实例的第一本地内存中的功能参数表是否与系统数据库中的功能参数表保持一致性，并且在确定两者不一致时，轮询线程会将系统数据库中的功能参数表更新至第一服务实例的第一本地内存中。

在一种可能的实现方法中，所述运行单元，还用于：在第二版本标记为非升级态时，从第二服务实例的第二本地内存中获取第二功能参数从而运行所述第二服务实例；所述第二版本标记用于指示所述第二服务实例是否需要升级；所述第二功能参数是所述系统数据库中通过所述第一配置文件更改前的记录。

基于该方案，在确认第二服务实例为不需要版本升级的状态时，第一节点仅需要从第二服务实例的第二本地内存中获取第二功能参数，以使得第二服务实例依然可以以旧版本的程序来正常对外提供服务，该方法保证了在对第一服务实例进行版本升级过程中，由于第一节点会短暂地将第一服务实例对外服务的行为停掉，因此调度系统可以将预设的准备调入第一服务实例的用户流量调入依然正常运作的第二服务实例上，让第二服务实例对用户提供服务，从而保证了在第一服务实例升级过程中，分布式系统重要依然可以有能正常运作的第二服务实例对外提供服务，将数据库变更脚本影响的交易范围和用户量最小化。

在一种可能的实现方法中，所述运行单元，还用于：在所述第一服务实例运行失败后，暂停所述第一服务实例，并将所述系统数据库中的第二功能参数更新至所述第一本地内存中；所述第二功能参数是根据第一回滚配置文件将所述系统数据库恢复至所述第一功能参数之前的记录。

基于该方案，在对第一服务实例进行版本升级的过程中，由于某些因素的存在将会导致第一节点上的第一服务实例无法如期、正常地实现由旧版本的程序升级到新版本的程序，也即第一服务实例在版本升级后会发生运行失败的情况，对此，本申请中仅需要通过数据回滚的操作即可以实现由新版本的程序恢复至旧版本的程序，从而保证了版本无法升级成功的第一服务实例依然可以用旧版本的程序来对外提供服务。

在一种可能的实现方法中，所述第一本地内存按照设定的表结构存储所述系统数据库中的功能参数表。

基于该方案，通过在第一服务实例的第一本地内存中存储系统数据库中的功能参数表，则可以根据第一服务实例本地的数据内容来对外提供服务；另一方面，在服务实例进行版本升级过程中，由于服务实例本地内存中可以存储系统数据库中的功能参数表，从而对于一些需要版本升级的服务实例(第一服务实例)来说，它/它们可以用系统数据库中最新的功能参数表来对外提供服务；而对于一些不需要版本升级的服务实例(第二服务实例)来说，它/它们可以继续使用自己本地内存的未更新的功能参数表来对外提供服务，从而可以实现对第一节点上的全部服务实例进行批量升级的目的。

在一种可能的实现方法中，所述第一节点为分布式系统中的多个节点中的任一个；所述运行单元，具体用于：各服务实例按照第一规则进行批量升级；所述第一规则是针对服务实例的升级顺序；按照第二规则对第二节点进行升级；所述第二节点为所述分布式系统中除所述第一节点外的任一节点；所述第二规则是针对节点的升级顺序。

基于该方案，由于分布式系统中存在多个节点，因此先通过对分布式系统中的某一测试节点进行率先升级，从而可以在该测试节点的版本升级效果良好的情况下，实现对分布式系统中的除去该测试节点的其余节点都进行版本升级，其中，在对该测试节点进行率先升级的过程中，又是可以先通过对其上的第一服务实例进行版本升级。以上对分布式系统进行版本升级的整个流程，可以将版本升级的风险降到最大，影响的范围也最小。

在一种可能的实现方法中，所述更新单元，还用于：在所有服务实例按照所述第一配置文件升级成功后，将所述系统数据库中的第三功能参数更新至所述所有服务实例各自的本地内存中；所述第三功能参数是通过第二配置文件设置的，所述第二配置文件用于对与服务实例无依赖关系的功能参数的升级。

基于该方案，当第一节点上的全部服务实例都实现了版本升级后，通过再次执行将系统数据库中的第三功能参数刷新至第一节点上的全部服务各自的本地内存中，则对于第一节点上的全部服务实例，它们彼此之间可以实现更好的配合，来对外提供服务。

在一种可能实现的方法中，所述更新单元，还用于：在所有节点的所有服务实例按照所述第一配置文件和所述第二配置文件升级成功后，将所述系统数据库中的第四功能参数更新至所述所有服务实例各自的本地内存中；所述第四功能参数是通过第三配置文件设置的，所述第三配置文件用于对与上下游服务实例有依赖关系的功能参数的升级。

基于该方案，当分布式系统中的全部节点中的每一个节点上的全部服务实例都按照第一配置文件和第二配置文件升级成功后，通过再次将系统数据库中的第四功能参数刷新至全部节点中的每一个节点上的全部服务实例，从而对于分布式系统的全部节点，它们彼此之间可以实现更好的配合，来对外提供服务。

第四方面，本发明实施例提供一种版本升级装置，该装置包括：功能参数生成单元，用于通过第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；升级态设置单元，用于根据第一规则，设置第一节点的第一版本标记为升级态；所述第一版本标记用于指示所述第一服务实例是否需要升级；功能参数复原单元，用于在确定所述第一服务实例升级失败时，通过第一回滚配置文件，恢复到所述第一配置文件对所述系统数据库进行更新之前的第二功能参数。

基于该方案，发布端根据第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；在确认第一服务实例版本升级失败后，发布端根据第一回滚配置文件，将系统数据库的功能参数修改为本次版本未升级之前的功能参数，以及将第一服务实例的第一本地内存中的第一功能参数也刷新为本次版本未升级之前的功能参数，从而保证了在第一节点上的第一服务实例升级失败后，可以在第一时间内对版本升级失败的数据进行回滚，让第一服务实例可以继续以旧版本的程序对外提供服务。

在一种可能实现的方法中，所述功能参数生成单元，还用于：在确定所述第一节点的所有服务实例升级成功后，通过第二配置文件对系统数据库中的功能参数进行更改，得到第三功能参数；所述功能参数复原单元，还用于：在确定升级失败时，通过第二回滚配置文件，恢复到所述第二配置文件对所述系统数据库进行更新之前的所述第一功能参数。

基于该方案，发布端根据第二配置文件对系统数据库中的功能参数进行修改，得到第三功能参数；在确认第一节点上的全部服务实例彼此之间配合的程度达不到第二配置文件的预设效果时，可以在第一时间内根据第二回滚配置文件对第一节点上的全部服务实例进行数据回滚，从而让第一节点上的每一个服务实例可以以第一功能参数对外提供服务。

在一种可能实现的方法中，所述功能参数生成单元，还用于：在确定所有节点的所有服务实例升级成功后，通过第三配置文件对系统数据库中的功能参数进行更改，得到第四功能参数；所述功能参数复原单元，还用于：在确定升级失败时，通过第三回滚配置文件，恢复到所述第三配置文件对所述系统数据库进行更新之前的所述第三功能参数。

基于该方案，发布端根据第三配置文件对系统数据库中的功能参数进行修改，得到第四功能参数；在确认全部节点上的全部服务实例彼此之间配合的程度达不到第三配置文件的预设效果时，可以在第一时间内根据第三回滚配置文件对全部节点上的全部服务实例进行数据回滚，从而让全部节点上的每一个服务实例可以以第三功能参数对外提供服务。

第五方面，本发明实施例提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如第一方面和第二方面任一所述的方法。

第六方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如第一方面和第二方面任一所述的方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种分布式系统的架构示意图；

图2为本发明实施例提供的一种版本升级方法；

图3为本发明实施例提供的另一种版本升级方法；

图4为本发明实施例提供一种银行的后台分布式架构；

图5为现有技术的一种对服务实例进行灰度发布的方案；

图6为本发明实施例提供的一种正常版本(上线时间比较充裕)的发布流程示意图；

图7为发明实施例提供的一种紧急版本(上线时间比较紧急)的发布流程示意图；

图8为本发明实施例提供的一种版本升级装置；

图9为本发明实施例提供的另一种版本升级装置。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

如图1所示，为本发明实施例提供的一种分布式系统的架构示意图，比如该架构可以被用于部署分布式存款核心系统。

其中，该分布式系统中包括多个DCN(Data Center Node，数据中心节点)，每一个DCN拥有一个属于自己的DB(Database System，数据库系统)，这些DCN上的DB的结构和参数基本一致。通过在DB中设置功能参数表，然后结合通用代码，就可以实现对待处理的服务请求进行处理的目的。相比于现有技术中，在对系统的版本进行升级时，不仅要求需要对DB中的数据库表进行修改，还要求对根据数据库表对外提供服务时的运行代码进行同步的修改，然后需要重新部署以及重启系统，才能使得本次的版本升级得以实现。而在本发明实施例中，通过使用功能参数表和通用代码的结合方式，当对系统的版本进行升级时，仅需要修改DB中的功能参数表进行修改，修改内容包括增、删、改等内容，并不需要再对通用代码进行修改，以及再重启系统了。

对于任一个DCN，它又包括多个服务实例。

对于每一个服务实例，它拥有一个自己的本地内存，如本发明实施例中以Java虚拟机级缓存为例进行说明。每一个服务实例的Java虚拟机级缓存中存储有该服务实例所在DCN连接的数据库DB中的部分或全部的功能参数表。因此，从理论上来说，基于同一版本的前提条件下，同一个DCN上的每一个服务实例能够对外提供的功能均相同，也就是说，资源允许的前提下，每一个服务实例可以对外提供它上面的全部功能；但从实际角度来说，每一个服务实例具体对外提供什么样的功能，还需要遵循调度系统对它功能的调度，也即，每一个服务实例实际在对外提供服务时，可能常用的也就是全部功能中的一些功能。

基于图1所示的架构示意图，如图2所示，为本发明实施例提供的一种版本升级方法，该方法包括以下步骤：

步骤201，第一节点在第一版本标记为升级态时，停止所述第一节点上的第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；

步骤202，所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；

步骤203，所述第一节点启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

基于该方案，在确认第一服务实例为需要版本升级的状态时，第一节点将停止第一服务实例对外所提供的一切服务，并将系统数据库中的第一功能参数更新至第一服务实例的第一本地内存中，当第一节点启动第一服务实例后，则第一服务实例可以根据第一本地内存中的第一功能参数重新开始对外提供服务。该方案，通过在服务实例中设置本地内存，可以确保仅通过对第一节点上的第一服务实例先进行版本升级，而非对第一节点上的全部服务实例以及分布式系统中的全部节点的全部服务实例都进行版本升级，这种版本升级方法更为灵活，可以将版本升级失败所带来的风险降到最低程度；此外，本方案通过功能参数的方式实现各业务功能，而非现有技术中依靠运行代码来实现业务功能，因而本方案可通过第一配置文件更新功能参数从而实现版本升级，避免了现有技术中通过更改代码来完成升级的复杂性。

在上述步骤201中，结合图1的架构，第一节点可以为分布式存款核心系统中的任一个DCN，作为示例，本发明实施例中令DCN1为第一节点。

参考图1，DCN1上存在N个服务实例，N的取值可以根据实际需要进行设定，作为示例，本发明实施例中令N取值为4，也即DCN1上存在4个服务实例，它们的编号分别记作1、2、3和4。

则上述步骤201中的第一服务实例可以为DCN1上的任一个服务实例，也可以为DCN1上的一些服务实例，对此，本发明不做限定。作为示例，本发明实施例中以第一服务实例仅为服务实例1为例进行说明。

当DCN1检测到服务实例1的第一版本标记为升级态时，也即说明本次版本升级过程中，对分布式存款核心系统中的DCN1上运行着的服务实例1率先进行版本升级，则DCN1会停止服务实例1对外提供服务的行为。

设本次版本升级涉及到一些功能参数的变更，这些变更信息被记录在第一配置文件中，在本发明实施例中，第一配置文件可以记为BeforeSQL，通过部署BeforeSQL脚本，则在DCN1连接的数据库DB1中，其中原先的功能参数已经被第一功能参数迭代，第一功能参数是DB1中通过BeforeSQL进行更改后的功能参数。

因此，在上述步骤202中，DCN1通过将它连接的DB1中的记录的第一功能参数更新至服务实例1的Java虚拟机级缓存中，从而在服务实例1被重新启用后，它可以以最新的功能参数，也即第一功能参数对外提供服务。

在上述步骤203中，DCN1启用服务实例1，从而可以让服务实例1以第一功能参数对外提供服务。

举个例子，如果本次版本升级过程中，是在原先版本所具有的功能的基础上，新增了一个全新的功能，那么这个全新的功能会被记录在BeforeSQL脚本中；通过在DCN1连接的DB1中部署BeforeSQL脚本，如果脚本一切正常，那么DCN1连接的DB1则会新增这项全新的功能，具体可以表现为DB1中的功能参数表的表数量加1。接下来，通过DCN1对它上面的服务实例1执行对外停止服务的操作，并将它连接的DB1中的部分或者全部的功能参数更新至服务实例1的Java虚拟机级缓存中，从而在服务实例1被DCN1重新启用后，服务实例1不仅可以提供原先已有的旧版本的功能，还能对外提供这次版本升级所新增的全新的功能了。本实施例以JVM(Java Virtual Machine，Java虚拟交换机)为例，具体本地内存的实现方式结合具体的应用环境来进行设定。

可选的，所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中，包括：所述第一节点通过缓存定义表确定需要更新至所述第一本地内存中的各功能参数表；所述缓存定义表记录有各功能参数表的属性信息；所述功能参数表记录有设定功能的各功能参数；所述第一节点从所述系统数据库中获取所述功能参数表并加载至所述第一本地内存。

可选的，所述第一本地内存按照设定的表结构存储所述系统数据库中的所有功能参数表。

如前述的由多个DCN共同构成的分布式存款核心系统中，设对于DCN1，它所连接的DB1中存储有101张表，对于其中的100张表，它们需要被配置为功能参数表；对于其中的1张表，并不需要被配置为功能参数表。

如对于DB1中的一张表，该表的表名为“dp_limit_rule”，表中文名称为“限额规则定义”，它所具有的功能参数可以参考表1：

表1

同理，对于DB1中除去表名为“dp_limit_rule”以及不需要被配置成功能参数表的以外的表，它们各自具有的功能参数可以根据实际的需求进行设置。

在本发明实施例中，在服务实例初始化启动时，需加载缓存定义表到JVM内存中，并将与缓存定义表对应的功能参数表加载到JVM本地缓存数据区中，以便后续读取数据时直接从JVM本地缓存数据区中读取，而不用从数据库中读取。

具体实施时，首先读取预设的缓存定义表，该缓存定义表中记录有基于数据库中配置的功能参数表的各属性信息，各属性信息可以包括：需要缓存的功能参数表的名、表的中文描述、缓存级别、执行前处理标志、登记变更日志标志、检查参数标志以及处理参数标志。缓存定义表中的属性信息可以根据实际运行需要进行设定。

具体地，缓存定义表ksys_tabctl的结构如表2所示：

表2

列名	类型	可否为空	主键	备注
					biaoming	varchar(30)	NO	PRI	需要缓存的功能参数表的名
biaozwmc	varchar(500)	YES		表的中文描述
					huancjib	varchar(20)	YES		缓存级别
qianclbz	varchar(1)	YES		执行前处理标志
					denjbgrz	varchar(1)	YES		登记变更日志标志
jiancshu	varchar(1)	YES		检查参数标志
					chulcshu	varchar(1)	YES		处理参数标志

比如，对于前述的功能参数表“dp_limit_rule”，其在缓存定义表中的配置如下：

biaoming: dp_limit_rule

biaozwmc: 限额规则定义

huancjib: global

qianclbz: 1

denjbgrz: 0

jiancshu: 1

chulcshu: 1

同理，对于DB1中除去表名为“dp_limit_rule”以及不需要被配置成功能参数表的以外的表，当它们被配置为Java虚拟机级缓存时，所执行的配置可以参考表名为“dp_limit_rule”的功能参数表的过程。

下面以一个具体的例子说明如何在服务实例JVM本地缓存数据区中缓存数据库中的功能参数表。

首先，当对服务实例1初始化启动时，服务实例1会将DB1中的ksys_tabctl中对应的所有记录组成一个链表，然后按照链表中的每条记录获取表名作为key和ksys_tabctl域对象作为value组成一个缓存定义哈希表CacheDefMap，并保存在服务实例1的Java虚拟机级缓存中。如表3所示，为本发明实施例提供的一张缓存定义哈希表CacheDefMap。

表3

Key	Value
		Name1	ksys_tabctl1
Name2	ksys_tabctl2
		Name3	ksys_tabctl3
……	……
		Name100	ksys_tabctl100

然后，通过对链表中的记录进行迭代，将huancjib(缓存级别)为global和qianclbz(执行前处理标志)为1的记录进行处理，也即按照记录中的表名从DB1中获取对应的功能参数表，并将功能参数表的表名和表中的主键PRI以及功能参数表的域对象组成一个缓存数据哈希表GlobalCacheMap。该缓存数据哈希表GlobalCacheMap为一个二级哈希结构的哈希表，它的key为DB1中的功能参数表的表名，它的value通过又一个缓存哈希表进行表示。其中，key为表中的主键PRI，如主键PRI可以为表1中的六个字段中的任一个，具体可以由工作人员进行设定，从而被选定的字段构成key；value是功能参数表的域对象，如表1中除去主键PRI的字段的其他部分构成value，并将该缓存数据哈希表GlobalCacheMap保存在服务实例1的Java虚拟机级缓存中。

从而，当对服务实例2、服务实例3和服务实例4执行如服务实例1相同的操作，则服务实例2、服务实例3和服务实例4各自的Java虚拟机级缓存中所存储的内容与服务实例1相同。

可选的，所述通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例，包括：所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表；所述第一服务实例根据所述第一功能参数表在所述缓存定义表中的属性信息，确定通过所述第一本地内存中的所述第一功能参数表来执行所述服务请求。

当服务实例1被重新启动后，接收到前端发送的服务请求时，根据服务请求中的参数到服务实例1的Java虚拟机级缓存中的缓存定义哈希表CacheDefMap中，查看是否有对应的key；如果有，则检查key对应的value对象——ksys_tabctl域对象中各属性信息；根据属性信息确定需要通过本地内存中的功能参数表来执行服务请求；具体来说是在处理参数标志为1时，则表示通过服务实例1的Java虚拟机级缓存来处理。处理参数标志的具体值可根据实际应用来设定。同时，也可以查看登记变更日志标志和检查参数标志若登记变更日志标志为1时，则记录本次的服务请求，若为空值或者0，则无需记录本次的服务请求；若检查参数标志为1时，则检查输入参数是否正确，若检查参数标志为空值或者0，则无需检查输入参数，直接进入处理参数环节。

具体来说，上述过程可以通过所述第一节点中的拦截线程确定所述服务请求需调用所述第一功能参数表，具体为：拦截线程确定要服务请求对应的方法上是否有设定标志，即执行该服务请求的代码中增加了设定标志，用于指示需要跳转到缓存定义表确定是否需要获取执行该方法的功能参数表。在处理参数标志为1时，则表示通过服务实例1的Java虚拟机级缓存来处理，具体来说是根据记录中的表名查看缓存数据哈希表GlobalCacheMap中确定是否有对应的key，如果有，则将key对应的value获取对应的功能参数表的域对象返回至设定标志的位置，从而继续执行该服务请求对应的方法。

可选的，所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中之前，还包括：所述第一节点的轮询线程确定所述系统数据库中的功能参数表发生了更改。

在服务实例1启动时，则服务实例上的轮询线程随即被启动，轮询线程会读取DB1中的缓存计数器的值；当轮询线程发现缓存计数器发生变化，则轮询线程将DB1中的功能参数表刷新至服务实例1的Java虚拟机级缓存中。

可选的，所述第一节点在第二版本标记为非升级态时，从第二服务实例的第二本地内存中获取第二功能参数从而运行所述第二服务实例；所述第二版本标记用于指示所述第二服务实例是否需要升级；所述第二功能参数是所述系统数据库中通过所述第一配置文件更改前的记录。

如前述的例子，在DCN1上的服务实例1被定义为第一服务实例后，那么DCN1上的除去服务实例1以外的其他服务实例可以为定义为第二服务实例，如在本发明实施例中，服务实例2、服务实例3和服务实例4均为第二服务实例。在DCN1确认第二服务实例的版本标记为非升级态时，也即本次在DCN1上的版本升级目前仅涉及服务实例1，但还不涉及服务实例2、服务实例3和服务实例4，那么DCN1并不会对服务实例2、服务实例3和服务实例4执行停止服务的操作，同时服务实例2、服务实例3和服务实例4各自的Java虚拟机级缓存中依然保存的是旧版本的应用对应的功能参数，也即第二功能参数，从而DCN1会从服务实例2、服务实例3和服务实例4各自的Java虚拟机级缓存中获取第二功能参数，以让这些服务实例继续对外提供服务。

可选的，所述第一节点在所述第一服务实例运行失败后，暂停所述第一服务实例，并将所述系统数据库中的第二功能参数更新至所述第一本地内存中；所述第二功能参数是根据第一回滚配置文件将所述系统数据库恢复至所述第一功能参数之前的记录。

在版本升级过程中，由于各种因素的影响，极容易导致版本涉及失败。比如在DCN1对应的数据库中部署BeforeSQL脚本时，由于脚本中存在错误，导致在数据库中无法生成一项全新的功能参数对应的数据库表，这说明本次版本升级发生异常。对于这个结果，本发明实施例中提出通过第一回滚配置文件的方法予以解决。在本发明实施例中，第一回滚配置文件可以记为BeforeRollbackSQL，通过部署BeforeRollbackSQL脚本，从而可以快速地让DCN1对应的数据库中的数据库表恢复至原先旧版本时的数据库表。

进一步地，设可以在DCN1对应的数据库中成功部署BeforeSQL脚本，当DCN1将数据库中第一功能参数刷新至服务实例1的本地内存，并重新启用服务实例1后，发现有用户针对全新的功能做出请求时，而服务实例1却无法对该请求作出响应，这说明并未对服务实例1实现成功版本升级。对于这个结果，本发明实施例中提供通过第一回滚配置文件的方法予以解决。通过部署BeforeRollbackSQL脚本，可以快速地让DCN1对应的数据库中的数据库表恢复至原先旧版本时的数据库表，DCN1通过再次将数据库中旧版本时的数据库表刷新至服务实例1的本地内存中，在服务实例1被重新启用后，它可以继续以旧版本的功能对外提供服务。

可选的，所述第一节点为分布式系统中的多个节点中的任一个；所述分布式系统按照设定规则进行系统升级，包括：所述第一节点上的各服务实例按照第一规则进行批量升级；所述第一规则是针对服务实例的升级顺序；所述第一节点升级后，按照第二规则对第二节点进行升级；所述第二节点为所述分布式系统中除所述第一节点外的任一节点；所述第二规则是针对节点的升级顺序。

前面的例子中，已经实现了对分布式系统中的DCN1上的服务实例1进行版本升级的操作，也即首先对服务实例1进行版本升级，随后可以依次对除去服务实例1以外的其他服务实例进行版本升级，具体的升级过程可以参考服务实例1。本发明实施例中的先对DCN1上的一部分服务实例(如服务实例1)进行版本升级，在确认这一部分服务实例版本升级后的效果良好后，再对余下一部分服务实例(服务实例2、服务实例3和服务实例4)进行版本升级，这属于第一规则(针对服务实例而言)。

在对DCN1上的全部服务实例进行版本升级后，并在确认全部服务实例版本升级后的效果为良好，则对分布式系统中的除去DCN1的其他DCN都进行如DCN1的版本升级操作，这属于第二规则(针对节点而言)。

可选的，所述第一节点在所有服务实例按照所述第一配置文件升级成功后，将所述系统数据库中的第三功能参数更新至所述所有服务实例各自的本地内存中；所述第三功能参数是通过第二配置文件设置的，所述第二配置文件用于对与服务实例无依赖关系的功能参数的升级。

前述的例子中，参考对服务实例1进行版本升级的方法步骤，当对DCN1上的除去服务实例1以外的其他服务实例都执行了相同的版本升级操作，且确认DCN1上的每一个服务实例皆可以以第一功能参数对外提供服务时，DCN1通过在数据库中部署第二配置文件，其中，第二配置文件在本发明实施例中记为AfterSQL，通过部署AfterSQL脚本，对数据库中的一些数据库表进行更改，从而将数据库表中的第一功能参数迭代为第三功能参数，最后DCN1通过将第三功能参数刷新至DCN1上的全部服务实例各自的Java虚拟机级缓存中，从而DCN1上的每一个服务例都可以以第三功能参数对外提供服务。

可选的，所述第一节点在所有节点的所有服务实例按照所述第一配置文件和所述第二配置文件升级成功后，将所述系统数据库中的第四功能参数更新至所述所有服务实例各自的本地内存中；所述第四功能参数是通过第三配置文件设置的，所述第三配置文件用于对与上下游服务实例有依赖关系的功能参数的升级。

前述的例子中，在DCN1上的每一个服务例都可以以第三功能参数对外提供服务后，因此参考对DCN1上的全部服务实例进行版本升级的操作，可以在分布式存款核心系统中的除去DCN1以外的其他节点上执行如对DCN1的版本升级操作，并在分布式系统中每一个节点中每一个服务实例皆可以以第三功能参数对外提供服务后，通过在包括DCN1在内的所有节点的各自连接的数据库中部署第三配置文件，其中，第三配置文件在本发明实施例中记为GlobalAfterSQL，通过部署GlobalAfterSQL脚本，对数据库中的一些数据库表进行更改，从而将数据库表中的第三功能参数迭代为第四功能参数，最后每一个节点通过将第四功能参数刷新至各自节点上的全部服务实例各自的Java虚拟机级缓存中，从而DCN1上的每一个服务例都可以以第四功能参数对外提供服务。

需要说明的是，在对数据库表的功能参数进行修改时，包括对数据库表结构的修改和对数据库表数据的修改。具体表现为：

对于BeforeSQL脚本，针对DDL(Data Definition Language，数据库定义语言，简写为DDL)的BeforeScriptSQL配置文件和针对DML(Data Manipulation Language，数据操纵语言，简写为DML)的BeforeDataSQL配置文件；

对于AfterSQL脚本，针对DDL的AfterScriptSQL配置文件和针对DML的AfterDataSQL配置文件；

对于GlobalAfterSQL脚本，针对DDL的GlobalAfterScriptSQL配置文件和针对DML的GlobalAfterDataSQL配置文件。

如图3所示，为本发明实施例提供的另一种版本升级方法，该方法包括以下步骤：

步骤301，发布端通过第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；

步骤302，所述发布端根据第一规则，设置第一节点的第一版本标记为升级态；所述第一版本标记用于指示所述第一服务实例是否需要升级；

步骤303，所述发布端在确定所述第一服务实例升级失败时，通过第一回滚配置文件，恢复到所述第一配置文件对所述系统数据库进行更新之前的第二功能参数。

基于该方案，发布端根据第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；在确认第一服务实例版本升级失败后，发布端根据第一回滚配置文件，将系统数据库的功能参数修改为本次版本未升级之前的功能参数，以及将第一服务实例的第一本地虚拟机内存中的第一功能参数也刷新为本次版本未升级之前的功能参数，从而保证了在第一节点上的第一服务实例升级失败后，可以在第一时间内对版本升级失败的数据进行回滚，让第一服务实例可以继续以旧版本的程序对外提供服务。

参考图1的架构示意图，在步骤301中，发布端根据BeforeSQL脚本对DCN1对应的数据库中的功能参数进行更改。比如本次版本升级涉及到一个全新的功能，因此BeforeSQL脚本中会详细配置有这个全新的功能的信息，然后发布端通过将BeforeSQL脚本部署到数据库中，在确认BeforeSQL脚本在数据库中成功生效后，那么数据库中的功能参数表的表数量将会增加1。

在步骤302中，当发布端对DCN1对应的数据库中的功能参数进行更改后，得到第一功能参数后，发布端会依据批量更新的规则，对DCN1上的服务实例进行版本更新。在更新之前，发布端会将一批率先更新的服务实例确定为第一服务实例，并将第一服务实例的版本标记设置为升级态。比如发布端可将DCN1上的服务实例1作为第一服务实例，因此发布端会将服务实例1的版本标记设置为升级态。

在步骤303中，在DCN1启用版本升级后的服务实例1，欲让它以最新版本的应用对外提供服务时，但是当有用户发出上述的全新的功能的对应的请求时，服务实例1无法对该请求作出响应后，则发布端可以确定服务实例的版本升级结果为升级失败，那么这时候，发布端通过部署BeforeRollbackSQL脚本，从而可以DCN1对应的数据库中的功能参数恢复到BeforeSQL脚本被部署之前的数据库中原先存在的功能参数，也即第二功能参数。

可选的，所述发布端在确定所述第一节点的所有服务实例升级成功后，通过第二配置文件对系统数据库中的功能参数进行更改，得到第三功能参数；所述发布端在确定升级失败时，通过第二回滚配置文件，恢复到所述第二配置文件对所述系统数据库进行更新之前的所述第一功能参数。

设DCN1上的全部服务实例在版本升级后都可以以第一功能参数对外提供服务后，发布端根据AfterSQL脚本对DCN1对应的数据库中的第一功能参数进行更改。比如涉及到删除一项原有的旧功能，因此AfterSQL脚本中会详细配置有如何删去这项原有的旧功能的信息，然后发布端通过将AfterSQL脚本部署到数据库中。在确认AfterSQL脚本在数据库中成功生效后，则数据库中的功能参数表的数量与最开始的功能参数表的数量持平。

在AfterSQL脚本在数据库中成功生效后，DCN1通过将第三功能参数刷新至每一个服务实例的各自的本地虚拟机内存中，若DCN1上的任一个服务实例在对外提供服务时，依然能够对外提供所删除的那项原有的旧功能，因此发布端可以确定AfterSQL脚本在部署过程中出现异常，对于这种情况，发布端通过部署AfterRollbackSQL脚本，从而可以让DCN1连接的数据库中的功能参数恢复到AfterSQL脚本被部署之前的数据库中原先存在的功能参数，也即第一功能参数。

可选的，在得到第三功能参数之后，所述发布端在确定所有节点的所有服务实例升级成功后，通过第三配置文件对系统数据库中的功能参数进行更改，得到第四功能参数；所述发布端在确定升级失败时，通过第三回滚配置文件，恢复到所述第三配置文件对所述系统数据库进行更新之前的所述第三功能参数。

由于DCN1处于分布式系统这样一个大环境条件下，因此参考对DCN1执行BeforeSQL脚本以及AfterSQL脚本的操作，对分布式系统中的除去DCN1以外的其他节点做同样的操作，还需要实现分布式系统中多个节点(包括同一个节点上的不同服务实例以及不同节点上的不同服务实例)之间的功能配合，本发明实施例中通过部署GlobalAfterSQL脚本，对分布式系统中的每一个节点对应的数据库中的第三功能参数进行修改，得到修改后的第四功能参数。从而当每一个节点将数据库中的第四功能参数刷新至每一个服务实例的各自的本地内存中，则分布式系统在对外提供服务时，不同服务实例之间可以更好地进行配合。

当不同服务实例之间的配合效果达不到预设的配合效果，则有理由认为本次部署的GlobalAfterSQL脚本发生异常，从而发布端通过部署GlobalAfterRollbackSQL脚本，将数据库中的功能参数恢复至第三功能参数。

接下来，将在一个具体的例子中描述本发明的方案。

如图4所示，为本发明实施例提供一种银行的后台分布式架构。在该架构中，按照不同的逻辑区域可以划分为多个数据节点，比如DCN1，DCN2，…，DCNn和特殊的逻辑节点ADM。每个节点，无论是DCN或ADM，都部署了多个服务实例，不同的服务实例按照实际需求可以共享同一个数据库，这样每个节点就可以作为一个独立的单元来对外提供服务。

存款核心系统按照不同的功能模块共划分为6个子系统，联机交易子系统，批量交易子系统，ADM联机交易子系统，ADM批量交易子系统，小总账子系统和控制台子系统，其中ADM联机交易子系统和ADM批量交易子系统是部署在ADM上，其他子系统是部署在各个DCN上。在DCN上，联机交易子系统和批量交易子系统共用同一个DB。在ADM上，ADM联机交易子系统和ADM批量交易子系统共用同一个DB，小总账子系统和控制台子系统共用同一个DB，所有的DB的数据库结构和参数基本一致。

如图5所示，为现有技术的一种对服务实例进行灰度发布的方案，主要可以概括为以下四个步骤：

1.将整个主机节点上的所有的服务实例进行停止服务处理，也就是不再对外提供服务了；

2.修改此次灰度发布中功能模块所关联的数据库的表结构或者表数据；

3.对主机节点上所有的服务实例进行版本变更，进行新的代码模块的更新；

4.启动主机节点上的所有的服务实例，也就是重新对外提供服务。

本发明实施例所提出的灰度发布方案，在分布式环境下，以其中一个节点——DCN1为代表，来描述灰度发布的流程。具体地，按照时间轴分成以下八个步骤：

1.部署BeforeSQL脚本，对这次版本涉及到的数据库相关表结构进行变更，

它的作用如下：

a)一方面是对应着马上部署的服务实例的相关功能，这些功能依赖这些数据库的提前变更；

b)另一方面针对已有功能的数据变更，先放在BeforeSQL里去做可以启到有异常能及时发现，避免后面应用部署之后出现异常导致的大面积回滚，做到发布时间提前化、异常影响交易范围最小化。

2.如果在上一步中，系统出现异常，使用BeforeRollbackSQL快速地回滚已发布的数据变更，这样可以做到即便出现异常对应用也无影响。

3.对DCN1上的服务实例分批进行版本变更。

4.如果在上一步中，如果因版本变更导致系统出现异常，将已变更的实例暂停服务，回滚服务实例，使用BeforeRollbackSQL回滚已发布的数据变更。

5.部署AfterSQL脚本，它的作用是跟BeforeSQL脚本相反，跟服务实例之间无依赖，通过变更表结构更改服务实例的相关功能，同样保证了变更前后对服务实例是无影响的，避免影响线上交易。

6.如果在上一步中，系统出现异常，使用AfterRollbackSQL快速地回滚已发布的数据变更，这样可以做到即便出现异常对应用也无影响。

7.部署GlobalAfterSQL脚本，它的作用是在一些场景下，上下游系统逻辑依赖存款核心子系统中某些功能，对这些功能涉及到的数据进行变更时，放在GlobalAfterSQL里统一处理，避免影响到其他的上下游系统。

8.如果在上一步中，系统出现异常，使用GlobalAfterRollbackSQL快速地回滚已发布的数据变更，这样可以做到即便出现异常对应用也无影响。

通过以上描述，对比本发明实施例所提出的灰度发布方案和现有的灰度发布的技术方案，有如下的不同：

首先，本发明实施例所提出的灰度方案针对的是分布式架构下整个服务集群的变更，它涉及到多个DCN，多个数据库以及多个服务实例，现有的灰度发布方案是无法满足这种架构下的灰度发布的。

举个例子，就第一步停服来说，现有的技术方案无法同时将所有的DCN上的服务实例进行停服处理。当DCN的数量很庞大涉及的服务实例很多时，同时将所有的服务实例停止对用户的产品体验以及整个银行的金融产品的安全造成了无法想象的风险。

其次，本发明实施例所提出的技术方案中，除了第3步需要分批对服务实例进行停服变更(同现有技术的第3步类似，因为要对服务实例做版本变更，停止服务是必需的)，而其余的第1，2，4，5，6，7，8步均不涉及到对服务实例进行停止服务处理。对比本发明实施例所提出方案中的第3步跟传统方案中的第3步，本发明示例中将服务实例停止的数量做了极大地优化，由全部实例改成分批的去处理，也就是说同一时间，虽然有的服务实例已停止，但是可以由这个DCN上的其他未停止的服务实例来对外提供服务。整个方案极大地减少了在整个灰度发布周期内集群对外服务不可用的时间，最小化了在灰度发布期间用户的交易影响范围。

然后，本发明实施例方案中的第1、5、7步对数据库进行数据变更时与现有技术方案中的第2步是不同的。对比现有技术在通过SQL配置文件做数据修改时，无法做缓存的。它们做缓存时只能针对DML语句中的查询结果做缓存，把查询的结果缓存在内存中，而无法对插入、更新和删除操作做缓存。

举个例子，现有的技术方案再对限额模块相关表的数据进行修改时，先插入一条数据，这条数据是无法及时生效的，现有的方案都是在代码中定义或者一个xml文件去配置，所以要修改限额模块这部分的代码或者相关的xml文件，然后重新部署及重启系统，才能使该数据生效。在本发明实施例提出的方案中，通过上述的本地Java虚拟机级缓存技术，被设计成缓存的表，无论对这个表做了任何操作，包括增加、删除和修改，在技术上都可以手动刷新缓存使得对该表的操作生效。也就是说如果想修改服务实例上某个模块的功能，找到与这个模块功能相互对应的表，通过修改与之关联的表的结构和对应的数据使得这个功能生效，无需再更改该模块的代码、重新发布应用和启动服务实例。在技术上与现有的技术方案中区别是，当一些表被设计成缓存表后，服务实例上对应模块对该表的调用会被Spring AOP(Aspect Oriented Programming，面向方面的编程框架，简写为AOP)所定义的拦截器拦截。如果该表是缓存表，该模块就会从缓存中读取最新的数据。同时还定义了一个轮询线程，它是每隔一段时间自动触发的，来读取缓存定义表中的全部数据，当它发现缓存已被刷新时，它就会重新从数据库读取所有缓存表的最新数据并重新加载，以供服务实例上的模块使用。

最后，本发明实施例方案中的第2、5、7步对数据进行变更后导致的异常故障对应的处理手段也与现有方案是不同的。当本发明实施例中做完数据变更后，一方面可以通过业务方直接从前端渠道进行交易来观察此次变更数据是否达到预期的结果；另一方面还可以通过运维人员从后端系统通过监控变更模块涉及到的接口服务的一些参数，比如接口调用的成功率、失败率、时延、错误日志等，来观察此次变更数据带来的影响。如果业务人员反馈的结果不理想或者运维人员发现相关的接口服务的参数性能指标出现了下降以及后台出现明显的跟此次变更相关的错误日志，跟现有技术方案不同的是，本发明实施例中无需将应用实例的服务停止，直接部署SQL配置文件相对应的回滚脚本，通过刷新缓存使得回滚脚本中的数据修改，这样可以快速地恢复该模块的交易功能，将此次交易故障的问题给客户带来的影响降到最低。

参考图6，为本发明实施例提供的一种正常版本(上线时间比较充裕)的发布流程示意图。

1、第一天，选取任意一台DCN上的一台联机实例，全部的批量实例、ADM上的一台联机实例，全部的小总账实例、全部的批量实例进行部署。这样做的好处是保证了在部署范围最小化的情况下，日间时对存款核心系统的联机交易进行了新版本功能的灰度，日终时对系统的批量交易和小总账交易进行了灰度。

2、第二天，将第一天发布的DCN上的剩余的联机实例进行新版本的发布。这样做的好处是在第二天发布完成之后，保证了有一个DCN进行了新版本功能的灰度，同时还可以在一个完整的DCN上观察新版本的交易运行情况。

3、第三天，根据前两天部署的DCN的情况，无异常后，再对其他的DCN按照相同的步骤来进行部署，直到所有DCN完成。

参考图7，为发明实施例提供的一种紧急版本(上线时间比较紧急)的发布流程示意图。

对于生产环境上紧急版本(上线时间比较紧急)的发布，整个灰度方案流程还可以按照两天进行处理，整个灰度方案流程如图7所示，与上述三天的方案不同的主要是第一天完成了上述三天方案中的前两天的工作。这样做的好处是保证了在时间很短和保证部署范围最小化的情况下，仍然对一个DCN做了完整的灰度发布，日间时对存款核心系统的联机交易进行了新版本功能的灰度，日终时对系统的批量交易和小总账交易进行了灰度。

基于同样的构思，本发明实施例还提供一种版本升级装置，如图8所示，该装置包括：

停止单元801，用于在第一版本标记为升级态时，停止第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；

更新单元802，用于将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；

运行单元803，用于启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

进一步地，对于该装置，更新单元802，具体用于：通过缓存定义表确定需要更新至所述第一本地内存中的各功能参数表；所述缓存定义表记录有各功能参数表的属性信息；所述功能参数表记录有设定功能的各功能参数；从所述系统数据库中获取所述各功能参数表并加载至所述第一本地内存。

进一步地，对于该装置，运行单元803，具体用于：所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表；所述第一服务实例根据所述第一功能参数表在所述缓存定义表中的属性信息，确定通过所述第一本地内存中的所述第一功能参数表来执行所述服务请求。

进一步地，对于该装置，运行单元803，具体用于：通过拦截线程确定所述服务请求需调用所述第一功能参数表。

进一步地，对于该装置，更新单元802，具体用于：通过轮询线程确定所述系统数据库中的功能参数表发生了更改。

进一步地，对于该装置，运行单元803，还用于：在第二版本标记为非升级态时，从第二服务实例的第二本地内存中获取第二功能参数从而运行所述第二服务实例；所述第二版本标记用于指示所述第二服务实例是否需要升级；所述第二功能参数是所述系统数据库中通过所述第一配置文件更改前的记录。

进一步地，对于该装置，运行单元803，还用于：在所述第一服务实例运行失败后，暂停所述第一服务实例，并将所述系统数据库中的第二功能参数更新至所述第一本地内存中；所述第二功能参数是根据第一回滚配置文件将所述系统数据库恢复至所述第一功能参数之前的记录。

进一步的，对于该装置，所述第一本地内存按照设定的表结构存储所述系统数据库中的功能参数表。

进一步的，对于该装置，所述第一节点为分布式系统中的多个节点中的任一个；运行单元803，具体用于：各服务实例按照第一规则进行批量升级；所述第一规则是针对服务实例的升级顺序；按照第二规则对第二节点进行升级；所述第二节点为所述分布式系统中除所述第一节点外的任一节点；所述第二规则是针对节点的升级顺序。

进一步的，对于该装置，更新单元802，还用于：在所有服务实例按照所述第一配置文件升级成功后，将所述系统数据库中的第三功能参数更新至所述所有服务实例各自的本地内存中；所述第三功能参数是通过第二配置文件设置的，所述第二配置文件用于对与服务实例无依赖关系的功能参数的升级。

进一步的，对于该装置，更新单元802，还用于：在所有节点的所有服务实例按照所述第一配置文件和所述第二配置文件升级成功后，将所述系统数据库中的第四功能参数更新至所述所有服务实例各自的本地内存中；所述第四功能参数是通过第三配置文件设置的，所述第三配置文件用于对与上下游服务实例有依赖关系的功能参数的升级。

如图9所示，为本发明实施例提供的另一种版本升级装置，该装置包括：

功能参数生成单元901，用于通过第一配置文件对系统数据库中的功能参数进行更改，得到第一功能参数；

升级态设置单元902，用于根据第一规则，设置第一节点的第一版本标记为升级态；所述第一版本标记用于指示所述第一服务实例是否需要升级；

功能参数复原单元903，用于在确定所述第一服务实例升级失败时，通过第一回滚配置文件，恢复到所述第一配置文件对所述系统数据库进行更新之前的第二功能参数。

进一步的，对于该装置，功能参数生成单元901，还用于：在确定所述第一节点的所有服务实例升级成功后，通过第二配置文件对系统数据库中的功能参数进行更改，得到第三功能参数；功能参数复原单元903，还用于：在确定升级失败时，通过第二回滚配置文件，恢复到所述第二配置文件对所述系统数据库进行更新之前的所述第一功能参数。

进一步的，对于该装置，功能参数生成单元901，还用于：在确定所有节点的所有服务实例升级成功后，通过第三配置文件对系统数据库中的功能参数进行更改，得到第四功能参数；功能参数复原单元903，还用于：在确定升级失败时，通过第三回滚配置文件，恢复到所述第三配置文件对所述系统数据库进行更新之前的所述第三功能参数。

本发明实施例还提供了一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。该计算设备可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器，可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本发明实施例中，存储器可以用于执行版本升级方法的程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行适用于版本升级方法。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行适用于版本升级方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (14)

1.一种版本升级方法，其特征在于，所述方法包括：

第一节点在第一版本标记为升级态时，停止所述第一节点上的第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；

所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；

所述第一节点启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

2.如权利要求1所述的方法，其特征在于，

所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中，包括：

所述第一节点通过缓存定义表确定需要更新至所述第一本地内存中的各功能参数表；所述缓存定义表记录有各功能参数表的属性信息；所述功能参数表记录有设定功能的各功能参数；

所述第一节点从所述系统数据库中获取所述各功能参数表并加载至所述第一本地内存。

3.如权利要求2所述的方法，其特征在于，

所述通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例，包括：

所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表；

所述第一服务实例根据所述第一功能参数表在所述缓存定义表中的属性信息，确定通过所述第一本地内存中的所述第一功能参数表来执行所述服务请求。

4.如权利要求3所述的方法，其特征在于，

所述第一服务实例确定待处理的服务请求在所述缓存定义表中对应的第一功能参数表之前，还包括：

所述第一节点中的拦截线程确定所述服务请求需调用所述第一功能参数表。

5.如权利要求1所述的方法，其特征在于，

所述第一节点将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中之前，还包括：

所述第一节点的轮询线程确定所述系统数据库中的功能参数表发生了更改。

6.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一节点在第二版本标记为非升级态时，从第二服务实例的第二本地内存中获取第二功能参数从而运行所述第二服务实例；所述第二版本标记用于指示所述第二服务实例是否需要升级；所述第二功能参数是所述系统数据库中通过所述第一配置文件更改前的记录。

7.如权利要求1所述的方法，其特征在于，所述运行所述第一服务实例之后，所述方法还包括：

所述第一节点在所述第一服务实例运行失败后，暂停所述第一服务实例，并将所述系统数据库中的第二功能参数更新至所述第一本地内存中；所述第二功能参数是根据第一回滚配置文件将所述系统数据库恢复至所述第一功能参数之前的记录。

8.如权利要求1所述的方法，其特征在于，所述第一本地内存按照设定的表结构存储所述系统数据库中的功能参数表。

9.如权利要求1-8任一项所述的方法，其特征在于，所述第一节点为分布式系统中的多个节点中的任一个；

所述分布式系统按照设定规则进行系统升级，包括：

所述第一节点上的各服务实例按照第一规则进行批量升级；所述第一规则是针对服务实例的升级顺序；

所述第一节点升级后，按照第二规则对第二节点进行升级；所述第二节点为所述分布式系统中除所述第一节点外的任一节点；所述第二规则是针对节点的升级顺序。

10.如权利要求1-8任一项所述的方法，其特征在于，所述方法还包括：

所述第一节点在所有服务实例按照所述第一配置文件升级成功后，将所述系统数据库中的第三功能参数更新至所述所有服务实例各自的本地内存中；所述第三功能参数是通过第二配置文件设置的，所述第二配置文件用于对与服务实例无依赖关系的功能参数的升级。

11.如权利要求10所述的方法，其特征在于，所述方法还包括：

所述第一节点在所有节点的所有服务实例按照所述第一配置文件和所述第二配置文件升级成功后，将所述系统数据库中的第四功能参数更新至所述所有服务实例各自的本地内存中；所述第四功能参数是通过第三配置文件设置的，所述第三配置文件用于对与上下游服务实例有依赖关系的功能参数的升级。

12.一种版本升级装置，其特征在于，所述装置包括：

停止单元，用于在第一版本标记为升级态时，停止第一服务实例；所述第一版本标记用于指示所述第一服务实例是否需要升级；

更新单元，用于将系统数据库中记录的第一功能参数更新至所述第一服务实例的第一本地内存中；所述第一功能参数是所述系统数据库通过第一配置文件进行更改后的功能参数；所述第一配置文件用于对与服务实例有依赖关系的功能参数的升级；

运行单元，用于启动所述第一服务实例，并通过所述第一本地内存中的所述第一功能参数运行所述第一服务实例。

13.一种计算设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如权利要求1-11任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如权利要求1-11任一项所述的方法。

Images