CN114513557A - 一种金融系统发布业务不中断的微服务通信方法 - Google Patents

Abstract

本发明涉及微服务技术领域，具体公开了一种金融系统发布业务不中断的微服务通信方法，定义微服务系统约束机制；限定微服务系统支持注册发现机制，支持主动发现新发布的服务；定义微服务系统状态机制；微服务系统支持准确区分多种状态标记，保障数据的高度一致性；制定微服务系统的发布策略；重启服务作为服务调用方的策略；采用先写日志的方式，保证金融请求不丢失；重启服务作为服务提供方的策略。本发明能够解决金融系统的发布过程中的数据一致性问题，能显著提升数据的一致性，具有容错率高，自动故障转移等优势，能满足对数据一致性要求高的业务场景。

Description

一种金融系统发布业务不中断的微服务通信方法

技术领域

本发明涉及微服务技术领域，具体为一种金融系统发布业务不中断的微服务通信方法。

背景技术

数据一致性在分布式领域一直是一个挑战，强一致性会使得分布式系统性能下降，而最终一致性如果最终一致性时间太长，从而容易引发客诉和上下游相关服务的数据异常。在互联网高并发时代，随devops的发展，对发布的频率要求越来越快，如此高的密集发布中，金融业务对数据一致性非常敏感，需要持续提高发布过程中业务不中断或用户无感知。

基于此，本发明公开了一种金融系统发布业务不中断的微服务通信方法，能解决微服务发布过程中的业务瞬断问题，数据可以高度一致。

发明内容

本发明的目的在于提供一种金融系统发布业务不中断的微服务通信方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：一种金融系统发布业务不中断的微服务通信方法，包括以下具体的步骤：

S1、定义微服务系统约束机制；限定微服务系统支持注册发现机制，支持主动发现新发布的服务；

S2：定义微服务系统状态机制；微服务系统支持准确区分多种状态标记，保障数据的高度一致性，状态标记包括：运行、重启中、启动中、终止；

S3：制定微服务系统的发布策略；

S4：重启服务作为服务调用方的策略；采用先写日志的方式，保证金融请求不丢失；

S5：重启服务作为服务提供方的策略。

作为本发明的一种优选方案，在步骤S1中，微服务系统约束机制在注册阶段：该机制的实现方案选择包括zookeeper，etcd在内的相关分布式协调系统作为注册中心，每一个服务人工编码分配一个唯一的数字id作为服务序号，该服务序号固定于该服务的配置文件中，每个服务支持启动多个副本，副本启动的时候自动连接注册中心，然后向注册中心发送注册消息，注册消息的格式为服务序号+GUID作为该副本的命名，注册中心包括zookeeper，etcd在内的相关分布式协调系统会存储该服务的ip、端口、命名；一个服务支持注册多个服务副本于注册中心；

微服务系统约束机制在发现阶段：服务启动完毕后，采用监听机制或主动拉取机制，支持获取当前提供的服务的全量列表数据，当新的服务注册完成或下线时，服务检测到新的列表增量数据，通过全量和增量数据，解析得到IP、端口和服务号，从而获得对应的服务号的通信地址。

作为本发明的一种优选方案，在步骤S1中，微服务系统约束机制支持负载均衡，不强依赖某一个节点；服务在调用阶段通过负载均衡的方式调用其他服务；如A服务调用B服务，B服务的服务序号为201，B服务有3个副本节点，则第一次发放请求调用副本节点1，第二次调用副本节点2，第三次调用副本节点3，第四次调用副本节点1，如此循环；

当节点1发生故障时，包括zookeeper，etcd在内的相关注册中心的服务列表则发生变化，服务A得到通知或主动拉取感知到节点1故障，从而从201的可用副本节点中移除相应的通信地址。

作为本发明的一种优选方案，在步骤S1中，微服务系统约束机制的每个微服务均非单点部署；每个微服务启动不得少于2个节点部署，避免当仅有一个副本节点部署在线，且该节点出现故障的时候，业务出现直接中断的情况；当存在多节点时，其中一个节点出现故障的时候，另一个节点通过负载均衡使得业务不中断。

