CN113326052A - 业务组件的升级方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种业务组件的升级方法、装置、计算机设备和存储介质。所述方法包括：响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。采用本方法能够有效提高业务组件升级的控制效率。

Description

业务组件的升级方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务组件的升级方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，5G时代的来临，互联网的出现给现代生活带来了极大的便利，越来越多的企业可以通过使用系统业务平台在线对多种业务进行处理，为用户带来便捷。例如，在目前的交易系统中，当用户需要查看交易数据时，用户可以在交易系统中进行相应的查询操作，交易系统中的业务组件响应于用户的查询操作，可以从数据库中查找对应的交易数据。

然而，目前的业务组件的升级方式中，通常是基于数据库实现的，业务组件与数据库紧耦合，由于所有组件都依赖于数据库，所以当进行升级时需要系统组件整体进行升级，这种系统组件整体升级的弊端在于容易出现升级效果不好而导致所有节点都出现问题的情况，尤其涉及多种业务场景下的业务组件灰度升级时，容易导致业务组件升级的控制效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高业务组件升级的控制效率的业务组件的升级方法、装置、计算机设备和存储介质。

一种业务组件的升级方法，所述方法包括：

响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

在其中一个实施例中，所述目标系统至少包括交易系统和风控系统；

所述响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点之前，所述方法还包括：

对所述交易系统和风控系统中的所有业务节点进行分类，得到对应的分类结果；

基于所述分类结果在操作界面中将业务节点进行分类展示。

在其中一个实施例中，所述响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，包括：

获取所述选取的目标系统中各个业务节点的业务执行情况；

基于所述业务执行情况确定所述业务节点的升级必要性，并按照所述升级必要性的高低顺序在操作界面中进行排序显示。

在其中一个实施例中，所述业务执行情况包括业务节点报错的频率；

所述基于所述业务执行情况确定所述业务节点的升级必要性，包括：

基于所述业务节点报错的频率确定所述业务节点的升级必要性。

在其中一个实施例中，所述获取与所述目标业务节点对应的升级包，包括：

通过通信总线获取与所述目标业务节点对应的升级包；其中，所述升级包包括不同灰度版本的升级包；

所述获取与所述目标业务节点对应的升级包之后，所述方法还包括：

将与所述目标业务节点对应的不同灰度版本的升级包显示在操作界面中。

在其中一个实施例中，所述将所述升级包下发到所述目标业务组件实例中之后，所述方法还包括：

在所述目标业务组件实例完成版本升级的情况下，执行数据库脚本，将与所述目标业务节点对应的数据更新至备份数据库中。

在其中一个实施例中，所述将所述升级包下发到所述目标业务组件实例中之后，所述方法还包括：

对已升级的所述目标业务节点的升级状态进行评估，得到对应的评估结果，并将所述评估结果显示在操作界面上；所述评估结果用于指示用户基于评估结果判断是否对其他的业务节点进行升级操作。

一种业务组件的升级装置，所述装置包括：

显示模块，用于响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取模块，用于获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

下发模块，用于获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

上述业务组件的升级方法、装置、计算机设备和存储介质，通过响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。获取从业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包；其中，升级包携带业务执行的代码、配置参数和用户数据。获取选取的与目标业务节点对应的目标业务组件实例，将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。由此使得，能够防止出现升级效果不好导致所有节点都出现问题的情况，有效提高节点升级的效率，即使是涉及多种业务场景下的业务组件灰度升级时，也能够实现仅对部分节点进行升级而不需要整体升级所有的节点，实现了对节点升级的有序管理，从而有效提高了业务组件升级的控制效率。

附图说明

图1为一个实施例中业务组件的升级方法的应用环境图；

图2为一个实施例中业务组件的升级方法的流程示意图；

图3为一个实施例中对交易系统和风控系统中的所有业务节点进行分类步骤的流程示意图；

图4A为一个实施例中响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点步骤的流程示意图；

