一种中心化应用系统的集群消息传递方法及系统与流程

1.本发明涉及中心化应用技术领域，具体涉及一种中心化应用系统的集群消息传递方法及系统。


背景技术：

2.国内银行系统由于业务稳定，大部分系统已支撑金融业务发展多年，长时间各个系统就逐渐形成中心化的烟囱式架构；然而中心化应用集群中的每个系统只能保障自身业务的事务一致性。
3.随着金融业务的发展，很多业务会涉及到多个系统，需要多个系统提供的服务来支撑业务流程，多个系统之间的关联度差，当某个系统发生异常时，如何及时通知其他系统以进行合理的异常处理成为最大的痛点；严重者将导致业务无法进行。
4.除了业务连续性得不到保障，还会影响业务数据异常，例如当某项业务在系统a和系统b中处理成功，产生的数据已经落库在两个系统，但当c系统出现异常时，a系统和b系统不会回滚，此时a系统和b系统的数据库出现脏数据，导致对账、报表等数据错误；在消息投递的过程中，如果某个环节出现异常，就无法保证消息的可靠投递。


技术实现要素：

5.本发明所要解决的技术问题是：中心化应用集群中的每个系统只能保障自身业务的事务一致性，系统之间关联度差导致业务连续性得不到保障，还会影响业务数据异常，无法保证消息发送的可靠性；本发明目的在于提供一种中心化应用系统的集群消息传递方法及系统，以解决上述技术问题。
6.本发明通过下述技术方案实现：
7.本方案提供一种中心化应用系统的集群消息传递方法，提取中心化集群应用系统的功能封装成微服务并注册到服务中心，根据功能的业务传递链形成上游服务和下游服务，上游服务和下游服务的消息传递过程为：
8.上游服务向可靠消息服务发送消息后开始操作本地业务，上游服务根据本地业务操作结果向可靠消息服务发送第一消息指令；
9.可靠消息服务储存消息并根据第一消息指令通知上游服务进行回滚或对消息进行状态更新；
10.可靠消息服务将状态更新后的消息投递到rocketmq消息队列；
11.下游服务从rocketmq消息队列中消费消息，当下游服务消费到消息时开始操作本地业务，下游服务根据本地业务操作结果向可靠消息服务发送第二消息指令，可靠消息服务根据第二消息指令对消息进行状态更新。所述消息用于跟踪上游服务系统实现某一功能的业务消息。
12.本方案工作原理：现有的中心化应用集群中的每个系统只能保障自身业务的事务一致性，应用于银行系统这种涉及到多个系统，需要多个系统提供的服务来支撑的业务流
程中，当某个系统出现异常，将导致整个业务无法进行，业务连续性得不到保障；整个业务链路中某个系统或某个环节出现异常，不仅无法保证消息可靠投递，还使得其他系统的数据库出现脏数据导致对账、报表等数据错误；本方案将中心化应用系统的各系统提取功能，封装成微服务，并注册到服务注册中心，服务和服务之间的通信基于本地可靠消息数据表和rocketmq消息队列将上游服务和下游服务建立消息关联，采用可靠消息最终一致性方案来实现多个系统的分布式事务；通过可靠消息服务根据第一消息指令和第二消息指令实时更新消息，使得整个业务逻辑的消息链路要么一起成功，要么一起失败，当上游服务或下游服务消息或业务数据异常时，相关的整个消息链路都失败，上游服务或下游服务能够及时获知链路状态，减少业务数据异常，保证消息的可靠投递，使得业务连续性得到保障。
13.本方案中的可靠消息服务根据第一消息指令通知上游服务进行回滚，但当某一系统出现异常时，通过回滚操作，保证同一业务链路中的其他系统数据库中已保存的脏数据及时删除，不会导致最终的对账、报表等数据错误。
14.本方案还提供一种中心化应用系统的集群消息传递系统，基于上述方法构建，包括：封装成微服务的上游服务子系统、下游服务子系统、可靠消息服务和 rocketmq消息队列组件；
15.所述上游服务子系统向可靠消息服务发送消息后开始操作本地业务，上游服务子系统根据本地业务操作结果向可靠消息服务发送第一消息指令；
16.可靠消息服务储存消息并根据第一消息指令通知上游服务进行回滚或对消息进行状态更新；
17.可靠消息服务将状态更新后的消息投递到rocketmq消息队列组件；
18.下游服务子系统从rocketmq消息队列组件中消费消息，当下游服务子系统消费到消息时开始操作本地业务，下游服务子系统根据本地业务操作结果向可靠消息服务发送第二消息指令，可靠消息服务根据第二消息指令对消息进行状态更新。
19.根据本方案可以将银行系统中的各个上游子系统和下游子系统包装成微服务，注册到注册中心，基于可靠消息服务和rocketmq消息队列组件，采用消息最终一致性方案构建分布式事务；保障一个业务链路中各个服务子系统间分布式事务的业务逻辑要么一起成功，要么一起失败。
20.基于mq的消息队列，采用可靠消息最终一致性方案，来实现分布式事务，保障各个服务间分布式事务的业务逻辑要么一起成功，要么一起失败，提高消息传递的可靠性。
21.进一步优化方案为，所述上游服务子系统、下游服务子系统和rocketmq消息队列组件分别具有统一存储接口，所述统一存储接口支持关系型数据储存、非关系型数据储存、本地文件储存和本地缓存。
22.进一步优化方案为，当下游服务子系统消费到消息时存储该消息。
23.进一步优化方案为，还包括后台线程，所述后台线程轮询扫描可靠消息服务中储存的消息，并根据消息的状态删除消息、将消息投递到rocketmq消息队列组件或将消息移入历史表。
24.进一步优化方案为，所述rocketmq消息队列组件进行自我mq故障查询，当 rocketmq消息队列组件查询到mq故障时，构建该mq降级替代方案。
25.进一步优化方案为，所述rocketmq消息队列组件包括：上游mq客户端组件、下游mq
客户端组件、降级开关、rocketmq中间件和队列存储组件；所述队列存储组件中存储有多个降级替代队列；所述队列存储组件为redis存储队列；
26.所述上游mq客户端组件判断状态更新后的消息能否写入，若能则通过 rocketmq中间件写入，否则触发降级开关；
27.降级开关后触发后，下游mq客户端组件判断能否消费到消息，若不能就从队列存储组件中并发读取降级替代队列。
28.根据写入mq的情况来判断mq是否故障，如连续5次尝试投递消息到mq都发现异常报错，网络无法联通等问题，说明mq故障，此时就可以自动感知以及自动触发降级开关。
29.进一步优化方案为，所述降级开关组件包括zookeeper。利用zookeeper的节点特性，做mq降级的触发开关。
30.进一步优化方案为，还包括故障恢复组件，在降级开关触发后，所述故障恢复组件每隔时间t向rocketmq消息队列组件投递一个消息，判断故障mq是否恢复，若故障mq恢复则关闭降级开关。
31.如果降级开关打开后，mq客户端组件需开启一个线程，每隔一段时间尝试给mq投递一个消息，判断mq是否恢复。
32.优选的，mq客户端组件包括一个后台线程，每隔一段时间尝试给mq投递一个消息，判断mq是否恢复。
33.如果mq恢复可以正常投递消息，此时就可以通过zookeeper关闭降级开关，可靠消息服务继续投递消息到mq，下游服务在确认redis存储的各个队列中已经没有数据之后，就可以切换到mq消费消息。
34.本方案基于开源组件rocketmq开发mq客户端组件，实现自动感知mq故障，自动完成降级功能，自动判断mq故障是否恢复。
35.银行业务不像互联网电商平台那样具有高并发场景，银行业务重点是保障业务的高可用和数据的一致性，具有消息量小，高可用特征。当mq故障，需保障消息持续投递，需采用降级方案，构建mq的替代方案，即基于redis存储队列的降级方案；redis具备队列功能，可将消息写入kv存储格式的队列数据结构中。
36.在上游服务，根据每天的消息量，在redis存储中固定划分几百个队列，对应几百个key，保证每个key对应的数据结构中不会写入过多的消息，而且不会频繁的写少数几个key；一旦mq出现故障，可靠消息服务可以对每个消息通过 hash算法，均匀的写入key对应的存储队列中。
37.下游服务消费mq也通过自行封装的mq客户端组件来实现，mq客户端组件从zookeeper感知到降级开关打开后，判断是否还能继续从mq消费到数据,如果不能，就从redis存储队列的各个预设好的队列中获取数据；每次获取到数据，就交给下游服务的业务逻辑来执行。
38.在实际落地生产时，需要考虑高并发场景下的高可用，本方案保障高可用最大的一个依赖是rocketmq消息队列组件的高可用性；mq一旦完全不可用，就会导致业务系统的各个服务之间无法通过mq来投递消息，导致业务流程中断；这种情况，就需要实现高可用保障机制，本方案中基于队列存储组件的队列支持的高可用降级方案，一旦mq中间件出现故障，立即自动降级为备用方案。
39.进一步优化方案为，还包括本地事务组件，在执行操作a和操作b时分别开启本地事务组件；在执行操作a或操作b失败时，本地事务组件异常退出,并令操作a和操作b停止执行；其中，
40.操作a为：可靠消息服务根据第一消息指令对消息进行状态更新时；
41.操作b为：可靠消息服务将状态更新后的消息投递到rocketmq消息队列时。
42.本系统实现异步调用或通知的服务间的分布式事务保障，如果上游服务子系统的数据库操作没成功，下游服务子系统是不会收到任何通知；如果上游服务子系统的数据库操作成功了，可靠消息服务确保将消息投递给下游服务子系统，而且一定会确保下游服务子系统务必成功处理这条消息。如果上游服务给可靠消息服务发送消息的过程出错，通过回滚操作上游服务可以感知到可靠消息服务调用异常，就不用执行业务链路的后续流程。
43.优选地，通过建设后台进程服务轮询处理消息数据，根据第一消息指令得到可靠消息服务中存储的消息状态是“待确认”时，在可靠消息服务里开发一个后台定时运行的线程，不停的检查各个消息的状态；如果一直是“待确认”状态，就认为这个消息出了问题，此时回调上游服务提供的一个接口，确认此消息对应的存储操作。根据第一消息指令得到如果上游服务执行成功，可靠消息服务就将消息状态修改为“已发送”，同时进行下一步投递消息；如果上游服务执行失败，可靠消息服务将数据库中的消息删除即可。
44.优选的，通过建设后台进程服务轮询处理消息数据，根据第二消息指令可靠消息服务里开发一个后台线程，不断检查消息状态，如果根据第二消息指令得到的消息状态是“已发送”，说明下游服务没有处理成功，此时可靠消息服务可尝试重新投递消息到rocketmq消息队列，让下游服务再次处理。
45.本发明与现有技术相比，具有如下的优点和有益效果：
46.本发明提供的一种中心化应用系统的集群消息传递方法及系统，将中心化应用系统的功能封装成微服务，并注册到服务注册中心，根据业务传递形成上下游服务，服务和服务之间通过可靠消息服务和rocketmq消息队列将上游服务和下游服务建立消息关联，采用可靠消息最终一致性方案来实现多个系统的分布式事务；通过可靠消息服务根据第一消息指令和第二消息指令实时更新消息，使得整个业务逻辑的消息链路要么一起成功，要么一起失败，当上游服务或下游服务消息或业务数据异常时，相关的整个消息链路都失败，上游服务或下游服务能够及时获知链路状态，减少业务数据异常，保证消息的可靠投递，使得业务连续性得到保障。
附图说明
47.为了更清楚地说明本发明示例性实施方式的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。在附图中：
48.图1为中心化应用系统的集群消息传递系统工作流程示意图；
49.图2为rocketmq消息队列组件工作流程示意图。
具体实施方式
50.为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明作进一步的详细说明，本发明的示意性实施方式及其说明仅用于解释本发明，并不作为对本发明的限定。
51.实施例1
52.本实施例提供一种中心化应用系统的集群消息传递方法，提取中心化集群应用系统的功能封装成微服务并注册到服务中心，根据功能的业务传递链形成上游服务和下游服务，上游服务和下游服务的消息传递过程为：
53.上游服务向可靠消息服务发送消息后开始操作本地业务，上游服务根据本地业务操作结果向可靠消息服务发送第一消息指令；
54.可靠消息服务储存消息并根据第一消息指令通知上游服务进行回滚或对消息进行状态更新；
55.可靠消息服务将状态更新后的消息投递到rocketmq消息队列；
56.下游服务从rocketmq消息队列中消费消息，当下游服务消费到消息时开始操作本地业务，下游服务根据本地业务操作结果向可靠消息服务发送第二消息指令，可靠消息服务根据第二消息指令对消息进行状态更新。
57.具体实施细节如下：
58.一、可靠消息服务
59.实现可靠消息最终一致性方案，先建设可靠消息服务，主要功能包括：接收上游消息、保存消息、投递消息。
60.上游服务投递消息步骤：
61.1、接收上游发送的消息：上游服务需要发送一条消息给可靠消息服务。
62.2、保存消息，消息状态为“待确认”；为了满足更多的中心化的系统，保存消息的介质包括关系型数据库，如mysql、oracle等，非关系型数据库，如 elasticsearch等，本地文件，本地缓存。
63.3、上游服务执行本地存储的业务数据操作，根据执行结果，向可靠消息服务发送第一消息指令。
64.(1)如果本地执行成功，发送确认指令，可靠消息服务将消息状态更新为“已发送”，同时将消息发送给rocketmq消息队列。
65.(2)如果本地执行失败，发送删除指令，可靠消息服务删除那条消息。
66.下游服务接收消息步骤：
67.1、下游服务从rocketmq消息队列消费消息，如果消费到了消息，就操作本地存储。
68.2、操作本地存储成功就发送成功指令(第二消息)通知可靠消息服务。
69.3、可靠消息服务把消息的状态设置为“已完成”。
70.下游服务对消息的可靠接收：
71.在消息投递的过程中，如果某个环节出现异常，不能保证消息可靠投递，可通过以下两种机制，可保证可靠消息服务一定能完成消息到mq的投递。
72.(1)异常机制阻止后续流程：如果上游服务给可靠消息服务发送待确认消息的过程出错，上游服务可以感知到调用异常，就不用执行后续流程。
73.(2)后台进程轮询消息数据：如果上游服务操作完本地存储之后，发送指令通知可靠消息服务确认消息或者删除消息时，出现了问题，如没通知成功，或没执行成功，或可靠消息服务没成功的投递消息到rocketmq消息队列。
74.下游服务对消息的可靠接收：后台进程轮询处理。可靠消息服务里开发一个后台线程，不断检查消息状态，如果消息状态是“已发送”，说明下游服务没有处理成功，此时可靠消息服务开启重试机制，尝试重新投递消息到mq，让下游服务再次处理。具体可分为三种情况：
75.1、重试机制达上限，通知上游服务进行回滚。
76.2、重试机制达上线，发送告警，人工处理。
77.3、按时间阶梯不停的重试，达到时间阶梯后，强制认为下游已处理，此种情况多用于下游数据采集，不用于业务处理。
78.实施例2
79.本实施例提供一种中心化应用系统的集群消息传递系统，基于上一实施例所述的方法构建，如图1所示，包括：将中心化应用系统的功能封装成微服务，并注册到服务注册中心，根据业务传递形成上下游服务，以及可靠消息服务和 rocketmq消息队列组件；
80.所述上游服务子系统向可靠消息服务发送消息后开始操作本地业务，上游服务子系统根据本地业务操作结果向可靠消息服务发送第一消息指令；
81.可靠消息服务储存消息并根据第一消息指令对消息进行状态更新或删除该消息；
82.可靠消息服务将状态更新后的消息投递到rocketmq消息队列组件；
83.下游服务子系统从rocketmq消息队列组件中消费消息，当下游服务子系统消费到消息时开始操作本地业务，下游服务子系统根据本地业务操作结果向可靠消息服务发送第二消息指令，可靠消息服务根据第二消息指令对消息进行状态更新。
84.所述上游服务子系统、下游服务子系统和rocketmq消息队列组件分别具有统一存储接口，所述统一存储接口支持关系型数据储存、非关系型数据储存、本地文件储存和本地缓存。
85.当下游服务子系统消费到消息时存储该消息。
86.还包括后台线程，所述后台线程轮询扫描可靠消息服务中储存的消息，并根据消息的状态删除消息、将消息投递到rocketmq消息队列组件或将消息移入历史表。
87.所述rocketmq消息队列组件进行自我mq故障查询，当rocketmq消息队列组件查询到mq故障时，构建该mq降级替代方案。
88.具体实现方式为：
89.1、将历史遗留系统统一封装
90.步骤1：梳理各个系统要暴露的接口；
91.步骤2：将暴露的接口封装从服务；
92.步骤3：将服务注册到sofa注册中心。
93.2、消息投递步骤
94.步骤1：向可靠消息服务发送消息；
95.步骤2：可靠消息服务保存消息，状态为“待确认”；
96.步骤3：上游服务子系统操作本地数据库；
97.步骤4：上游服务子系统向可靠消息服务发送第一消息指令，包括：
98.(1)确认指令；
99.(2)删除指令。
100.步骤5：可靠消息服务更新消息状态，
101.(1)如果是确认指令，就更新消息状态为“已发送”102.(2)如果是删除指令，就更新消息状态为“删除消息”。
103.步骤6：可靠消息服务将消息投递到rocketmq消息队列组件；
104.步骤7：下游服务子系统消费消息；
105.步骤8：下游服务子系统执行本地数据库操作；
106.步骤9：下游服务子系统对消息进行手动ack确认；
107.步骤10：消息处理成功，下游服务子系统发送第二消息指令通知可靠消息服务，可靠消息服务更新消息状态为“已完成”。
108.3、后台线程：后台线程扫描数据库消息表，对不同状态的消息做不同处理。
109.(1)“已发送”：移入历史表。
110.(2)“超时”：触发消息服务，执行消息投递到rocketmq消息队列组件。
111.如图2所示，所述rocketmq消息队列组件包括：上游mq客户端组件、下游 mq客户端组件、降级开关、rocketmq中间件和队列存储组件；所述队列存储组件中存储有多个降级替代队列；
112.所述上游mq客户端组件判断状态更新后的消息能否写入，若能则通过 rocketmq中间件写入，否则触发降级开关；
113.降级开关后触发后，下游mq客户端组件判断能否消费到消息，若不能就从队列存储组件中并发读取降级替代队列。
114.所述降级开关组件包括zookeeper。利用zookeeper的节点特性，做mq降级的触发开关。
115.封装mq客户端组件。基于开源mq客户端软件进行封装，并发布形成mq客户端组件，此组件重点功能包括自动感知mq故障，自动完成降级功能，自动判断mq是否恢复。
116.还包括故障恢复组件，在降级开关触发后，所述故障恢复组件每隔时间t 向rocketmq消息队列组件投递一个消息，判断故障mq是否恢复，若故障mq恢复则关闭降级开关。
117.还包括本地事务组件，在执行操作a和操作b时分别开启本地事务组件；在执行操作a或操作b失败时，本地事务组件异常退出,并令操作a和操作b停止执行；其中，
118.操作a为：可靠消息服务根据第一消息指令对消息进行状态更新时；
119.操作b为：可靠消息服务将状态更新后的消息投递到rocketmq消息队列时。
120.上游服务投递消息需要注意：可靠消息服务执行存储操作时，存储中的消息状态和投递消息到mq要开启本地事务，即这两步操作要么成功，要么失败。如果存储里更新消息状态失败，就抛异常退出，不再进行消息的投递，如果消息投递失败，就抛异常让本地事务回滚。
121.下游服务消费消息需要注意：下游服务的接口要实现幂等性，保证多次处理一个消息，不会插入重复数据。
122.使用redis存储需要注意：
123.(1)任何redis存储的集合类数据结构，建议写入数据量不要过大，否则会导致大value的情况发生，引发严重的后果，因此绝不能在redis里搞一个key，就拼命往这个数据结构中一直写入消息，这是肯定不行的。
124.(2)不能往少数key对应的数据结构中持续写入数据，那样会导致热key 的产生，也就是某几个key特别热。因为redis集群，一般是根据key来hash，定位到对应的服务器上，如果总是写少数几个key，会导致reids集群中的某台服务器访问过高，负载过大。
125.不同业务不同的处理策略
126.(1)根据不同业务，设置消息的顺序性，消息投递是否有顺序，顺序的排序配置等。
127.(2)根据不同业务，生成对应的key。
128.以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。