作为本发明的一种优选方案，在步骤S2中，状态标记于微服务实现中采用整数内存变量表示，记作status，状态表示为：1运行、2重启中、3启动中、4终止；

当服务进程刚启动，程序设置为status＝1，此时不对外提供服务，系统未初始化；

当服务进程包括初始化网络、队列在内的相关服务完成系统初始化后，程序设置为status＝2，此时支持对外提供服务；

当服务进程接收到kill pid命令时，pid为服务的进程号，进程收到kill信号后，程序设置为status＝3，此时处于重启中状态，表示不再处理新的业务请求，并负责把老的业务请求处理完毕；

当服务进程将老的业务请处理完毕后，程序设置为status＝4，进入最后清理阶段，释放相应的内存和对象，然后进程关闭。

作为本发明的一种优选方案，在步骤S3中，微服务系统的发布策略具体为：对于一批待发布的微服务，逐个微服务逐台滚动发布，每个发布成功后再发下一个的时间间隔定义为秒，大于系统中调用最大超时时间。

作为本发明的一种优选方案，在步骤S4中，重启服务作为服务调用方的策略具体为：

(1)、服务调用方发起请求前记录redo log于磁盘文件；

(2)、服务调用方发起请求到服务提供方；

(3)、服务调用方获得服务提供方的请求；

(4)、服务调用方提交redo log；

若此过程中发生重启的情况，服务调用方重启后，处于“启动中”状态，加载redolog，启动重发线程；待重发线程处理完未commit的请求后，进入“运行”状态，提供服务。

作为本发明的一种优选方案，在步骤S5中，将重启服务作为服务提供方的策略具体为：

(1)、发布通过Kill命令，服务提供方收到重启信号，首先设置状态为“重启中”；

(2)、关闭网络监听端口，拒绝新连接进入；

(3)、处理队列中已有请求，网络请求的并给予网络响应；

(4)、等待β秒，使得各线程池请求处理完，γ＜β＜α，此处若仍未处理完，不再继续等待；

(5)、断开相关连接，进程终止；

在“重启中”状态下，接收到的新请求，返回给服务调用方“重启故障码”，服务调用方则标记此服务提供方为失效状态，进行负载均衡重发到其他的服务调用方。

值得注意的是：发布的服务，除网关外，一般既是服务调用方，同时又是服务提供方，按步骤S4、S5中的处理逻辑操作即可。

与现有技术相比，本发明的有益效果是：

本发明提供的一种金融系统发布业务不中断的微服务通信方法，解决发布过程中业务中断的问题，该方法通过对服务提供方和服务调用方的通信方式和逻辑实现进行状态区分并处理，能够极大提升微服务系统的数据一致性，该方法可做到除非发生大面积故障，否则发布过程中或单台故障的场景下，不会对业务产生影响和额外的失败，与现有的技术方法对比，显著提升了数据一致性。

附图说明

图1为本发明的微服务通信方法的整体流程图；

图2为本发明的微服务系统状态机制的具体结构示意图；

图3为本发明的重启服务作为服务调用方的策略图；

图4为本发明的重启服务作为服务提供方的策略图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1-4，本发明提供一种技术方案：一种金融系统发布业务不中断的微服务通信方法，包括以下具体的步骤：

S1、定义微服务系统约束机制；

微服务系统应首先满足如下条件：

(1)、支持注册发现机制，能主动发现新发布的服务；

注册阶段：该机制的可实现方案可选择zookeeper，etcd等作为注册中心，每一个服务人工编码分配一个唯一的数字id作为服务序号，该服务序号固定于该服务的配置文件中，每个服务可启动多个副本，副本启动的时候自动连接注册中心，然后向注册中心发送注册消息，注册消息的格式可为服务序号+GUID作为该副本的命名，注册中心zookeeper，etcd等会存储该服务的ip、端口、命名；一个服务会注册多个服务副本于注册中心。