图4B为一个实施例中某个运维支撑系统提供的组件升级操作界面显示图；

图5为另一个实施例中业务组件的升级方法的流程示意图；

图6为一个实施例中业务组件的升级装置的结构框图；

图7为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的业务组件的升级方法，可以应用于如图1所示的应用环境中。其中，用户终端102通过网络与服务器104通过网络进行通信。服务器104响应于用户终端102的触发操作，在操作界面中显示用户终端102选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。服务器104获取用户终端102从业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包；其中，升级包携带业务执行的代码、配置参数和用户数据。服务器104获取用户终端102选取的与目标业务节点对应的目标业务组件实例，服务器104将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种业务组件的升级方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。

在目前的软件开发过程中，开发人员可以采用微服务架构，围绕着业务组件来创建不同业务功能的应用，这些应用可独立地进行开发、管理和更新，在分散的组件中使用微服务云架构和平台，能够使部署、管理和服务功能交付变得更加简单。微服务是一个新兴的软件架构，能够把一个大型的单个应用程序和服务拆分为数十个的支持微服务。微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

现有业务系统中服务发布上线或需要升级业务组件时，可以采用灰度发布或者灰度升级业务组件对应的服务实例的方式。灰度发布(又名金丝雀发布)是指在黑与白之间，能够平滑过渡的一种发布方式。在服务版本快速迭代过程中，灰度版本与正式版本可以并存，灰度版本逐步放量到升级正式版，这样服务更新版本发布过程中就不需要停用服务一段时间，而且不同版本之间过渡过程可监控，一旦发现灰度版本有问题，也可以快速回退为原有的正式版的状态。即灰度统指程序发布上线后由于无法预估风险而采取的客户影响最小化运行策略。

具体的，以自主研发的运维支撑系统(OSS，Operation Support Systems)为例进行说明。该运维支撑系统能够提供组件升级操作界面和控制每个节点需要下发的数据格式和数据，可以用于管理证券交易系统，也可以用独立的服务器或者是多个服务器组成的服务器集群来实现。用户可以通过在手机应用程序中或浏览器网页中输入用户名和密码的方式，登录特定场景的业务系统中，即用户可以通过app(Application，应用程序)客户端或web客户端即web浏览器的方式登录某个运维支撑系统，并进入与该运维支撑系统对应的显示界面中。进一步的，用户可以通过触发操作选取在操作界面中显示的某个子系统，并在操作界面中显示与该用户选取的子系统所对应的业务节点。例如，用户可以通过点击该运维支撑系统界面中展示的某个系统A的图标(或者名称条目等)，则运维支撑系统即服务器响应于该触发操作，在操作界面中显示选取的目标系统A所对应的业务节点，即用户可以通过触发操作选取运维支撑系统中不同类型的目标系统，运维支撑系统将用户所选取的目标系统所对应的所有业务节点展示在操作界面中，以使得用户可以选取想要升级的业务节点。

其中，业务节点是由业务组件实例进行划分得到，业务节点是指每个系统的各个交易业务对应的独立的业务节点，即将业务组件实例划分为一个一个的业务节点，每个业务节点可以独立完成对应的业务。交易过程需要的配置参数和客户数据由运维平台通过文件的方式发送给交易节点的组件，发送给各个交易节点的文件可以是不同的格式和内容，从而实现解耦交易组件与数据库。例如，在证券交易系统中，通过部署配置实现将组件实例划分为一个一个的交易节点。具体的，可以将用户按照用户的资金账号进行分区，将组件实例划分一个一个功能完整的组，即交易节点，每个交易节点对应一个客户的分区。可以理解的是，用户通过触发操作选取目标系统的方式包括但不限于点击操作，还可以为语音操作、手势操作等其他方式触发，只要能够实现选取目标系统，对其触发方式不做限定。

步骤204，获取从业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包；其中，升级包携带业务执行的代码、配置参数和用户数据。

