消息推送方法、系统及存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种消息推送方法、系统及存储介质。


背景技术：

2.消息推送是一种应用方将信息传递给用户的机制，当前越来越多的软件通过消息推送与用户进行交互。
3.相关技术中，原生应用(application，app)有较多的消息推送机制，主要有手机厂商通道、第三方推送服务平台、长连接等，但对于h5、小程序等非原生app类型的应用来说，成本较高，往往需要使用短信通知来实现信息推送，而且门槛较高，必须要求获取到用户手机号码，因此，大量应用的消息推送受到限制，导致推送效率低，降低了用户体验。


技术实现要素：

4.本技术实施例的主要目的在于提出一种消息推送方法、系统及存储介质，能够提供准实时的消息推送，提高了推送效率，提高了用户体验。
5.为实现上述目的，本技术实施例的第一方面提出了一种消息推送方法，所述方法包括：应用端向服务端发出业务接口访问请求；服务端接收所述访问请求，根据所述访问请求获取与所述应用端的身份信息对应的目标基本信息，将所述目标基本信息封装进所述业务接口的返回报文中，并将所述返回报文发送至所述应用端；所述应用端接收所述服务端发送的所述返回报文，提取所述返回报文中的所述目标基本信息，根据所述目标基本信息向所述服务端发送消息查询请求；所述服务端根据所述消息查询请求查询所述目标基本信息对应的目标消息详情，向所述应用端发送所述目标消息详情。
6.在一些实施例中，所述根据所述访问请求获取与所述应用端的身份信息对应的目标基本信息，包括：对所述访问请求进行信息拆分，从信息拆分结果中确定所述应用端的身份信息；根据所述身份信息生成与所述访问请求并行的查询子请求；根据所述查询子请求，从预先存储的信息中获取与所述身份信息对应的目标基本信息。
7.在一些实施例中，所述根据所述访问请求获取与所述应用端的身份信息对应的目标基本信息，包括：获取业务服务中产生的消息详情并存储到存储器中，得到第一基本信息；根据所述访问请求，从多个所述第一基本信息中获取与所述应用端的身份信息对应的目标基本信息。
8.在一些实施例中，所述根据所述访问请求，从多个所述第一基本信息中获取与所述应用端的身份信息对应的目标基本信息，包括：提取所述第一基本信息中的通用字段，得到第二基本信息；根据所述访问请求，从多个所述第二基本信息中获取与所述应用端身份信息对应的目标基本信息。
9.在一些实施例中，所述将所述目标基本信息封装进所述业务接口的返回报文中，包括：获取所述业务接口在基于所述访问请求下生成的返回报文；从所述返回报文中确定http协议报文头信息，并将所述目标基本信息封装进所述http协议报文头信息中，以使所
述应用端从所述http协议报文头信息中提取所述目标基本信息。
10.在一些实施例中，所述服务端根据所述消息查询请求查询所述目标基本信息对应的目标消息详情，包括：所述服务端根据所述消息查询请求，通过预设的通用接口从预先存储的信息中查询所述目标基本信息对应的目标消息详情；根据目标数据类型对所述目标消息详情进行封装，并通过所述通用接口向所述应用端发送封装后的所述目标消息详情。
11.在一些实施例中，所述根据目标数据类型对所述目标消息详情进行封装，并通过所述通用接口向所述应用端发送封装后的所述目标消息详情，包括：确定所述目标消息详情中的综合内容和推送内容；保留所述综合内容的数据类型，并通过目标数据类型对所述推送内容进行封装，根据所述综合内容和封装后的所述推送内容得到封装后的所述目标消息详情；通过所述通用接口向所述应用端发送封装后的所述目标消息详情。
12.在一些实施例中，所述向所述应用端发送所述目标消息详情之后，所述方法还包括：所述应用端接收所述服务端发送的所述目标消息详情；根据所述目标消息详情提取得到推送内容，并推送所述推送内容。
13.为实现上述目的，本技术实施例的第二方面提出了一种消息推送系统，所述系统包括应用端和服务端，其中：所述应用端向所述服务端发出业务接口访问请求；所述服务端接收所述访问请求，根据所述访问请求获取与所述应用端的身份信息对应的目标基本信息，将所述目标基本信息封装进所述业务接口的返回报文中，并将所述返回报文发送至所述应用端；所述应用端接收所述服务端发送的所述返回报文，提取所述返回报文中的所述目标基本信息，根据所述目标基本信息向所述服务端发送消息查询请求；所述服务端根据所述消息查询请求查询所述目标基本信息对应的目标消息详情，向所述应用端发送所述目标消息详情。
14.为实现上述目的，本技术实施例的第三方面提出了一种存储介质，所述存储介质为计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面实施例所述的方法。
15.本技术提出的消息推送方法、系统及存储介质，其中，消息推送系统设置有应用端和服务端，在执行消息推送方法时，应用端可以向服务端发送业务接口访问请求，响应于访问请求，服务端获取与应用端的身份信息对应的目标基本信息，将目标基本信息封装进业务接口的返回报文中，通过业务接口的返回报文直接将目标基本信息反馈给应用端，不需要依赖其他渠道进行交互，此后应用端可以提取返回报文中的目标基本信息后，得知有消息需要推送，因此向服务端发送消息查询请求进行查询，服务端根据消息查询请求查询目标基本信息对应的目标消息详情，最终向应用端发送目标消息详情，实现消息推送。本技术实施例中通过与业务接口调用结合实现消息推送，能够提供准实时的消息推送，提高了推送效率，提高了用户体验。
附图说明
16.图1是本技术实施例提供的消息推送系统的示意图；
17.图2是本技术另一实施例提供的消息推送系统的示意图；
18.图3是本技术实施例提供的消息推送方法的流程图；
19.图4是图2中的步骤s102的流程图；
20.图5是图2中的步骤s102的流程图；
21.图6是图5中的步骤s302的流程图；
22.图7是图2中的步骤s102的流程图；
23.图8是图2中的步骤s104的流程图；
24.图9是图8中的步骤s602的流程图；
25.图10是图2中的步骤s104之后的流程图；
26.图11是本技术实施例提供的电子设备的硬件结构示意图；
27.图12是本技术实施例提供的应用端的结构示意图；
28.图13是本技术实施例提供的服务端的结构示意图。
具体实施方式
29.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。
30.需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
31.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
32.首先，对本技术中涉及的若干名词进行解析：
33.人工智能(artificial intelligence，ai)：是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学；人工智能是计算机科学的一个分支，人工智能企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器，该领域的研究包括机器人、语言识别、图像识别、自然语言处理和专家系统等。人工智能可以对人的意识、思维的信息过程的模拟。人工智能还是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
34.信息推送，就是"web广播"，是通过一定的技术标准或协议，在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。它根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息。
35.超文本传输协议(hyper text transfer protocol，http)是一个简单的请求-响应协议，它通常运行在tcp之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
36.客户端消息推送，也可以叫消息通知，是一种应用方将信息传递给用户的机制。常见的应用场景，有公司的运营岗或业务系统将营销消息或结果消息通过短信、微信、消息推送等渠道发送给用户，又例如在用户会员等级变动或者会员身份变更，需要在用户使用应
用页面的同时及时地通知用户了解，或者在页面上进行交互响应，如新增展示内容、或开启新的功能入口等，例如在保险的续保或缴费中经常需要推送续保提示消息或缴费消息。
37.手机原生app有较多的消息推送机制，主要有手机厂商通道、第三方推送服务平台、长连接等，但对于第5代互联网超文本标记语言(hyper text markup language 5th，html5/h5)制作的数字产品(简称h5)、小程序等非原生app类型的应用来说，想实现消息推送是比较受限的。例如如果使用短信通知方式，一则成本比较高，而且必须要求获取到用户手机号码，门槛较高，如果用户未授权手机号，则无法实现短信通知。
38.申请人发现，小程序上实现消息推送是一个难题，用户进入小程序之时，需要对用户的业务线、归属坐席等最新身份信息进行识别，页面也会针对不同身份有差异展示的内容。但因为身份识别涉及多个维度和多个系统因而比较耗时，如果页面阻塞等待身份识别完成之后再进行展示，将显著影响客户体验。而且用户身份可能在后台发生了变化，前端页面也无法主动感知，只能被动等待用户访问某些内容，身份变更才能应用到业务中。另外为了页面性能，前端也会采用缓存，那就更难及时响应身份变更了。
39.因此，对于非原生app应用，即需要一套分布式、低成本、安全高效、易用的应用内消息通知机制，能极大丰富这类应用的交互方式，可以类似原生app一样主动与用户在页面上进行交互。
40.基于此，本技术实施例提供了一种消息推送方法、系统及存储介质，能够提供准实时的消息推送，提高了推送效率，提高了用户体验。
41.本技术实施例提供的消息推送方法、系统及存储介质，具体通过如下实施例进行说明，首先描述本技术实施例中的消息推送系统。
42.消息推送系统设置有应用端和服务端，其中，应用端也可以叫客户端，应用端可以为app、h5、小程序等应用，或者为这些应用的前端页面，服务端是为应用端提供接口服务的设备或软件的统称，在一实施例中，如图1所示，服务端可以为网关，或者，如图2所示，服务端可以为网关加后端服务器的统称，可以为应用端提供服务。本技术实施例中前端主要是利用了前端代理层，用以分离出消息事件，以及对事件响应进行调度；网关主要是从业务请求中拆分请求，将消息附加到业务请求，响应通用的消息详情查询接口；后端提供一个消息服务，以从业务系统接受消息，处理消息缓存等。
43.需要说明的是，常见分布式架构中，面向互联网都会有一个外网网关，前端对后端接口的访问，都会经过网关的负载和转发，因此，本技术实施例中利用网关这一特性来统一处理全局的消息通知，并将网关作为服务端，或者作为服务端的一部分来实现本技术实施例中的功能。此外，服务端还可以是可以实现上述网关功能的网络设备，在此不做具体限制。
44.本技术实施例中的消息推送方法可以通过如下实施例进行说明。
45.本技术实施例可以基于人工智能技术对相关的数据进行获取和处理。其中，人工智能(artificial intelligence，ai)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
46.人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机
视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。
47.本技术实施例提供的消息推送方法，涉及计算机技术领域。本技术实施例提供的消息推送方法可应用于终端中，也可应用于服务器端中，还可以是运行于终端或服务器端中的软件。在一些实施例中，终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等；服务器端可以配置成独立的物理服务器，也可以配置成多个物理服务器构成的服务器集群或者分布式系统，还可以配置成提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn以及大数据和人工智能平台等基础云计算服务的云服务器；软件可以是实现消息推送方法的应用等，但并不局限于以上形式。
48.本技术可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本技术可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本技术，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
49.需要说明的是，在本技术的各个具体实施方式中，当涉及到需要根据用户信息、用户行为数据，用户历史数据以及用户位置信息等与用户身份或特性相关的数据进行相关处理时，都会先获得用户的许可或者同意，例如，获取用户存储的数据以及用户的缓存数据访问请求时，均会先获得用户的许可或者同意。而且，对这些数据的收集、使用和处理等，都会遵守相关国家和地区的相关法律法规和标准。此外，当本技术实施例需要获取用户的敏感个人信息时，会通过弹窗或者跳转到确认页面等方式获得用户的单独许可或者单独同意，在明确获得用户的单独许可或者单独同意之后，再获取用于使本技术实施例能够正常运行的必要的用户相关数据。
50.图3是本技术实施例提供的消息推送方法的一个可选的流程图，图3中的方法可以包括但不限于包括步骤s101至步骤s104。
51.步骤s101，应用端向服务端发出业务接口访问请求；
52.示例性的，本技术实施例中的消息推送方法可以在消息推送系统中执行，消息推送系统中设置有应用端和服务端，用以实现消息推送方法中的内容，在此不再赘述。
53.示例性的，应用端与服务端之间可以进行网络连接，应用端可以通过业务接口与服务端保持连接，业务接口可以为服务端中的接口，例如，可以为网关上的业务接口。在一实施例中，应用端向服务端发出业务接口访问请求，进行常规的业务接口查询，本技术实施例通过与业务接口调用结合，避免应用端高频次轮询影响服务端，且保证安全性，实现了将消息推送与正常的业务接口查询相结合，可以避免新增接口调用，是一种代价较小且安全的方式。
54.步骤s102，服务端接收访问请求，根据访问请求获取与应用端的身份信息对应的目标基本信息，将目标基本信息封装进业务接口的返回报文中，并将返回报文发送至应用端；
55.示例性的，服务端的业务接口在接收到访问请求后，会对访问请求进行相应，生成一个返回报文，在本技术实施例中，服务端接收访问请求后，根据访问请求获取与应用端的身份信息对应的目标基本信息，随后将目标基本信息封装进业务接口的返回报文中，并将返回报文发送至应用端，实现了在不新增新的接口的前提下，通过原先的业务接口实现消息推送。
56.可以理解的是，目标基本信息是消息推送的基本信息，也即消息事件，也可以称为一个通知信息，表明了当前应用端对应的身份信息下有消息需要推送，因此，在服务端接收到访问请求后，可以从中解析得到应用端的身份信息，若有对应身份信息下的消息需要推送，则将这个消息推送的基本信息，也就是目标基本信息封装在返回报文中，一同返回给应用端，不干扰业务接口的入参、出参。对于业务接口来讲，对这个消息通知机制与其接口的结合，是无感知的。
57.步骤s103，应用端接收服务端发送的返回报文，提取返回报文中的目标基本信息，根据目标基本信息向服务端发送消息查询请求；
58.示例性的，应用端在接收到服务端发送的返回报文后，会对返回报文进行解析，从而提取返回报文中的目标基本信息，得知有消息需要推送，由于业务接口返回报文的限制，夹在返回报文里面的目标基本信息并不能完整反应需要推送的内容，也即不能完成反应消息事件的内容，因此应用端可以向服务端发送消息查询请求进行查询。
59.需要说明的是，当应用端为前端，前端可以通过代理层提取返回报文携带的消息事件，针对携带的消息，前端根据消息类型，进行响应，从而生成消息查询请求，并将消息查询请求发送给服务端。需要指出的是，本技术实施例中的应用端可以进行两种形式响应，例如，可以直接调用特定的业务接口进行响应，也可以通过通用接口进一步查询消息详情。
60.步骤s104，服务端根据消息查询请求查询目标基本信息对应的目标消息详情，向应用端发送目标消息详情。
61.示例性的，在服务端接收到应用端发送的消息查询请求后，可以返回具体的内容，因此服务端根据消息查询请求查询目标基本信息对应的目标消息详情，此时需要说明的是，服务端预先存储好多个消息的消息详情，在接收到消息查询请求后，可以从存储的数据中根据应用端的身份信息，查找对应的消息详情，并作为目标消息详情，从而向应用端发送目标消息详情，完成消息推送。
62.需要指出的是，在常见的b/s结构中，除非使用socket等长连接机制，否则无法实现真正的服务端对应用端的主动通知。为近似实现这种效果，一个常规思路是前端进行定时轮询，查询后端接口是否有新消息。但这样有两个问题，一是大量应用端高频次查询，对后端服务器的压力非常大，可能会出现此类轮询比所有其他的业务接口调用量都大，影响业务服务的性能和稳定性。另外，如果应用端在一段时间内没有操作页面访问后端接口，h5等类型应用一般会设计为会话自动过期，如果进行轮询，相当于一直延长客户的会话，过期机制就失效了，对于在公共场合访问h5的这种情况特别不安全。
63.因此，本技术实施例中通过将消息推送与正常的业务接口查询相结合，可以避免新增接口调用，是一种代价较小且安全的方式，预先通过业务接口来返回基本的通知信息，不干扰业务接口的入参、出参，对于业务接口来讲，对这个消息通知机制与其接口的结合，是无感知的，因此可以适用在h5、小程序等非原生app中，能够提供准实时的消息推送，提高
了推送效率，提高了用户体验。
64.本技术实施例中能够提供准实时的消息通知，对于h5这类传统上被动依赖用户发起访问的交互模式，新增了应用主动进行的交互模式。如可以支持耗时任务的异步化，优化客户体验，还可以支持运营推送活动消息，提升转化，可以广泛应用在金融、保险等领域中。
65.需要说明的是，业务接口包括而不限于以太网接口、pos(packet over sonet/sdh)接口等，以太网接口例如是灵活以太网业务接口(flexible ethernet clients，flexe clients)。
66.请参阅图4，在一些实施例中，步骤s102中还可以包括步骤s201至步骤s203：
67.步骤s201，对访问请求进行信息拆分，从信息拆分结果中确定应用端的身份信息；
68.步骤s202，根据身份信息生成与访问请求并行的查询子请求；
69.步骤s203，根据查询子请求，从预先存储的信息中获取与身份信息对应的目标基本信息。
70.示例性的，服务端可以对访问请求进行信息拆分，完成拆分子任务，首先从信息拆分结果中确定应用端的身份信息，检查存储的信息中是否有该身份信息对应的信息需要推送，若有，根据身份信息生成与访问请求并行的查询子请求，根据查询子请求，从预先存储的信息中获取与身份信息对应的目标基本信息。本技术实施例中服务端负责从业务请求中分拆出消息查询子任务，会针对每一个业务接口请求，派生出一个并行的子请求，原请求正常路由到对应的业务接口服务器，新增的子请求并行访问消息缓存，以身份信息，也就是用户标识(userid)为关键字查询消息缓存中是否有该用户的最新消息，最终将消息事件附加到业务接口的返回报文中，一同返回给应用端。
71.需要说明的是，服务端对访问请求进行信息拆分有个前提，是拿到用户标识userid。根据不同的鉴权机制，userid可能从访问请求的消息头详情(http header)中直接拿到，也可能拿到json网络令牌(json web token，jwt)后解密获得，也可能拿到token，从鉴权服务交换得到userid。因此只有用户本人访问页面接口才能获取到自己的消息。
72.需要指出的是，jwt是为了在网络应用环境间传递声明而制定的一种基于json的开放标准((rfc7519)。jwt是一个轻便的安全跨平台传输格式，定义了一个紧凑的自包含的方式用于通信双方之间以json对象行使安全的传递信息。广义上讲jwt是一个标准的名称；狭义上讲jwt指的就是用来传递的那个token字符串。jwt用于放置如userid和另外一些非敏感但业务必须的数:如用户名、小区号等，其他敏感数据，如用户姓名、身份证号、手机号则不放置于jwt中。
73.此外，在拆分中，服务端针对所有请求都拆分出一个消息查询请求，复杂一点的，可以在redis中缓存一下上次消息查询的时间，在一定时长内的(如3秒内已查询过)可以不再拆分出消息查询请求以免查询频率过高。如果总体接口请求并不很频繁可以采用简单方案。
74.不仅如此，本技术实施例中服务端可以设置白名单，可以基于配置针对某些请求免拆分，例如埋点接口调用可能会非常频繁，可将此类接口加入拆分白名单，不进行拆分。
75.请参阅图5，在一些实施例中，步骤s102中还可以包括步骤s301至步骤s302：
76.步骤s301，获取业务服务中产生的消息详情并存储到存储器中，得到第一基本信息；
77.步骤s302，根据访问请求，从多个第一基本信息中获取与应用端的身份信息对应的目标基本信息。
78.示例性的，消息一般是由业务服务产生的，且不同业务的消息内容结构是可能有较大差异的。本技术实施例中采用了消息抽象和统一封装的处理。后端或业务系统产生一个新消息后，对于具体的消息详情，由服务端获取业务服务中产生的消息详情并储存在数据库等持久化设备，得到第一基本信息，因此，第一基本信息为预先存储在存储器中的信息，随后，服务端可以根据访问请求，从多个第一基本信息中获取与应用端的身份信息对应的目标基本信息。
79.例如，用户在个人中心修改了个人信息，触发了异步的身份识别，识别完成本身就是一个消息，因此，服务端将此消息相关的业务信息如是否为客户、是否为在拨库、业务线、归属坐席um等字段，存放在存储器中，完成存库，库中的信息就是第一基本信息。
80.请参阅图6，在一些实施例中，步骤s302中还可以包括步骤s401至步骤s402：
81.步骤s401，提取第一基本信息中的通用字段，得到第二基本信息；
82.步骤s402，根据访问请求，从多个第二基本信息中获取与应用端的身份信息对应的目标基本信息。
83.示例性的，本技术实施例中对于消息事件，会数据结构抽象为统一通用的几个字段，因此将提取第一基本信息中的通用字段，得到第二基本信息，最终根据访问请求，从多个第二基本信息中获取与应用端的身份信息对应的目标基本信息。
84.第二基本信息是服务端按照消息通知的规范，生成的一个消息事件，并放到存储器中，存储器可以是redis缓存。因为一个用户可能有多条消息，因此消息是一个列表，为了避免对业务接口访问性能有影响，携带的消息包含最少字段，且均为短字段。
85.在一实施例中，目标基本信息中包含的消息id、消息类型、消息生成服务名，例如，第二基本信息可以包含如下信息：
86.事件key：msg_notify_[userid]//其中userid为用户的唯一id，确保只有用户本人才能访问；
[0087]
事件value：消息id、消息类型、消息生成服务名；
[0088]
例如，第二基本信息中起到身份识别的消息如下：
[0089]
事件key：msg_notify_[userid]；
[0090]
事件value：[{msgid:100000001001,msgtype:”userrecognize”，msgsrv:”userservice”}]；
[0091]
可以理解的是，在提取第一基本信息中的通用字段的过程中，本技术实施例可以预先定义一些通用字段，例如：
[0092]
msgid:100000001001：消息id，用以标记不同消息；
[0093]
msgtype:”userrecognize”：消息类型，用以区分消息类型，以做不同响应和处理；
[0094]
类型”userrecognize”：代表有新的用户身份被识别，前端可以相应地，去查询最新的身份，引导用户跳转到符合身份的特定页面，实现了由后端通知前端主动与用户交互的目标；
[0095]
msgsrv:”userservice”：用以标识消息的来源(服务方)，当需要获取消息详情时，可以根据此值路由到相应的服务获取消息详情。
[0096]
可以理解的是，上述实施例中的消息事件，主要完成消息通知的作用，且不能因为消息部分的内容过长影响宿主业务接口请求的性能，因此事件相关的数据经过提炼，只传递最必要最有用的几个字段。事件相关的详情可以由前端根据不同的消息类型，后续发起独立请求来获取更多详情以支持消息事件的处理，也就是上述实施例中的消息查询请求。
[0097]
请参阅图7，在一些实施例中，步骤s102中还可以包括步骤s501至步骤s502：
[0098]
步骤s501，获取业务接口在基于访问请求下生成的返回报文；
[0099]
步骤s502，从返回报文中确定http协议报文头信息，并将目标基本信息封装进http协议报文头信息中，以使应用端从http协议报文头信息中提取目标基本信息。
[0100]
示例性的，本技术实施例中服务端在整合和返回报文中，可以在查询到消息后，在返回前，将消息封装进返回报文的http协议报文头信息中。具体的，http协议报文头信息是一个报文头，也即http报文头或http头，本技术实施例中为进一步减少耦合，消息相关数据都放在业务接口请求和返回报文的http头里，不干扰业务接口的入参、出参，对于业务接口来讲，对这个消息通知机制与其接口的结合，是无感知的。
[0101]
示例性的，服务端查询到新消息后，将其序列化为字符串，以特定关键字x-msg-notify-events存入业务接口返回的http协议报文头信息中，例如，将下列消息事件封装在http协议报文头信息中：
[0102]
header：x-msg-notify-events；
[0103]
value：[{msgid:100000001001,msgtype:”userrecognize”，msgsrv:”userservice”},{
…
}]；
[0104]
需要指出的是，字段分别为消息id、消息类型、消息生成服务名。
[0105]
此外，需要说明的是，http报文体body中也可以放置消息。但这个对于业务接口的报文，有侵入性、耦合性太强，甚至需要在所有业务接口文档中说明字段的含义，需要关注消息机制细节增加负担，也容易出现字段冲突和报文结构的互相影响。此外，如果业务接口出现异常无报文返回，消息也难以附加，因此，本技术实施例中优先将信息封装在http协议报文头信息中。
[0106]
请参阅图8，在一些实施例中，步骤s104中还可以包括步骤s601至步骤s602：
[0107]
步骤s601，服务端根据消息查询请求，通过预设的通用接口从预先存储的信息中查询目标基本信息对应的目标消息详情；
[0108]
步骤s602，根据目标数据类型对目标消息详情进行封装，并通过通用接口向应用端发送封装后的目标消息详情。
[0109]
示例性的，本技术实施例中设计一个通用接口，可用于查询消息推送的详情，在应用端使用代理层提取返回报文携带的消息事件后，针对携带的消息，应用端根据消息类型，可以通过通用接口进一步查询消息详情。具体的，服务端根据消息查询请求，通过预设的通用接口从预先存储的信息中查询目标基本信息对应的目标消息详情，随后根据目标数据类型对目标消息详情进行封装，并通过通用接口向应用端发送封装后的目标消息详情。
[0110]
需要说明的是，通用接口是服务端主导的一个接口，是一个统一的查询接口。因为消息来源于不同服务，消息详情需要各业务系统来提供。但业务系统一般情况下也不用单独设计消息详情查询接口，因此可以仅实现通用的接口以返回消息详情，接口由服务端提供给应用端。因为消息来源于不同服务，消息详情查询可以由服务端来转发到对应的服务，
从特定业务系统获取到消息详情后，服务端返回报文到应用端中。
[0111]
需要指出的是，目标数据类型是预设的一种数据类型，通过目标数据类型对目标详细详情进行封装后，可以适应字段差异和扩展，本技术实施例中可以对目标消息详情的全部内容通过目标数据类型的格式进行封装，也可以只对目标消息详情的部分内容通过目标数据类型的格式进行封装。
[0112]
请参阅图9，在一些实施例中，步骤s602中还可以包括步骤s701至步骤s703：
[0113]
步骤s701，确定目标消息详情中的综合内容和推送内容；
[0114]
步骤s702，保留综合内容的数据类型，并通过目标数据类型对推送内容进行封装，根据综合内容和封装后的推送内容得到封装后的目标消息详情；
[0115]
步骤s703，通过通用接口向应用端发送封装后的目标消息详情。
[0116]
示例性的，本技术实施例中的目标消息详情中，包含有综合内容和推送内容，其中，综合内容是一些表示消息名称、类型等信息的内容，推送内容是消息中用于推送给用户查看的内容。例如，综合内容可以是消息id、消息类型、消息生成服务名，而推送内容则为详细的消息内容。
[0117]
本技术实施例中可以根据目标消息详情中的不同字段，识别出是综合内容还是推送内容，在识别出不同的内容后，对目标消息详情的部分内容通过目标数据类型的格式进行封装。具体的，本技术实施例中保留综合内容的数据类型，并通过目标数据类型对推送内容进行封装，根据综合内容和封装后的推送内容得到封装后的目标消息详情，最终通过通用接口向应用端发送封装后的目标消息详情。
[0118]
可以理解的是，在服务端查询详情时，前面过程返回给应用端的目标基本信息中包含的消息id、消息类型、消息生成服务名作为接口入参，服务端根据服务名路由到相应的服务，查询详情后统一封装返回。需要详情查询的服务实现标准接口以支持查询，为了适应字段差异和扩展，目标数据类型为json格式数据类型，json格式是一种数据交换格式，json格式可以方便地读取数据，因此详情用json形式封装。
[0119]
需要说明的，可以通过下述例子说明。
[0120]
示例性的，目标基本信息作为消息事件通知，已经携带了必要的信息，如果应用端代理层需要访问查询消息详情的通用接口时，应用端将消息事件中的消息id、消息类型、消息生成服务名作为接口入参，例如：
[0121]
{msgid:100000001001,msgtype:”userrecognize”，msgsrv:”userservice”}；
[0122]
随后，服务端，如网关过滤器(filter)中获取到此接口请求时，解析到其中的参数消息生成服务名msgsrv，利用伪装(feign)方式调用相应系统实现的接口。
[0123]
最终，网关从业务系统查询到消息详情后统一封装返回。为了适应字段差异和扩展，详情用json形式封装，内容包括消息id、消息类型、消息生成服务名、消息内容(json)。
[0124]
例如，目标消息详情(以身份识别消息详情为例子)如下：
[0125]
{msgid:100000001001,msgtype:”userrecognize”，msgsrv:”userservice”,details:{ifcustomer:”y”,...}}；
[0126]
上述前几个字段是已有信息，业务系统的消息详情序列化为json字符串后，可以封装在返回给应用端的报文的细节(details)字段中，应用端解析details字段可以得到目标消息详情。
[0127]
请参阅图10，在一些实施例中，步骤s104之后，还可以包括步骤s801至步骤s802：
[0128]
步骤s801，应用端接收服务端发送的目标消息详情；
[0129]
步骤s802，根据目标消息详情提取得到推送内容，并推送推送内容。
[0130]
示例性的，应用端在接收到服务端发送的目标消息详情后，可以根据其内容，进行进一步的响应，因此，应用端可以根据目标消息详情提取得到推送内容，并推送上述得到的推送内容。例如，如当目标消息详情为身份识别消息详情，则需要反馈客户为c端在拨库用户，因此应用端在前端页面主动弹窗引导用户参与门槛为在拨库客户的活动，完成消息推送。
[0131]
需要说明的是，通本技术实施例中的消息推送方法，适应各种应用类型，可以适用于h5、小程序、原生app等各种类型的应用，为原生app之外的应用创造提供了新的类似原生app的交互模式；此外，还可以与业务接口调用结合，最小化对服务器的调用频次，兼顾性能和实时性，保证安全性，不增加额外风险；且与网关结合，减少业务耦合及对业务系统的侵入和改造；同时还支持分布式集群部署，支持微服务架构；且使用灵活的json结构保存消息，支持消息类型和结构的扩展；此外，还具备消息可持久化、可恢复的优点；且使用http协议的原生机制，兼容性好，各浏览器版本都能支持。
[0132]
请参阅图1或图2所示，本技术实施例还提供一种消息推送系统，可以实现上述消息推送方法，消息推送系统包括：应用端和服务端，其中：
[0133]
应用端向服务端发出业务接口访问请求；
[0134]
服务端接收访问请求，根据访问请求获取与应用端的身份信息对应的目标基本信息，将目标基本信息封装进业务接口的返回报文中，并将返回报文发送至应用端；
[0135]
应用端接收服务端发送的返回报文，提取返回报文中的目标基本信息，根据目标基本信息向服务端发送消息查询请求；
[0136]
服务端根据消息查询请求查询目标基本信息对应的目标消息详情，向应用端发送目标消息详情。
[0137]
示例性的，应用端与服务端之间可以进行网络连接，应用端可以通过业务接口与服务端保持连接，业务接口可以为服务端中的接口，例如，可以为网关上的业务接口。在一实施例中，应用端向服务端发出业务接口访问请求，进行常规的业务接口查询，本技术实施例通过与业务接口调用结合，避免应用端高频次轮询影响服务端，且保证安全性，实现了将消息推送与正常的业务接口查询相结合，可以避免新增接口调用，是一种代价较小且安全的方式。
[0138]
示例性的，服务端的业务接口在接收到访问请求后，会对访问请求进行相应，生成一个返回报文，在本技术实施例中，服务端接收访问请求后，根据访问请求获取与应用端的身份信息对应的目标基本信息，随后将目标基本信息封装进业务接口的返回报文中，并将返回报文发送至应用端，实现了在不新增新的接口的前提下，通过原先的业务接口实现消息推送。
[0139]
可以理解的是，目标基本信息是消息推送的基本信息，也即消息事件，也可以称为一个通知信息，表明了当前应用端对应的身份信息下有消息需要推送，因此，在服务端接收到访问请求后，可以从中解析得到应用端的身份信息，若有对应身份信息下的消息需要推送，则将这个消息推送的基本信息，也就是目标基本信息封装在返回报文中，一同返回给应
用端，不干扰业务接口的入参、出参。对于业务接口来讲，对这个消息通知机制与其接口的结合，是无感知的。
[0140]
示例性的，应用端在接收到服务端发送的返回报文后，会对返回报文进行解析，从而提取返回报文中的目标基本信息，得知有消息需要推送，由于业务接口返回报文的限制，夹在返回报文里面的目标基本信息并不能完整反应需要推送的内容，也即不能完成反应消息事件的内容，因此应用端可以向服务端发送消息查询请求进行查询。
[0141]
需要说明的是，当应用端为前端，前端可以通过代理层提取返回报文携带的消息事件，针对携带的消息，前端根据消息类型，进行响应，从而生成消息查询请求，并将消息查询请求发送给服务端。需要指出的是，本技术实施例中的应用端可以进行两种形式响应，例如，可以直接调用特定的业务接口进行响应，也可以通过通用接口进一步查询消息详情。
[0142]
示例性的，在服务端接收到应用端发送的消息查询请求后，可以返回具体的内容，因此服务端根据消息查询请求查询目标基本信息对应的目标消息详情，此时需要说明的是，服务端预先存储好多个消息的消息详情，在接收到消息查询请求后，可以从存储的数据中根据应用端的身份信息，查找对应的消息详情，并作为目标消息详情，从而向应用端发送目标消息详情，完成消息推送。
[0143]
需要指出的是，在常见的b/s结构中，除非使用socket等长连接机制，否则无法实现真正的服务端对应用端的主动通知。为近似实现这种效果，一个常规思路是前端进行定时轮询，查询后端接口是否有新消息。但这样有两个问题，一是大量应用端高频次查询，对后端服务器的压力非常大，可能会出现此类轮询比所有其他的业务接口调用量都大，影响业务服务的性能和稳定性。另外，如果应用端在一段时间内没有操作页面访问后端接口，h5等类型应用一般会设计为会话自动过期，如果进行轮询，相当于一直延长客户的会话，过期机制就失效了，对于在公共场合访问h5的这种情况特别不安全。
[0144]
因此，本技术实施例中通过将消息推送与正常的业务接口查询相结合，可以避免新增接口调用，是一种代价较小且安全的方式，预先通过业务接口来返回基本的通知信息，不干扰业务接口的入参、出参，对于业务接口来讲，对这个消息通知机制与其接口的结合，是无感知的，因此可以适用在h5、小程序等非原生app中，能够提供准实时的消息推送，提高了推送效率，提高了用户体验。
[0145]
本技术实施例中能够提供准实时的消息通知，对于h5这类传统上被动依赖用户发起访问的交互模式，新增了应用主动进行的交互模式。如可以支持耗时任务的异步化，优化客户体验，还可以支持运营推送活动消息，提升转化，可以广泛应用在金融、保险等领域中。
[0146]
该消息推送系统的具体实施方式与上述消息推送方法的具体实施例基本相同，在此不再赘述。在满足本技术实施例要求的前提下，消息推送系统还可以设置其他功能模块，以实现上述实施例中的消息推送方法。
[0147]
本技术实施例还提供了一种电子设备，电子设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述消息推送方法或缓存读取方法。该电子设备可以为包括平板电脑、车载电脑等任意智能终端。
[0148]
请参阅图11，图11示意了另一实施例的电子设备1100的硬件结构，参照图12和图13所示，电子设备1100可可以是应用端或服务端中的设备，通过设置在应用端或服务端中，以实现上述实施例中的消息推送方法，电子设备1100包括：
[0149]
处理器1101，可以采用通用的cpu(central processingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificitegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本技术实施例所提供的技术方案；
[0150]
存储器1102，可以采用只读存储器(readonlymemory，rom)、静态存储设备、动态存储设备或者随机存取存储器(randomaccessmemory，ram)等形式实现。存储器1102可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1102中，并由处理器1101来调用执行本技术实施例的消息推送方法；
[0151]
输入/输出接口1103，用于实现信息输入及输出；
[0152]
通信接口1104，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信；
[0153]
总线1105，在设备的各个组件(例如处理器1101、存储器1102、输入/输出接口1103和通信接口1104)之间传输信息；
[0154]
其中处理器1101、存储器1102、输入/输出接口1103和通信接口1104通过总线1105实现彼此之间在设备内部的通信连接。
[0155]
本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述消息推送方法。
[0156]
存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
[0157]
本技术实施例描述的实施例是为了更加清楚的说明本技术实施例的技术方案，并不构成对于本技术实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
[0158]
本领域技术人员可以理解的是，图中示出的技术方案并不构成对本技术实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。
[0159]
以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
[0160]
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
[0161]
本技术的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或
设备固有的其它步骤或单元。
[0162]
应当理解，在本技术中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
[0163]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0164]
上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0165]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0166]
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括多指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例的方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，简称rom)、随机存取存储器(random access memory，简称ram)、磁碟或者光盘等各种可以存储程序的介质。
[0167]
以上参照附图说明了本技术实施例的优选实施例，并非因此局限本技术实施例的权利范围。本领域技术人员不脱离本技术实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本技术实施例的权利范围之内。