发现阶段：服务启动完毕后，采用监听机制(zookeeper支持)或主动拉取机制，可获取当前可提供的服务的全量列表数据，当新的服务注册完成或下线(断开连接)时，服务检测到新的列表增量数据，通过全量和增量数据，解析得到IP、端口和服务号，从而获得对应的服务号的通信地址。

(2)、支持负载均衡，不强依赖某一个节点；

服务在调用阶段通过负载均衡的方式调用其他服务。如A服务调用B服务，B服务的服务序号为201，B服务有3个副本节点，则第一次发放请求调用副本节点1，第二次调用副本节点2，第三次调用副本节点3，第四次调用副本节点1，如此循环。

若节点1发生故障，则注册中心zookeeper，etcd等服务列表发生变化，服务A会得到通知或主动拉取感知到节点1故障，从而从201的可用副本节点中移除相应的通信地址。

(3)、每个微服务非单点部署，单点部署无法做到发布不中断业务；

每个微服务应启动不得少于2个节点部署，若仅有一个副本节点部署在线，则该节点故障的时候，业务会直接中断，若存在多节点，则当其中一个节点出现故障的时候，另一个节点可以通过负载均衡使得业务不中断。

S2、定义微服务系统状态机制；

微服务应能够区分状态标记，状态标记包括以下四中：运行、重启中、启动中、终止；准确的识别这4种状态才能做到数据高一致性。

状态标记于微服务实现中可以采用整数内存变量表示，记作status，状态表示为：1运行、2重启中、3启动中、4终止。

当服务进程刚启动，程序设置为status＝1，此时不可对外提供服务，系统未初始化；

当服务进程初始化网络、队列等完成系统初始化后，程序设置为status＝2，此时可对外提供服务；

当服务进程接收到kill pid命令时，pid为服务的进程号，进程收到kill信号后，程序设置为status＝3，此时处于重启中状态，表示不再处理新的业务请求，并负责把老的业务请求处理完毕；

当服务进程处理完毕老的业务请求后，程序设置为status＝4，进入最后清理阶段，释放相应的内存和对象，然后进程关闭。

S3、微服务系统的发布策略；

对于一批待发布的微服务，逐个微服务逐台滚动发布，每个发布成功后再发下一个的时间间隔定义为秒，大于系统中调用最大超时时间；

S4、重启服务作为服务调用方的策略；采用先写日志(write-ahead)的方式，保证金融请求不丢失。具体为：

(1)、服务调用方发起请求前记录redo log于磁盘文件(顺序文件)；

(2)、服务调用方发起请求到服务提供方；

(3)、服务调用方获得服务提供方的请求；

(4)、服务调用方提交redo log；

若此过程中，发生重启，服务调用方重启后，处于“启动中”状态，加载redo log，启动重发线程，待重发线程处理完未commit的请求后，进入“运行”状态，提供服务。

S5、重启服务作为服务提供方的策略；

(1)、发布通过Kill命令，服务提供方收到重启信号，首先设置状态为“重启中”；

(2)、关闭网络监听端口，拒绝新连接进入；

(3)、处理队列中已有请求，网络请求的并给予网络响应；

(4)、等待β秒，使得各线程池请求处理完，γ＜β＜α，此处若仍未处理完，不再继续等待；

(5)、断开相关连接，进程终止。

在“重启中”状态下，接收到的新请求，返回给服务调用方“重启故障码”，服务调用方则标记此服务提供方为失效状态，进行负载均衡重发到其他的服务调用方。

值得注意的是：发布的服务，除网关外，一般既是服务调用方，同时又是服务提供方，按步骤S4、S5中的处理逻辑操作即可。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (8)

1.一种金融系统发布业务不中断的微服务通信方法，其特征在于：包括以下具体的步骤：

S1、定义微服务系统约束机制；限定微服务系统支持注册发现机制，支持主动发现新发布的服务；

S2：定义微服务系统状态机制；微服务系统支持准确区分多种状态标记，保障数据的高度一致性，状态标记包括：运行、重启中、启动中、终止；

S3：制定微服务系统的发布策略；

S4：重启服务作为服务调用方的策略；采用先写日志的方式，保证金融请求不丢失；