服务器响应于触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点之后，服务器可以获取用户从操作界面中显示的业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包。其中，升级包携带业务执行的代码、配置参数和用户数据。目标业务节点是指选取的需要升级的节点，即为目标业务节点。即服务器响应于触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点之后，用户可以选取部分节点(比如，选取业务节点A和B)进行升级，也可以选取全部节点(比如，全部业务节点A、B、C)进行升级，即用户可以选择一个或多个节点进行升级，服务器可以提供对一个或多个节点进行升级的回滚操作。

例如，在证券交易系统中，可以预先根据证券业务的内容进行分类，将期权类的业务节点作为一个节点组A，将现货类的业务节点作为另一个节点组B。服务器响应于触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点时，可以将同一节点组的业务节点在相连续的位置上进行显示，使得用户可以方便地选取特定类别的业务节点进行升级。进一步的，服务器在获取到用户选取的特定类别的业务节点即目标业务节点之后，服务器可以通过通信总线获取与用户所选取的目标业务节点对应的升级包。其中，升级包中可以包含多个不同版本的升级包，即每个升级包对应的版本标识可以标识不同的版本信息，版本标识可以包括灰度版本标识和非灰度版本标识，版本信息可以包括非灰度版本和灰度版本。这些升级包可以存储在服务器对应的数据库中，也可以存储在各个节点对应的业务组件上，服务器可以通过通信总线从对应的业务组件的存储空间中获取对应的升级包。例如，用户选择的节点为“上证-公共服务”和“机构上证通期权1号-BOS”，则服务器可以分别从“上证-公共服务”和“机构上证通期权1号-BOS”对应的组件中获取对应的升级包。

可以理解的是，获取与目标业务节点对应的升级包可以是获取最新的升级包，也可以是获取一定数量的既有升级包(即回滚操作)，升级包的获取规则可以由用户设置的升级规则来确定。

步骤206，获取选取的与目标业务节点对应的目标业务组件实例，将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。

服务器获取与目标业务节点对应的升级包之后，服务器可以获取用户选取的与目标业务节点对应的目标业务组件实例，将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。其中，目标业务组件实例是指用户选取的目标业务组件对应的实例，一个组件在一个节点中可以有多个实例。OSS可以在界面中显示用户所选取的目标节点对应的各个实例，以指示用户选择目标业务组件实例，用户可以选取部分实例，即只升级其中的部分实例。例如，以机构上证通期权1号节点为例进行说明，该业务节点对应的实例可以包括交易网关(GW，GateWay，负责与客户端进行消息交互，例如Archforce GateWay，华锐标准网关)、TE(交易引擎，负责对交易请求进行处理)和ORS(Order Routing Service，系统报盘服务组件)等。进一步的，在服务器获取用户选取的与目标业务节点对应的目标业务组件实例之后，即在完成实例选择之后，就可以进行对应的版本升级。

传统的业务组件的升级方式中，通常是基于数据库实现的，例如传统的交易系统对交易数据进行处理的方式是基于数据库实现的，即将交易的配置参数和客户数据都存储在数据库中，在需要对某一交易文件进行运算时，各个交易组件从数据库中读取数据，计算完成后再将结果写入数据库，业务组件与数据库紧耦合，由于所有组件都依赖于数据库，所以当需要升级时需要整体进行升级，若升级效果不好容易导致所有节点都出现问题的情况，使得业务组件升级的控制效率较低。

而本实施例中，通过响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。获取从业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包；其中，升级包携带业务执行的代码、配置参数和用户数据。获取选取的与目标业务节点对应的目标业务组件实例，将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。由此使得，能够防止出现升级效果不好导致所有节点都出现问题的情况，有效提高节点升级的效率，即使是涉及多种业务场景下的业务组件灰度升级时，也能够实现仅对部分节点进行升级而不需要整体升级所有的节点，实现了对节点升级的有序管理，从而有效提高了业务组件升级的控制效率。

