CN110365729A - 响应式消息推送、接收方法和响应式消息推送*** - Google Patents

Abstract

本发明公开了一种响应式消息推送、接收方法和***，客户端产生业务请求发送给服务器，服务器判断是否接收到客户端发送的业务请求，若是则从消息队列中提取出与客户端相关的推送消息，并将推送消息与业务响应报文整合成为响应报文后向客户端反馈；客户端在接收到响应报文后，从其中过滤出推送消息并进行广播；本申请基于请求/响应式通信方式，在服务器在生成的业务响应报文中整合进与该客户端相关的推送消息，在向客户端反馈业务响应报文同时，与该客户端相关的推送消息随业务响应报文一起反馈给了客户端，减少了为了实现消息推送建立通信会话连接所需运行的资源消耗，解决了现有消息推送方式存在耗费***资源的技术问题。

Description

响应式消息推送、接收方法和响应式消息推送***

技术领域

本发明属于消息传输技术领域，具体地说，是涉及一种响应式消息推送、接收方法和响应式消息推送***。

背景技术

消息推送服务的基础思想是将客户端请求信息和服务端被动响应请求，改为服务器主动向客户端发送信息。

消息推送服务的通用架构中，具有消息推送服务功能的软件***，符合客户端/服务端的架构，服务端一定会包含消息产生模块，对应客户端会有消息使用模块，此外也必定会有服务端和客户端的消息通讯模块来完成从服务端到客户端的消息推送通讯实现。

目前消息推送的通讯技术实现方式主要有两种：1、Pull型，客户端和服务端定时建立连接，通过客户端周期性轮询消息请求的方式来查询是否有新的消息，在有新的消息时，服务端向客户端推送消息；这种方式在使用上限制较大，轮询的频率不能过慢或者过快，过慢会导致部分消息更新不及时，过快又会消耗更多的***资源、流量以及电量，对用户体验的影响也比较大；2、Push型，该推送是基于TCP长连接实现的，客户端和服务端建立TCP长连接之后，客户端定期向服务端发送心跳包用于保持链接，有消息的时候，服务端直接通过这个已经建立好的TCP长连接通知客户端；这种方式中需要维护海量的TCP长连接，同样存在耗费***资源的问题。

发明内容

本申请提供了一种响应式消息推送、接收方法和响应式消息推送***，解决现有消息推送方式存在耗费***资源的技术问题。

为解决上述技术问题，本申请采用以下技术方案予以实现：

提出一种响应式消息推送方法，包括：判断是否接收到客户端发送的业务请求；若是，从消息队列中提取出与所述客户端相关的推送消息；将所述推送消息与业务响应报文整合成为响应报文；向所述客户端反馈所述响应报文。

提出一种响应式消息接收方法，包括：向服务器发送业务请求之后，监听所述服务器反馈的响应报文；在接收到所述响应报文后，从所述响应报文中过滤出所述推送消息；广播所述推送消息。

提出一种响应式消息推送***，包括客户端和服务器，所述客户端包括业务请求模块、客户端通信模块、推送消息过滤模块和广播模块；所述服务器包括服务器通信模块、推送消息提取模块和推送消息整合模块；所述业务请求模块，用于生成业务请求；所述客户端通信模块，用于向所述服务器发送所述业务请求；所述服务器通信模块，用于接收所述业务请求；所述推送消息提取模块，用于判断是否接收到所述业务请求，若是，则从消息队列中提取与所述客户端相关的推送消息；所述推送消息整合模块，用于将所述推送消息与业务响应报文整合成为响应报文；所述服务器通信模块，用于向所述客户端反馈所述响应报文；所述推送消息过滤模块，用于在所述客户端通信模块监听并接收到所述响应报文之后，从所述响应报文中过滤出所述推送消息；所述广播模块，用于广播所述推送消息。