S5：重启服务作为服务提供方的策略。

2.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S1中，微服务系统约束机制在注册阶段：该机制的实现方案选择包括zookeeper，etcd在内的相关分布式协调系统作为注册中心，每一个服务人工编码分配一个唯一的数字id作为服务序号，该服务序号固定于该服务的配置文件中，每个服务支持启动多个副本，副本启动的时候自动连接注册中心，然后向注册中心发送注册消息，注册消息的格式为服务序号+GUID作为该副本的命名，注册中心包括zookeeper，etcd在内的相关分布式协调系统会存储该服务的ip、端口、命名；一个服务支持注册多个服务副本于注册中心；

微服务系统约束机制在发现阶段：服务启动完毕后，采用监听机制或主动拉取机制，支持获取当前提供的服务的全量列表数据，当新的服务注册完成或下线时，服务检测到新的列表增量数据，通过全量和增量数据，解析得到IP、端口和服务号，从而获得对应的服务号的通信地址。

3.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S1中，微服务系统约束机制支持负载均衡，不强依赖某一个节点；服务在调用阶段通过负载均衡的方式调用其他服务；如A服务调用B服务，B服务的服务序号为201，B服务有3个副本节点，则第一次发放请求调用副本节点1，第二次调用副本节点2，第三次调用副本节点3，第四次调用副本节点1，如此循环；

当节点1发生故障时，包括zookeeper，etcd在内的相关注册中心的服务列表则发生变化，服务A得到通知或主动拉取感知到节点1故障，从而从201的可用副本节点中移除相应的通信地址。

4.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S1中，微服务系统约束机制的每个微服务均非单点部署；每个微服务启动不得少于2个节点部署，避免当仅有一个副本节点部署在线，且该节点出现故障的时候，业务出现直接中断的情况；当存在多节点时，其中一个节点出现故障的时候，另一个节点通过负载均衡使得业务不中断。

5.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S2中，状态标记于微服务实现中采用整数内存变量表示，记作status，状态表示为：1运行、2重启中、3启动中、4终止；

当服务进程刚启动，程序设置为status＝1，此时不对外提供服务，系统未初始化；

当服务进程包括初始化网络、队列在内的相关服务完成系统初始化后，程序设置为status＝2，此时支持对外提供服务；

当服务进程接收到killpid命令时，pid为服务的进程号，进程收到kill信号后，程序设置为status＝3，此时处于重启中状态，表示不再处理新的业务请求，并负责把老的业务请求处理完毕；

当服务进程将老的业务请处理完毕后，程序设置为status＝4，进入最后清理阶段，释放相应的内存和对象，然后进程关闭。

6.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S3中，微服务系统的发布策略具体为：对于一批待发布的微服务，逐个微服务逐台滚动发布，每个发布成功后再发下一个的时间间隔定义为秒，大于系统中调用最大超时时间。

7.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S4中，重启服务作为服务调用方的策略具体为：

(1)、服务调用方发起请求前记录redo log于磁盘文件；

(2)、服务调用方发起请求到服务提供方；

(3)、服务调用方获得服务提供方的请求；

(4)、服务调用方提交redo log；

若此过程中发生重启的情况，服务调用方重启后，处于“启动中”状态，加载redolog，启动重发线程；待重发线程处理完未commit的请求后，进入“运行”状态，提供服务。

8.根据权利要求1所述的一种金融系统发布业务不中断的微服务通信方法，其特征在于：在步骤S5中，将重启服务作为服务提供方的策略具体为：

(1)、发布通过Kill命令，服务提供方收到重启信号，首先设置状态为“重启中”；

(2)、关闭网络监听端口，拒绝新连接进入；

(3)、处理队列中已有请求，网络请求的并给予网络响应；

(4)、等待β秒，使得各线程池请求处理完，γ＜β＜α，此处若仍未处理完，不再继续等待；

(5)、断开相关连接，进程终止；

在“重启中”状态下，接收到的新请求，返回给服务调用方“重启故障码”，服务调用方则标记此服务提供方为失效状态，进行负载均衡重发到其他的服务调用方。

Images