在一个实施例中，如图3所示，目标系统至少包括交易系统和风控系统，响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点之前，该方法还包括对交易系统和风控系统中的所有业务节点进行分类的步骤，具体包括：

步骤302，对交易系统和风控系统中的所有业务节点进行分类，得到对应的分类结果。

步骤304，基于分类结果在操作界面中将业务节点进行分类展示。

以自主研发的运维支撑系统(OSS，Operation Support Systems)为例进行说明。运维支撑系统即服务器响应于用户的触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点之前，服务器可以对目标系统中的所有业务节点进行分类。其中，目标系统至少包括交易系统和风控系统。具体的，服务器可以对交易系统和风控系统中的所有业务节点进行分类，得到对应的分类结果。进一步的，服务器响应于用户的触发操作，基于分类结果在操作界面中将用户选取的目标系统所对应的业务节点进行分类展示。OSS支持管理多个系统，系统可以是不同的产品，比如交易系统(对实际的股票等交易业务进行处理的系统)、风控系统(对用户、证券产品等进行风险监控的系统)等，而每个系统的各个交易业务对应有独立的业务节点。升级控制系统、OSS以及这些业务节点均搭载在统一的通信总线上，升级控制系统可以通过该通信总线从OSS以及这些业务节点上获取数据，也可以通过通信总线将升级包等数据发送至对应的业务节点。例如，在证券交易系统中，可以预先根据证券业务的内容来分类，将期权类的业务节点作为一个节点组，将现货类的业务节点作为另一个节点组。在进行展示时，可以将同一节点组的业务节点放在相连续的位置上显示，例如：期权类的各个业务节点排在现货类的各个业务节点之前。由此，通过分类显示的方式，使得用户可以方便地对特定类别的业务节点进行升级。

在一个实施例中，如图4A所示，响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点的步骤，包括：

步骤402，获取选取的目标系统中各个业务节点的业务执行情况。

步骤404，基于业务执行情况确定业务节点的升级必要性，并按照升级必要性的高低顺序在操作界面中进行排序显示。

服务器响应于用户的触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点。具体的，如图4B所示，为某个运维支撑系统提供的组件升级操作界面显示图。服务器可以获取用户选取的目标系统中各个业务节点的业务执行情况。进一步的，服务器可以基于业务执行情况确定业务节点的升级必要性，并按照升级必要性的高低顺序在操作界面中进行排序显示。例如，在图4B的升级界面图中，由于“统一运维公共服务”节点的升级必要性高于“上证-公共服务”节点的升级必要性，因此按照升级必要性的高低顺序排序显示为“统一运维公共服务”节点排在“上证-公共服务”节点之前。由此，通过运维支撑系统的升级界面显示图，用户可以直观快速的选择一个或多个目标节点进行升级，同时也提供对一个或多个目标节点进行升级回滚操作，使得能够按需选取节点进行升级，其它节点正常作业，能够动态控制组件的灰度升级，即可实现基于不同业务场景特色动态定制节点升级的组件，无须整体升级系统中所有组件，能够保证组件更新迭代时的稳定性，同时有效的提高了组件升级的控制效率。

在其中一个实施例中，业务执行情况包括业务节点报错的频率，基于业务执行情况确定业务节点的升级必要性的步骤，包括：

基于业务节点报错的频率确定业务节点的升级必要性。