与现有技术相比，本申请的优点和积极效果是：本申请提出的响应式消息推送、接收方法和响应式消息推送***中，基于请求/响应式通信方式，在客户端向服务器发送业务请求后，服务器在生成的业务响应报文中整合入与该客户端相关的推送消息，在向客户端反馈业务响应报文同时，与该客户端相关的推送消息随业务响应报文一起反馈给了客户端，客户端通过解析过滤出推送消息后进行广播；相比现有的消息推送方式，本申请中无需客户端与服务器定时建立连接，更无需客户端与服务器建立TCP长连接，在客户端与服务器之间建立例如商户信息查询、下单、支付等请求/响应式的业务会话时，在业务响应报文中整合与客户端相关的推送消息，实现业务响应报文反馈的同时也就实现了消息的推送，在没有额外增加通信会话连接处理的情况下实现了消息推送的目的，减少了为了实现消息推送建立通信会话连接所需运行的资源消耗，解决了现有消息推送方式存在耗费***资源的技术问题。

结合附图阅读本申请实施方式的详细描述后，本申请的其他特点和优点将变得更加清楚。

附图说明

图1 为本申请提出的响应式消息推送、接收方法的流程图；

图2为本申请提出的响应式消息推送***的架构图；

图3为本申请提出的客户端接收响应报文后的处理流程图。

具体实施方式

下面结合附图对本申请的具体实施方式作进一步详细地说明。

本申请提出的响应式消息推送、接收方法，建立在如图2所示的响应式消息推送***基础上，该***包括客户端1和服务器2，二者之间的服务模型是请求/响应式，由客户端1发起业务请求，由服务器2给予响应。

如图1所示，本申请提出的响应式消息推送（服务器）、接收（客户端）方法，包括如下步骤：

步骤S11：客户端向服务器发送业务请求。

以智能手机为客户端为例，智能手机向服务器发出订餐下单、商品下单、商户信息查询、菜品查询、支付等业务请求。

步骤S12：服务器判断是否接收到客户端发送的业务请求，若是，步骤S131：从消息队列中提取出与客户端相关的推送消息，以及，步骤S132：基于业务请求生成业务响应报文。

服务器在接收到了客户端发送的业务请求之后，一方面根据请求/响应式通信模式的正常流程生成与该业务请求对应的业务响应报文，例如该业务请求为商户信息查询，则业务响应报文则是将该商户的信息封装成业务响应报文；另一方面从消息队列中提取出与该客户端相关的推送消息。

消息队列为服务器预先生成的多条等待被推送的推送消息组合，当服务器接收到业务请求后，从业务请求携带的信息中解析出客户端信息，从消息队列中提取出与该客户端相关或对应的多条推送消息。

从消息队列提取推送消息时，按照设定规则将与该客户端相关的多条推送消息打包，封装成为消息数据包，并可以根据需要对消息数据包进行加密或者数字签名处理，以提升消息通信的安全性以及完整性校验能力。

生成消息数据包后，将消息数据包进行存储并标记状态为待发送。

步骤S14：将推送消息与业务响应报文整合成为响应报文。

服务器将生成与客户端相关的推送消息，也即上述生成的消息数据包与业务响应报文整合成为一条响应报文，作为请求/响应模式的响应报文。

步骤S15：向客户端反馈响应报文。

服务器将整合的响应报文反馈给客户端。响应报文发送成功之后，存储的消息数据包的状态修改为已发送。

步骤S16：客户端接收到响应报文后，从响应报文中过滤出推送消息。

客户端在发送了业务请求之后，监听服务器反馈的响应报文，在监听并接收到服务器反馈的响应报文之后，首先将响应报文拦截，判断响应报文中是否包含有推送消息相关的消息数据包，若存在则进一步过滤出推送消息的消息数据包以及业务响应报文，一方面将去除了推送消息的业务响应报文返回业务处理模块，一方面对消息数据包进行解密、数字签名识别、解包等处理得到推送消息。

在对响应报文进行过滤时，可以对消息数据包进行一系列的校验，判断消息数据包的来源合法性、正确性、完整性以防篡改或通信中的传输异常，客户端身份一致性校验等等。

解包出的推送消息先存入缓存或者存储器中，然后通知广播模块，以异步的方式获取推送消息；这种通过缓存或者存储器存储后再广播的方式，既保证了推送消息不会丢失，又以异步的方式保证了解析的效率不会因为推送消息的使用而造成明显的延迟。

