一种基于长轮询的微服务同步方法、装置及存储介质与流程

1.本发明涉及一种数据同步方法，尤其是涉及一种基于长轮询的微服务同步方法、装置及存储介质。


背景技术：

2.目前在领域驱动设计下，确定非失血模型的实体或值对象时，通常非同一聚合根的实体之间在拆分时会拆分为多个不同的独立服务，通信时通常会采用同库不同表的方案，但对于体量较大需要分库的场景下则需要建立通信方式交换数据，同时，在需要考虑实时通信的场景下，通常会采用接口实时调用的方式进行数据获取。
3.尤其针对于查询的场景，实际情况中经常会对多个表进行关联，进行查询后组装的方式统一展示，在领域驱动分库分表的微服务体系下，需要展示时无法避免多次调取多个系统接口的场景，查询端的请求只能被迫控制频率，尤其是在下游服务没有背压体系的情况下，更是容易导致下游服务无法消费而导致大面积宕机。
4.针对这种场景，目前常见的做法是采用命令查询职责分离(cqrs)架构体系，cqrs从架构上把crud系统拆分为两部分：命令(command)处理和查询(query)处理，cqrs增加一个q端(查询端)，针对查询场景，实时获取数据变动后产生一张专门针对某一个查询场景的数据展示表，查询时不需要涉及真正的数据存储端，既可以增加展示效率，同时降低了数据存储端的服务稳定性。
5.但同时也会产生一个问题，就是数据同步的方式，常见方式有如非同步的定时同步方式，同步推送的接口方式，基于消息总线的消息通知机制等等。当使用场景为业务用户需要实时获取结果时，非同步方式则无法满足；同步推送方式依赖业务端请求查询端推送数据变动，当查询端过多时，在数据变动时会导致业务端执行效率低下；基于消息总线的消息通知机制可以很好的降低业务端的压力，但是需要额外的消息总线做承载。


技术实现要素：