服务器可以获取用户选取的目标系统中各个业务节点的业务执行情况。进一步的，服务器可以基于业务执行情况确定业务节点的升级必要性，并按照升级必要性的高低顺序在操作界面中进行排序显示。其中，业务执行情况可以包括业务节点报错的频率，则服务器可以基于业务节点报错的频率确定业务节点的升级必要性。具体的，服务器可以获取用户选取的目标系统中各个业务节点报错的频率即(报错率)，进一步的，服务器可以基于各个业务节点报错的频率确定各个业务节点的升级必要性，并按照升级必要性的高低顺序在操作界面中将各个业务节点进行排序显示。例如，如图4B所示，假设服务器获取“统一运维公共服务”节点的报错率为10％以及“上证-公共服务”节点的报错率为8％，由于“统一运维公共服务”节点的报错率为10％高于“上证-公共服务”节点的报错率为8％，则“统一运维公共服务”节点的升级必要性高于“上证-公共服务”节点的升级必要性，即报错频率越高，升级必要性就越高，因此按照升级必要性的高低顺序排序显示为“统一运维公共服务”节点排在“上证-公共服务”节点之前。可以理解的是，升级控制系统也可对节点进行其他的处理，以适应不同的升级需要。

由此，通过运维支撑系统的升级界面显示图，用户可以直观快速的选择一个或多个目标节点进行升级，使得能够按需选取节点进行升级，其它节点正常作业，实现对组件灰度升级的动态控制，即可实现基于不同业务场景特色动态定制节点升级的组件，无须整体升级系统中所有组件，能够保证组件更新迭代时的稳定性，同时有效的提高了组件升级的控制效率。

在一个实施例中，获取与目标业务节点对应的升级包的步骤，包括：

通过通信总线获取与目标业务节点对应的升级包；其中，升级包包括不同灰度版本的升级包。

服务器响应于触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点之后，服务器可以获取用户从操作界面中显示的业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包。具体的，服务器可以通过通信总线获取与目标业务节点对应的升级包。其中，升级包包括不同灰度版本的升级包。例如，用户在操作界面中选择的节点为“上证-公共服务”和“机构上证通期权1号-BOS”，则服务器分别从“上证-公共服务”和“机构上证通期权1号-BOS”对应的组件中获取对应的升级包。其中，获取的升级包可以是获取最新版本的升级包(比如灰度版本升级包)，也可以是获取一定数量的既有升级包(比如非灰度版本升级包)。进一步的，服务器获取与目标业务节点对应的升级包之后，服务器还可以将与目标业务节点对应的不同灰度版本的升级包显示在操作界面中，使得用户可以快速准确的选取不同版本的升级包对业务组件实例进行灰度升级。由此使得，通过获取不同版本的升级包，能够实现对一个或多个目标节点进行升级回滚操作，即能够按需选取节点进行不同版本的灰度升级，其它节点正常作业，实现对组件灰度升级的动态控制，无须整体升级系统中所有组件，从而有效提高了组件升级的控制效率。

在一个实施例中，如图5所示，提供了一种业务组件的升级方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤502，响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。

步骤504，获取从业务节点中选取的目标业务节点，并通过通信总线获取与目标业务节点对应的升级包；其中，升级包包括不同灰度版本的升级包。

步骤506，将与目标业务节点对应的不同灰度版本的升级包显示在操作界面中。

步骤508，获取从不同灰度版本的升级包中选取的目标升级包。

步骤510，获取选取的与目标业务节点对应的目标业务组件实例，将目标升级包下发到目标业务组件实例中，目标升级包用于指示目标业务组件实例读取目标升级包携带的业务执行的代码、配置参数和用户数据进行升级。

以自主研发的运维支撑系统(OSS)为例进行说明，OSS支持管理多个系统，当交易节点的版本不同时，通过OSS控制每个节点下发的数据格式，实现管理不同版本的交易节点。本实施例中可以基于OSS(运维支撑系统)来实现，OSS提供组件升级操作界面和控制每个节点需要下发的数据格式和数据。例如，某企业研发的运维支撑系统(OSS)，用于管理证券交易系统，其中，交易组件都使用一个叫AMI的消息总线进行组件间通信，所有组件都订阅了一个消息主题用于接收实时指令。OSS将文件下发到组件实例所在的机器后会发送一条数据加载指令到消息总线，各组件实例收到消息后读取文件到内存中。相较于传统方式，使用了低时延的可靠组播技术发送消息。