推送消息缓存或存储后，首先标记为待使用状态，当广播模块广播完的推送消息再标记为已使用状态。

步骤S17：客户端广播推送消息。

客户端根据实际应用情景以发布订阅的方式，广播消息事件，采用广播的优点在于以异步方式进行消息的消费使用。

上述本申请提出的响应式消息推送、接收方法中，基于请求/响应式通信方式，在客户端向服务器发送业务请求后，服务器在生成的业务响应报文中整合进与该客户端相关的推送消息，在向客户端反馈业务响应报文同时，与该客户端相关的推送消息随业务响应报文一起反馈给了客户端，客户端通过解析过滤出推送消息后进行广播；相比现有的消息推送方式，本申请中无需客户端与服务器定时建立连接，更无需客户端与服务器建立TCP长连接，在客户端与服务器之间建立例如商户信息查询、下单、支付等请求/响应式的业务会话时，在业务响应报文中整合与客户端相关的推送消息，实现业务响应报文反馈的同时也就实现了消息的推送，在没有额外增加通信会话连接处理的情况下实现了消息推送的目的，减少了为了实现消息推送建立通信会话连接所需运行的资源消耗，解决了现有消息推送方式存在耗费***资源的技术问题。

由于响应报文的长度对通信处理时间会造成影响，因此在上述步骤S131中，可以对提取消息的最大条数进行限制，限制的原则为消息数据包的长度小于本次业务请求涉及业务场景的响应时间要求所能处理的报文长度，也即限制推送消息的消息数据包的长度要小于一个设定阈值，而该设定阈值要基于业务请求所限定的响应时间来确定。例如，一个支付场景要求响应时间为小于0.5秒，根据正常网络环境计算响应时间为0.1秒，原始支付响应报文长度小于200K，当响应报文总长度为600K时响应时间为0.5秒，则消息数据包的总长度要小于400K，最好在60K-200K。

上述本申请实施例中，在业务请求的业务响应报文中额外增加推送消息的内容，为了避免推送消息对原业务请求的处理产生影响，除了上述提出的通过限制推送消息长度小于设定阈值，以避免影响业务请求所限定的响应时间的手段之外，本申请还提出具体异步化的消息数据包与业务响应报文的整合机制，保证原有业务请求不因整合消息数据包而导致响应堵塞：1、将推送消息与业务响应报文整合成为响应报文之前，判断业务响应报文是否允许合并消息；若是，则将推送消息与业务响应报文整合为响应报文；否则，向客户端反馈业务响应报文；对于客户端静态资源请求或实时性要求极高的业务请求的业务响应报文，不会在其中增加推送消息，以避免延时影响客户体验；或者，2、将推送消息与业务响应报文整合成为响应报文之前，判断是否存在推送消息；若是，将推送消息与业务响应报文整合成为响应报文；否则，向客户端反馈业务响应报文；业务响应报文与推送消息的数据打包是同步进行的，当业务响应报文已经生成可以进行反馈时，首先判断一次是否存在已经打包好的消息数据包，若存在则整合，若不存在则直接反馈业务响应报文，不会因为等待消息数据包而延迟业务请求报文的反馈；或者，3、将推送消息与业务响应报文整合成为响应报文之前，方法还包括：判断业务响应报文的长度是否允许合并推送消息；若是，将推送消息与业务响应报文整合成为响应报文；否则，向客户端反馈业务响应报文；由于同一个业务场景，不同的客户端响应内容长度会有差异，该判断步骤能够避免过长的原始业务响应报文再叠加上消息数据包而造成通信时间超过该业务场景所要求的响应时间。以上三种手段可根据实际应用需求结合和/或排序，本申请实施例不予限定。

而相应的，在客户端收到响应报文时，如图3所示，首先步骤S31：判断报文中是否包含有消息数据包，若包含有消息数据包，则进一步的步骤S32：判断消息数据包的合法性、正确性和完整性，进而再步骤S33：解析消息数据包为多条推送消息并存储，也即从响应报文中过滤出推送消息；步骤S34：通知广播模块，同时，步骤S35：将解析出的业务响应报文返回客户端通信模块，并由客户端通信模块发送给业务处理模块使用。