6.本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种基于长轮询的微服务同步方法、装置及存储介质。
7.本发明的目的可以通过以下技术方案来实现：
8.一种基于长轮询的微服务同步方法，该方法包括：
9.查询端发起同步请求；
10.业务端发现同步请求后判断是否返回应答报文，若是则返回应答报文，否则保留连接，直到查询端主动断开；
11.查询端获取到应答报文后，更新本地微服务，发起下一次的同步请求。
12.优选地，所述的同步请求中包括查询端微服务的当前版本号。
13.优选地，业务端发现同步请求后判断是否返回应答报文的方式包括：
14.将同步请求中查询端微服务的当前版本号与业务端数据库中微服务的版本号进
行比对，若两者不一致则返回应答报文，若两者一致则保留连接。
15.优选地，查询端和业务端保留连接期间，业务端轮询监控本地数据字段的变化。
16.优选地，在业务端轮询监控本地数据字段的变化期间，若业务端数据库中微服务的版本号发生变化后，向查询端返回应答报文。
17.优选地，该方法还包括：
18.在查询端和业务端建立连接后，若超过设定时长后查询端端仍未获得应答报文，则查询端主动断开连接并重新发起同步请求建立连接。
19.优选地，所述的查询端和业务端保留连接的方式包括采用block的方式保留连接。
20.优选地，所述的设定时长与服务器的承载能力呈正相关关系。
21.一种基于长轮询的微服务同步装置，包括存储器和处理器，所述的存储器用于存储计算机程序，所述的处理器用于当执行所述计算机程序时，实现所述的基于长轮询的微服务同步方法。
22.一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的基于长轮询的微服务同步方法。
23.与现有技术相比，本发明具有如下优点：
24.(1)相对于接口通知方式，本发明请求的发起方由业务端转移到查询端，同时采用长轮询的方式减少了连接建立频次，定期重新建立连接的方式也充分利用到了业务端的负载方案，可以有效降低服务器的压力；
25.(2)相对于消息总线的消息通知机制，本发明不用额外开发管理消息总线，不需要额外部署服务；
26.(3)相对于文件同步监听信号文件的方式，本发明减少了磁盘io，为定时扫描的非同步方式额外提供了同步方案。
附图说明
27.图1为本发明一种基于长轮询的微服务同步方法的流程框图。
具体实施方式
28.下面结合附图和具体实施例对本发明进行详细说明。注意，以下的实施方式的说明只是实质上的例示，本发明并不意在对其适用物或其用途进行限定，且本发明并不限定于以下的实施方式。
29.实施例1
30.本实施例提供一种基于长轮询的微服务同步方法，该方法通过长轮询的方式建立查询端与业务端的数据交互通道，在不产生额外成本(如消息总线的搭建)的前提下，降低消息通知时的压力。长轮询查询端发起long polling(长轮询)请求，此时如果业务端没有相关数据，会hold住请求，直到业务端有相关数据，或者等待一定时间超时才会返回。返回后，查询端又会立即再次发起下一次long polling。(所谓的hold住请求指的业务端暂时不回复结果，保存相关请求，不关闭请求连接，等相关数据准备好，写会查询端。)
31.进行长轮询的具体过程为：
32.1、发起polling
33.发起polling很简单，只需向服务器发起请求，此时业务端还未应答，所以查询端与业务端之间一直处于连接状态，该通讯方式本质上使用了长链的方式，提升网络传输效率，减少网络建链次数；
34.2、数据推送
35.如果服务器端有相关数据，此时业务端会将数据通过此前建立的通道发回查询端，确保返回的数据都是有变动的最新数据，减少无效数据传输，降低网络带宽使用；
36.3、polling终止
37.polling终止情况有三种：
38.若业务端返回相关数据，此时查询端收到数据后，关闭请求连接，结束此次polling过程；
39.若查询端等待设定的超时时间后，业务端依然没有返回数据，此时查询端需要主动终止此次polling请求，避免长时间不关闭链接带来的链接假死问题；
40.若查询端收到网络故障或异常，此时查询端自然也是需要主动终止此次polling请求，主动保护机制，确保网络通讯健康情况；
41.4、重新polling
42.终止上次polling后，差选段需要立即再次发起polling请求。这样才能保证拉取数据的及时性，重新建链确保数据变动后同步通知的时效性。
43.具体地，如图1所示，本实施例中基于长轮询的微服务同步方法具体包括如下步骤：
44.查询端发起同步请求；
45.业务端发现同步请求后判断是否返回应答报文，若是则返回应答报文，否则采用block的方式保留连接，直到查询端主动断开；
46.查询端获取到应答报文后，更新本地微服务，发起下一次的同步请求。
47.同步请求中包括查询端微服务的当前版本号。
48.业务端发现同步请求后判断是否返回应答报文的方式包括：
49.将同步请求中查询端微服务的当前版本号与业务端数据库中微服务的版本号进行比对，若两者不一致则返回应答报文，若两者一致则保留连接。
50.查询端和业务端保留连接期间，业务端轮询监控本地数据字段的变化。
51.在业务端轮询监控本地数据字段的变化期间，若业务端数据库中微服务的版本号发生变化后，向查询端返回应答报文。
52.该方法还包括：
53.在查询端和业务端建立连接后，若超过设定时长后查询端端仍未获得应答报文，则查询端主动断开连接并重新发起同步请求建立连接，其中，设定时长根据服务器承载能力设置，该设定时长与服务器的承载能力呈正相关关系。
54.查询端及业务端在进行数据维护时，需要将每次产生的命令赋予版本号，查询端需要维护每次同步时的版本号，以作为同步时的范围依据(也可通过时间戳等方式)。如果展示端采用的是实时构建方式，也可不维护版本号，而是每次全量获取进行命令重演。
55.相对于接口通知方式，本发明请求的发起方由业务端转移到查询端，同时采用长轮询的方式减少了连接建立频次，定期重新建立连接的方式也充分利用到了业务端的负载
方案，可以有效降低服务器的压力；相对于消息总线的消息通知机制，本发明不用额外开发管理消息总线，不需要额外部署服务；相对于文件同步监听信号文件的方式，本发明减少了磁盘io，为定时扫描的非同步方式额外提供了同步方案。
56.实施例2
57.本实施例提供一种基于长轮询的微服务同步装置，包括存储器和处理器，存储器用于存储计算机程序，处理器用于当执行所述计算机程序时，实现如实施例1中所述的基于长轮询的微服务同步方法，基于长轮询的微服务同步方法在实施例1中已详细说明，本实施例不再赘述。
58.实施例3
59.本实施例提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如实施例1中所述的基于长轮询的微服务同步方法，基于长轮询的微服务同步方法在实施例1中已详细说明，本实施例不再赘述。
60.上述实施方式仅为例举，不表示对本发明范围的限定。这些实施方式还能以其它各种方式来实施，且能在不脱离本发明技术思想的范围内作各种省略、置换、变更。