具体的，进行节点升级的过程具体说明如下。OSS通过界面展示不同的系统，使得用户可以快速准确的选取目标系统。即OSS响应于用户的触发操作，在操作界面中显示用户选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。例如，在用户选择某一系统S之后，OSS在界面上展示所选择系统S对应的节点。此时用户可以选择对应的需要升级的节点，可以选择对其中部分或者全部的节点。另外，在OSS通过界面展示节点之前，升级控制系统可以对S系统中的所有节点进行分类。OSS基于分类结果进行节点展示。例如，根据证券业务的内容来分类，将期权类的业务节点作为一个节点组，将现货类的业务节点作为另一个节点组。在进行展示时，可以将同一节点组的业务节点放在相连续的位置上显示，例如：期权类的各个业务节点排在现货类的各个业务节点之前。通过分类显示的方式，用户可以方便地对特定类别的业务节点进行升级。另外，也可以获取各个节点的业务执行情况，基于业务执行情况确定各个节点的升级必要性，例如：根据节点报错的频率来确定升级必要性，报错频率越高，升级必要性越高，再按照升级必要性的高低顺序进行排序显示。可以理解的是，升级控制系统也可对节点进行其他的处理，以适应不同的升级需要。

进一步的，在获取到用户选择的目标节点之后，升级控制系统通过通信总线获取与所选择节点对应的升级包。这些升级包可以存储在升级控制系统对应的数据库中，也可以存储在各个节点对应的业务组件上，升级控制系统通过通信总线从对应的业务组件的存储空间中获取对应的升级包。其中，升级包包括不同灰度版本的升级包，即升级包可以是获取最新的升级包，也可以是获取一定数量的既有升级包。在获取升级包的过程中，OSS可以在界面中显示“正在获取升级包”等信息。OSS也可以将获取的升级包信息展示在界面中，例如：获取到“上证-公共服务”节点(即目标业务节点)对应的多个版本的升级包，则在界面中显示这些升级包(不同灰度版本的升级包)，并指示用户从中选择一个，即升级控制系统获取用户从不同灰度版本的升级包中选取的目标升级包。其中，升级包中除了必要的业务执行的相关代码，还可以包含交易的配置参数和客户数据等。

进一步的，一个组件在一个节点中可以有多个实例。OSS可以在界面中显示用户所选择目标节点的各个实例，以指示用户选择，可以只升级其中的部分实例。即运维支撑系统获取用户选取的与目标业务节点对应的目标业务组件实例，并将目标升级包下发到目标业务组件实例中，目标升级包用于指示目标业务组件实例读取目标升级包携带的业务执行的代码、配置参数和用户数据进行升级。其中，一个组件在一个节点中可以有多个实例，是为了提升单节点的吞吐能力，一个节点内同一个组件的版本是一致的，比如部署多个查询引擎组件的实例同时对外提供服务。即在用户完成目标实例选择之后，就可以进行版本升级。运维支撑系统将新版本的升级包(目标升级包)的二进制文件复制到对应的组件(目标组件实例)中。其中，二进制包是指程序的安装包。当节点的高可用类型为主备时，可以对主备进行同步升级，例如：可以对主备上的某些实例进行同步升级。即一个组件的主备实例都属于同一个节点，升级的时候按节点升级就自动升级了主备节点。相较于传统方式进行主备的数据复制技术实现主备的数据一致性，而本实施例中是通过AMI系统，使主备同时接收到同样的数据，进行同样的处理，不需要进行主备的数据同步，从而也有效提高了组件升级的控制效率。

本实施中，通过将升级文件发送给目标节点，在进行升级时可以选择部分节点升级，或部分节点的部分实例进行升级，之后再推广至其他节点，即通过使用发送文件方式可以将业务组件与数据库进行解耦，能够实现组件的灰度升级，即可实现基于不同业务场景特色动态定制节点升级的组件，无须整体升级系统中所有组件，能够保证组件更新迭代时的稳定性，同时有效的提高了组件升级的控制效率。