基于上述提出的响应式消息推送、接收方法，本申请还提出一种响应式消息基于上述提出的响应式消息推送、接收方法，本申请还提出一种响应式消息 ***，如图2所示，包括客户端1和服务器2，客户端1包括业务请求模块11、客户端通信模块12、推送消息过滤模块13和广播模块14；服务器2包括服务器通信模块21、推送消息提取模块22和推送消息整合模块23。

客户端1的业务请求模块11用于生成业务请求；客户端通信模块12用于向服务器2发送业务请求；服务器2的服务器通信模块21用于接收业务请求；推送消息提取模块22用于判断是否接收到业务请求，若是，则从消息队列中提取与客户端1相关的推送消息；推送消息整合模块23用于将推送消息与业务响应报文整合成为响应报文；服务器通信模块21再用于向客户端1反馈该响应报文；客户端1的推送消息过滤模块13在客户端通信模块12监听并接收到响应报文之后，从响应报文中过滤出推送消息；广播模块14则用于广播推送消息。这其中，消息队列中的若干推送消息由消息产生模块26生成。

客户端1还包括存储模块15，推送消息过滤模块13从响应报文中过滤出推送消息之后，将推送消息存储于该存储模块15中，再由广播模块14从存储模块15中读取推送消息并广播给消息处理模块16。而过滤出的业务响应报文则反馈给业务请求模块11应用处理。

为避免业务响应报文过长导致响应报文反馈延迟，服务器2还包括业务处理模块24和整合判断模块25；业务处理模块24用于基于业务请求生成业务响应报文；整合判断模块25则用于在推送消息整合模块将推送消息与业务响应报文整合成为响应报文之前，判断业务响应报文是否允许合并消息；若是，则推送消息整合模块将推送消息与业务响应报文整合为响应报文；否则，服务器通信模块向客户端反馈业务响应报文；或者，在推送消息整合模块将推送消息与业务响应报文整合成为响应报文之前，判断是否存在推送消息；若是，则推送消息整合模块将推送消息与业务响应报文整合为响应报文；否则，服务器通信模块向客户端反馈业务响应报文；或者，在推送消息整合模块将推送消息与业务响应报文整合成为响应报文之前，判断业务响应报文的长度是否适合合并推送消息；若是，则推送消息整合模块将推送消息与业务响应报文整合为响应报文；否则，服务器通信模块向客户端反馈业务响应报文。

下面，以一个具体的实施例（客户端发送商户查询的业务请求）对本申请提出的响应式消息推送***的工作过程做出详细说明。

如图2所示，消息产生模块26在服务器端按照自身程序产生若干推送消息组成消息队列，具体的消息推送流程为：

3.1、客户端1的业务请求模块11根据用户操作产生业务请求，并发送给客户端通信模块12；

3.2、客户端1通过客户端通信模块12向服务器2发送业务请求（商户查询）；

3.3、服务器通信模块21接收到业务请求后，通知推送消息提取模块22；

3.4、推送消息提取模块22从消息队列中提取与客户端1相关的推送消息，并按照约定格式将推送消息打包为消息数据包；

3.4.1、推送消息提取模块22将打包好的消息数据包发送给推送消息整合模块23；

3.5、服务器通信模块21同时将业务请求发送给业务处理模块24；

3.6、业务处理模块24生成业务响应报文返回给服务器通信模块21；

3.7、服务器通信模块21将业务响应报文封装为报文发送给推送消息整合模块23；

3.8、整合判断模块25判断是否存在与该客户端1相关的待推送的消息数据包，若存在则

3.8.1、推送消息整合模块23将消息数据包与业务响应报文整合成为响应报文，并将响应报文返给服务器通信模块21；

3.9、服务器通信模块21将整合的响应报文反馈给客户端1；

3.9.1、服务器通信模块21将响应报文反馈成功后，则通知推送消息提取模块22则将消息数据包的状态修改为已发送；

3.10、客户端通信模块12接收到响应报文后，将响应报文发送给推送消息过滤模块13；

3.11、推送消息过滤模块13检查响应报文中是否包含有消息数据包，如果有则按照约定规则解包，并判断包含的推送消息是否为重复发送，对于重复发送的丢弃处理；非重复发送的则存储至存储模块15中；

3.12、广播模块14从存储模块15中读取推送消息以便进行新推送消息的广播处理；消息处理模块16则根据接收到的广播对消息进行设定处理；

3.13、推送消息过滤模块13完成推送消息过滤后，将去除了消息数据包的业务响应报文返回给客户端通信模块12；

3.14、客户端通信模块12将业务响应报文发送给业务请求模块11处理。

通过上述响应式消息推送***的工作，推送消息在原有业务请求的响应中同时完成推送，节省了消息推送需要的通信资源消耗。为保证原有业务请求不因整合消息数据包而导致响应堵塞，保证原业务请求的非功能性指标不被影响，并最大程度上节约了服务器资源，上述响应式消息推送***中具体的异步化的消息数据包与原有业务响应报文的整合机制，在上述响应式消息推送、接收方法中已经详述，此处不予赘述。

上述本申请提出的响应式消息推送、接收方法和***中，接收方法中，基于请求/响应式通信方式，在客户端向服务器发送业务请求后，服务器在生成的业务响应报文中整合进与该客户端相关的推送消息，在向客户端反馈业务响应报文同时，与该客户端相关的推送消息随业务响应报文一起反馈给了客户端，客户端通过解析过滤出推送消息后进行广播，在没有额外增加通信会话连接处理的情况下实现了消息推送的目的，减少了为了实现消息推送建立通信会话连接所需运行的资源消耗，解决了现有消息推送方式存在耗费***资源的技术问题。

现有技术中，消息推送需要增加额外消息推送的推送连接和通信协议层的处理，大量消耗通信和计算资源；或者，需要额外搭建消息服务***及服务器或购买第三方消息推送服务，增加了IT建设和管理的投入；或者，在原有业务***中引入新的消息通信***及方案会带来信息安全风险，如引入消息推送方案所带来的新的开发包、通信处理机安全加密机制等，会导致原产品和项目的信息安全要求不一致等，相比上述，本申请提出的响应式消息推送、接收方法和***，无需为获取消息额外增加任何通信连接以及请求，减小因消息推送产生的***资源消耗；无需为消息推送增加新***，仅需要在原有业务***中增加诸如推送消息提取模块、整合模块等，不会增加新***建设和运维，节省了***的成本投入；无需引入新的通信机制，也无需集成第三方推送服务，安全及可控性更强。

目前基于客户端/服务器端模式的逻辑架构中，服务器端包含业务通信模块和业务处理模块，客户端包含通信模块和业务请求模块，客户端和服务器之间的服务模型是请求/响应模式，由客户端发起服务请求，服务器给予回应，且通信模块均支持监听、过滤或拦截的扩展。而目前基于客户端/服务器模式的软件***通信实现基本都依赖于成熟的软件通信中间件和模块，其通信符合标准和协议，以Java实现的软件***为例，其WEB通信基本都会使用http协议并遵循JavaEE的Serverlet标准，这一标准和协议都会被WEB中间件良好进行封装（如tomcat、Webaphere，WebLogic等），并不需要软件开发者自行开发基础通信功能；对应的这些通信中间件均支持监听、过滤或拦截功能的扩展；考虑到目前大多数程序无论是JAVA、Nodejs、Python的服务端技术，还是JS、Android、IOS的客户端技术，基本都能符合以上特征，因此，本申请提出的响应式消息推送、接收方法和***方案具有极为广泛的通用性。

应该指出的是，上述说明并非是对本发明的限制，本发明也并不仅限于上述举例，本技术领域的普通技术人员在本发明的实质范围内所做出的变化、改型、添加或替换，也应属于本发明的保护范围。

Claims (10)

1.响应式消息推送方法，其特征在于，包括：

判断是否接收到客户端发送的业务请求；若是，

从消息队列中提取出与所述客户端相关的推送消息；