在一个实施例中，将升级包下发到目标业务组件实例中之后，该方法还包括将与目标业务节点对应的数据更新至备份数据库中的步骤，具体包括：

在目标业务组件实例完成版本升级的情况下，执行数据库脚本，将与目标业务节点对应的数据更新至备份数据库中。

运维支撑系统(升级控制系统)将升级包下发到目标业务组件实例中之后，即在完成目标节点的版本升级之后，如果数据库有升级的话，升级控制系统可以执行数据库脚本，以对数据库进行升级，例如：在数据库中更新与所升级节点对应的数据。这里的数据库可以理解为对各个业务节点数据的备份数据库。在完成数据库的数据升级之后，可以通过OSS来接收业务触发操作，OSS基于业务触发操作获取每个节点需要下发的数据格式和数据。OSS基于所获取的数据格式和数据触发对应的节点针对性地执行业务，例如：按照列表的形式输出用户当月的期权收益。由此使得，能防止出现升级效果不好导致所有节点都出现问题的情况，通过使用升级包的方式可以将业务组件与数据库进行解耦，从而有效提高节点升级的整体效率。

在一个实施例中，将升级包下发到目标业务组件实例中之后，该方法还包括对已升级的目标业务节点的升级状态进行评估的步骤，具体包括：

对已升级的目标业务节点的升级状态进行评估，得到对应的评估结果，并将评估结果显示在操作界面上；评估结果用于指示用户基于评估结果判断是否对其他的业务节点进行升级操作。

运维支撑系统(升级控制系统)将升级包下发到目标业务组件实例中之后，即在完成目标节点的版本升级之后，运维支撑系统可以对已升级的目标业务节点的升级状态进行评估，得到对应的评估结果，并将评估结果显示在操作界面上，评估结果用于指示用户基于评估结果判断是否对其他的业务节点进行升级操作。即本实施例中可以对部分节点先升级，基于已升级的部分节点的升级效果来对剩下的节点进行升级，进而完成所有节点的升级。进一步地，可以评估已升级的各个节点的升级状态，通过OSS在界面上显示升级状态。用户基于升级状态的做出是否要对剩下的节点进行升级的选择操作。当需要升级时，升级控制系统根据选择操作对剩下的节点进行升级。可以理解的是，也可以基于各个节点的升级状态自动完成后续的升级过程，例如，当确定之前选择的所有节点都已正常升级时，可以对所选择节点中剩下的实例进行自动升级，也可以对系统S中的其他节点进行自动升级，还可以对其他系统中的类似节点进行自动升级。由此使得，能够按需选取节点进行不同版本的灰度升级，其它节点正常作业，同时能够对组件灰度升级时进行动态调控，无须整体升级系统中所有组件，从而有效提高了组件升级的控制效率。

应该理解的是，虽然图1-5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-5中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图6所示，提供了一种业务组件的升级装置，包括：显示模块602、获取模块604和下发模块606，其中：

显示模块602，用于响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，业务节点是由业务组件实例进行划分得到。

获取模块604，用于获取从业务节点中选取的目标业务节点，并获取与目标业务节点对应的升级包；其中，升级包携带业务执行的代码、配置参数和用户数据。

下发模块606，用于获取选取的与目标业务节点对应的目标业务组件实例，将升级包下发到目标业务组件实例中，升级包用于指示目标业务组件实例读取升级包携带的业务执行的代码、配置参数和用户数据进行升级。

在一个实施例中，该装置还包括：分类模块和展示模块。

分类模块用于对交易系统和风控系统中的所有业务节点进行分类，得到对应的分类结果。展示模块用于基于分类结果在操作界面中将业务节点进行分类展示。

在一个实施例中，该装置还包括：确定模块。

获取模块还用于获取选取的目标系统中各个业务节点的业务执行情况。确定模块用于基于业务执行情况确定业务节点的升级必要性，并按照升级必要性的高低顺序在操作界面中进行排序显示。

在一个实施例中，确定模块还用于基于业务节点报错的频率确定业务节点的升级必要性。

在一个实施例中，获取模块还用于通过通信总线获取与目标业务节点对应的升级包；其中，升级包包括不同灰度版本的升级包。显示模块还用于将与目标业务节点对应的不同灰度版本的升级包显示在操作界面中。

在一个实施例中，该装置还包括：执行模块。

执行模块用于在目标业务组件实例完成版本升级的情况下，执行数据库脚本，将与目标业务节点对应的数据更新至备份数据库中。

在一个实施例中，该装置还包括：评估模块。

评估模块用于对已升级的目标业务节点的升级状态进行评估，得到对应的评估结果，并将评估结果显示在操作界面上，评估结果用于指示用户基于评估结果判断是否对其他的业务节点进行升级操作。

关于业务组件的升级装置的具体限定可以参见上文中对于业务组件的升级方法的限定，在此不再赘述。上述业务组件的升级装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储业务组件的升级数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务组件的升级方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述各个方法实施例的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种业务组件的升级方法，所述方法包括：

响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

2.根据权利要求1所述的方法，其特征在于，所述目标系统至少包括交易系统和风控系统；

所述响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点之前，所述方法还包括：

对所述交易系统和风控系统中的所有业务节点进行分类，得到对应的分类结果；

基于所述分类结果在操作界面中将业务节点进行分类展示。

3.根据权利要求1所述的方法，其特征在于，所述响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点，包括：

获取所述选取的目标系统中各个业务节点的业务执行情况；

基于所述业务执行情况确定所述业务节点的升级必要性，并按照所述升级必要性的高低顺序在操作界面中进行排序显示。

4.根据权利要求3所述的方法，其特征在于，所述业务执行情况包括业务节点报错的频率；

所述基于所述业务执行情况确定所述业务节点的升级必要性，包括：

基于所述业务节点报错的频率确定所述业务节点的升级必要性。

5.根据权利要求1所述的方法，其特征在于，所述获取与所述目标业务节点对应的升级包，包括：

通过通信总线获取与所述目标业务节点对应的升级包；其中，所述升级包包括不同灰度版本的升级包；

所述获取与所述目标业务节点对应的升级包之后，所述方法还包括：

将与所述目标业务节点对应的不同灰度版本的升级包显示在操作界面中。

6.根据权利要求1所述的方法，其特征在于，所述将所述升级包下发到所述目标业务组件实例中之后，所述方法还包括：

在所述目标业务组件实例完成版本升级的情况下，执行数据库脚本，将与所述目标业务节点对应的数据更新至备份数据库中。

7.根据权利要求1所述的方法，其特征在于，所述将所述升级包下发到所述目标业务组件实例中之后，所述方法还包括：

对已升级的所述目标业务节点的升级状态进行评估，得到对应的评估结果，并将所述评估结果显示在操作界面上；所述评估结果用于指示用户基于评估结果判断是否对其他的业务节点进行升级操作。

8.一种业务组件的升级装置，其特征在于，所述装置包括：

显示模块，用于响应于触发操作，在操作界面中显示选取的目标系统所对应的业务节点；所述业务节点是由业务组件实例进行划分得到；

获取模块，用于获取从所述业务节点中选取的目标业务节点，并获取与所述目标业务节点对应的升级包；其中，所述升级包携带业务执行的代码、配置参数和用户数据；

下发模块，用于获取选取的与所述目标业务节点对应的目标业务组件实例，将所述升级包下发到所述目标业务组件实例中，所述升级包用于指示所述目标业务组件实例读取所述升级包携带的业务执行的代码、配置参数和用户数据进行升级。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images