将所述推送消息与业务响应报文整合成为响应报文；

向所述客户端反馈所述响应报文。

2.根据权利要求1所述的响应式消息推送方法，其特征在于，在接收到客户端发送的业务请求之后，所述方法还包括：基于所述业务请求生成所述业务响应报文。

3.根据权利要求2所述的响应式消息推送方法，其特征在于， 将所述推送消息与业务响应报文整合成为响应报文之前，所述方法还包括：

判断所述业务响应报文是否允许合并消息；若是，则将所述推送消息与所述业务响应报文整合为响应报文；否则，向所述客户端反馈所述业务响应报文。

4.根据权利要求2所述的响应式消息推送方法，其特征在于，将所述推送消息与业务响应报文整合成为响应报文之前，所述方法还包括：

判断是否存在所述推送消息；若是，将所述推送消息与所述业务响应报文整合成为响应报文；否则，向所述客户端反馈所述业务响应报文。

5.根据权利要求2所述的响应式消息推送方法，其特征在于，将所述推送消息与业务响应报文整合成为响应报文之前，所述方法还包括：

判断所述业务响应报文的长度是否允许合并所述推送消息；若是，将所述推送消息与所述业务响应报文整合成为响应报文；否则，向所述客户端反馈所述业务响应报文。

6.根据权利要求1所述的响应式消息推送方法，其特征在于，在从消息队列中提取出与所述客户端相关的推送消息时，所述方法还包括：

限制所述推送消息的长度小于设定阈值；其中，所述设定阈值基于业务请求所限定的响应时间确定。

7.响应式消息接收方法，其特征在于，包括：

向服务器发送业务请求之后，监听所述服务器反馈的响应报文；

在接收到所述响应报文后，从所述响应报文中过滤出所述推送消息；

广播所述推送消息。

8.根据权利要求7所述的响应式消息接收方法，其特征在于，在从所述响应报文中解析出所述推送消息之后，所述方法还包括：

存储所述推送消息；则广播所述推送消息，具体为：读取所述推送消息并广播。

9.响应式消息推送***，包括客户端和服务器，其特征在于，所述客户端包括业务请求模块、客户端通信模块、推送消息过滤模块和广播模块；所述服务器包括服务器通信模块、推送消息提取模块和推送消息整合模块；

所述业务请求模块，用于生成业务请求；所述客户端通信模块，用于向所述服务器发送所述业务请求；

所述服务器通信模块，用于接收所述业务请求；所述推送消息提取模块，用于判断是否接收到所述业务请求，若是，则从消息队列中提取与所述客户端相关的推送消息；所述推送消息整合模块，用于将所述推送消息与业务响应报文整合成为响应报文；所述服务器通信模块，用于向所述客户端反馈所述响应报文；

所述推送消息过滤模块，用于在所述客户端通信模块监听并接收到所述响应报文之后，从所述响应报文中过滤出所述推送消息；所述广播模块，用于广播所述推送消息。

10.根据权利要求9所述响应式消息推送***，其特征在于，所述服务器还包括业务处理模块；所述业务处理模块，用于基于所述业务请求生成所述业务响应报文；

所述服务器还包括整合判断模块，用于

在所述推送消息整合模块将所述推送消息与业务响应报文整合成为响应报文之前，判断所述业务响应报文是否允许合并消息；若是，则推送消息整合模块将所述推送消息与所述业务响应报文整合为响应报文；否则，服务器通信模块向所述客户端反馈所述业务响应报文；或，

在所述推送消息整合模块将所述推送消息与业务响应报文整合成为响应报文之前，判断是否存在所述推送消息；若是，则推送消息整合模块将所述推送消息与所述业务响应报文整合为响应报文；否则，服务器通信模块向所述客户端反馈所述业务响应报文；或，

在所述推送消息整合模块将所述推送消息与业务响应报文整合成为响应报文之前，判断所述业务响应报文的长度是否适合合并所述推送消息；若是，则推送消息整合模块将所述推送消息与所述业务响应报文整合为响应报文；否则，服务器通信模块向所述客户端反馈所述业务响应报文。