CN109639782A - 消息发送平台、方法 - Google Patents

Abstract

本发明提供了一种消息发送方法、平台。该消息发送方法包括：接收消息发送请求；解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包；调用消息转发平台的API，以使消息转发平台基于消息数据包进行对应的消息发送。该消息发送方法从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案。

Description

消息发送平台、方法

技术领域

本发明涉及计算机应用技术领域，尤其涉及一种消息发送平台、方法、计算机设备以及计算机可读存储介质。

背景技术

随着互联网技术的飞速发展，各类移动互联网应用层出不穷，大部分移动互联网应都会配置即时通信服务(Instant Messaging)。

目前，为移动互联网应用提供即时通信服务(如消息推送服务、手机短信服务等)的消息转发平台众多，如极光推送、信鸽推送、小米推送、网易云信等。众多的消息转发平台为移动互联网应用开发者提供了专业稳定的即时通信服务，使得开发者不需要搭建复杂的服务环境或者安装巨型软件，只需调用消息转发平台的客户端SDK(Software DevelopmentKit，软件开发工具包)和开放的API(Application Programming Interface，应用程序编程接口)，即可在短时间内为移动互联网应用获得稳定可靠的即时通信功能，极大地简化了办公过程。

但是，众多的消息转发平台自成体系，企业内部的不同移动互联网应用对使用到的不同消息转发平台的消息服务各自进行集成，对消息服务分别部署后，调用不同消息转发平台提供的API使用对应的消息服务。

因此，对于企业内部的不同移动互联网应用的开发者而言，需要掌握不同消息转发平台服务的集成和API，增加了开发者的工作量和学习成本，且不便于对消息转发平台服务进行统一部署和管理。

发明内容

本发明提供了一种消息发送方法、平台、计算机设备以及计算机可读存储介质，解决开发者需要掌握不同消息转发平台服务的集成和API，增加了开发者的工作量和学习成本，且不便于对消息转发平台服务进行统一部署和管理的问题。

为解决上述技术问题，本发明采用如下技术方案：

第一方面，提供一种消息发送方法，包括：

接收消息发送请求；

解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；其中，配置信息包括：消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户标识以及密钥；

根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包；

调用消息转发平台的API，以使消息转发平台基于消息数据包进行对应的消息发送。

进一步地，在解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息之前，还包括：

将消息发送请求写入消息队列。

进一步地，在解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息之前，还包括：

根据预设格式对消息发送请求进行格式校验。

进一步地，根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包，包括：

根据发送方式与消息转发平台获取对应的API规则；其中，API规则为利用消息转发平台以发送方式进行消息发送时的接收数据标准格式；

根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包。

进一步地，根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包，包括：

基于消息转发平台的服务地址构建请求对象，请求对象包括：头文件和包数据；

将用户标识、密钥写入头文件；

将消息发送目标标识以及待发送消息写入包数据中，生成所述消息数据包。

进一步地，发送方式包括：消息推送服务和手机短信服务。

进一步地，消息发送方法还包括：

采用日志记录工具同步记录日志信息。

第二方面，提供一种消息发送平台，包括：

接入层，接收消息发送请求；

路由层，解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；其中，配置信息包括：消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户标识以及密钥；

消息服务层，根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包，然后调用消息转发平台的API，以使消息转发平台基于消息数据包进行对应的消息发送。

进一步地，消息发送平台还包括：

消息队列层，用于存放消息发送请求。

进一步地，接入层还用于根据预设格式对消息发送请求进行格式校验。

进一步地，消息服务层包括：

API规则确定模块，根据发送方式与消息转发平台获取对应的API规则；其中，API规则为利用消息转发平台以发送方式进行消息发送时的接收数据标准格式；

整理适配模块，根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包。

进一步地，整理适配模块包括：

构建单元，基于消息转发平台的服务地址构建请求对象，请求对象包括：头文件和包数据；

写单元，将用户标识、密钥写入头文件，将消息发送目标标识以及待发送消息写入包数据中，生成消息数据包。

进一步地，发送类别包括：消息推送服务和手机短信服务。

进一步地，消息发送平台还包括：

基础服务层，用于提供日志记录工具以同步记录日志信息。

第三方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述消息发送方法的步骤。

第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一项消息发送方法的步骤。

本发明提供的消息发送方法、平台、计算机设备以及计算机可读存储介质，该消息发送方法，包括：接收消息发送请求；解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包；调用消息转发平台的API，以使消息转发平台基于消息数据包进行对应的消息发送。该消息发送方法应用于企业内部的移动互联网应用消息服务管理，从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费，并且不同移动互联网应用统一使用消息服务，实现解耦，降低了维护的复杂性。

为让本发明的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例消息发送平台的应用架构图；

图2为本发明实施例消息发送平台的结构图一；

图3为本发明实施例消息发送平台的结构图二；

图4为本发明实施例消息发送平台的结构图三；

图5示出了图2至图4中消息服务层24的具体结构；

图6示出了采用图3所示消息发送平台实现消息发送的信令流程图；

图7示出了采用图4所示消息发送平台实现消息发送的信令流程图；

图8为本发明实施例消息发送方法的流程图一；

图9示出了图8中步骤S300的具体步骤；

图10为本发明实施例消息发送方法的流程图二；

图11为本发明实施例消息发送方法的流程图三；

图12为本发明实施例计算机设备的结构图。

具体实施方式

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

随着互联网技术的飞速发展，互联网移动应用(APP)在日常生活中应用广泛，比如各种外卖类APP、购物类APP以及交友类APP等，各种APP经常需要向指定用户发送短信或推送消息，或者群发短信或推送消息。目前，为APP提供消息推送或发送短信服务的消息转发平台众多，比如极光推送、信鸽推送、小米推送、网易云信等第三方平台，但是，众多的消息转发平台自成体系，企业内部的不同移动互联网应用对使用到的不同消息转发平台的消息服务各自进行集成，对消息服务分别部署后，调用不同消息转发平台提供的API使用对应的消息服务，对于企业内部的不同移动互联网应用的开发者而言，需要掌握不同消息转发平台服务的集成和API，增加了开发者的工作量和学习成本，且不便于对消息转发平台服务进行统一部署和管理。

为解决上述技术问题，本发明实施例提供一种消息发送平台，其应用架构如图1所示，该消息发送平台2作为移动互联网应用1与多个消息转发平台3之间的媒介。

当移动互联网应用1需要发送消息时，调用所述消息发送平台2的API，向所述消息发送平台2发出消息发送请求。

该消息发送平台2接收该消息发送请求，并对该消息发送请求进行处理，进而根据该消息发送请求调用所需的消息转发平台3的API进行消息发送服务，进而实现众多的消息转发平台的集成，对于企业内部的不同移动互联网应用的开发者而言，不需要掌握不同消息转发平台服务的集成和API，减少了开发者的工作量和学习成本，且便于对消息转发平台服务进行统一部署和管理。

下面，结合图2至图7对该消息发送平台2的结构作具体说明：

图2为本发明实施例消息发送平台的结构图一。如图2所示，该消息发送平台本包括：接入层21、路由层23以及消息服务层24。

接入层21用于接收消息发送请求。

其中，该消息发送请求来自终端中的APP或其他应用软件。

该接入层21提供该消息发送平台2的API接口，当移动互联网应用需要使用该消息发送平台进行消息发送时，只需调用该API接口，即可接入该消息发送平台21。

在一个可选的实施例中，该接入层21接收到该消息发送请求后，还可以根据预设格式对该消息发送请求进行格式校验。

路由层23用于解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息。

其中，该发送方式可以包括：消息推送服务和手机短信服务两种，但不限于此。

该消息转发平台包括：极光推送、信鸽推送、小米推送、网易云信等第三方云服务平台，但不限于此。

该配置信息包括：消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户标识以及密钥，用户标识是用户在消息转发平台进行注册时，消息转发平台分配给用户的，是还用户的唯一标识码。该消息发送目标标识指目标发送对象的标识，比如当向用户手机发送短信时，该消息发送目标标识可以为用户的手机号；当向用户推送互联网消息时，该消息发送目标标识可以为用户的IP地址或注册ID等。

另外，当向单个用户发送消息时，该消息发送目标标识为一个，当向多个用户群发消息时，该消息发送目标标识为多个。

该待发送消息包括消息发送的具体内容以及标题等信息。

在一个可选的实施例中，当一个企业内部配置了该消息发送平台后，该企业的多个APP均调用该消息发送平台进行消息发送服务，此时，可以将消息转发平台的用户密钥预存在该消息发送平台，使得一个企业的多个APP均通过一个用户密钥进行业务处理和计费即可，进而使得用户的消息发送请求中不需要每次都含有用户密钥。

另外，该路由层23解析得到上述信息后，将解析得到的信息路由至该消息服务层24。

消息服务层24根据从路由层23接收到的发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包，然后调用该消息转发平台对应的API，以使该消息转发平台基于消息数据包进行对应的消息发送。

其中，该消息发送平台中集成了多种消息转发平台的API以及对应的API规则。该API规则是指其对应的消息转发平台对接收数据的字段如何设置以及数据格式要求等，各消息转发平台的供应商均会向公众提供，以便公众利用该消息转发平台时向该消息转发平台发送的数据包能够被该消息转发平台有效识别和处理。

其中，该消息服务层24在得知APP的消息发送请求对应的发送方式是发送短信还是推送消息后，结合对应的消息转发平台，获取该消息转发平台对应该种发送方式下的API规则，以对数据进行整理适配。

通过上述技术方案可以得知，该消息发送平台2通过对不同平台消息服务(消息推送和短信服务)从API和部署上进行整合和优化，为企业内部提供一种简化学习成本、统一管理、统一扩展、高稳定性、高可用的消息服务解决方案，而且便于集中资源进行管理，降低了维护的复杂性，减少了服务器资源浪费。

本发明实施例提供的消息发送平台开发使用Spring3.2.2作为系统集成框架，采用J2EE架构(使用JDK1.6)，应用64位Tomcat6.0作为服务器，后续可提升版本，方便与其它第三方框架和组件的集成。该消息发送平台最终以war包的形式部署到J2EE应用服务器下，是一种无状态(指两个来自于相同发起者的请求在服务器端无上下文关系)系统，支持负载均衡和集群部署，通过水平扩展可达到与第三方供应商提供的消息服务性能指标，最大限度保证消息服务的可用性。

另外，该消息发送平台的服务器部署采用冗余的方式，减少单点故障。

该消息发送平台设计上分为采用消息队列的异步模式和不采用消息队列的同步模式两种，从使用者的角度看，只需简单更换API调用即可，可根据业务需求进行选择集成。

其中，不采用消息队列的同步模式消息发送平台如图3所示，该消息发送平台在包含图2所示消息发送平台的基础上，还包括：基础服务层25。

该基础服务层25用于提供服务端I/O接口以及日志组件和异常组件。

其中，该日志组件作为日志记录工具，同步记录日志信息，即平台运行轨迹，在平台出错或异常的情况下有助于问题的分析和诊断。该日志组件可以采用现有成熟的日志记录工具Log4j1.2.17，每天滚动日志记录文件，以自然日为基本单位对日志进行归档保存，保留一个月内的日志文件以供查阅。

该异常组件用于记录平台的报错信息并对该报错信息进行分类，以供系统维护人员作为异常判断和故障诊断的依据。

图3示出的消息发送平台从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费。但是，当消息发送请求数量较多时，受限于服务器资源，不能实时对消息发送请求进行处理，容易造成拥堵，降低了用户体验。

图4示出了一种采用消息队列的异步模式的消息发送平台，解决当消息发送请求数量较多时不能实时对消息发送请求进行处理进而容易造成拥堵的问题。该消息发送平台在包含图3所示消息发送平台的基础上，还包括：消息队列层22。

该消息队列层22用于存放消息发送请求。

其中，该消息队列层22采用先进先出的原则，对接收到的消息发送请求进行顺序存储，当路由层23处理完上一个消息发送请求后，从消息队列层22中读取本次消息发送请求，先存入消息队列层22的消息发送请求先被路由层23读取，以此实现依序对接收到的消息发送请求进行处理。

该消息队列层可采用Alibaba的RocketMQ，其中，RocketMQ会对进入消息队列层的消息进行持久化，当服务器出现崩溃或者死机的情况时，修复完成后，消息队列层中的消息不会丢失，以此增加该消息发送平台的安全性和稳定性。

通过上述技术方案可知，当消息发送请求数量较多时，消息发送请求先暂存在消息队列层22中，防止拥堵，提高了用户体验。

图5示出了图2至图4中消息服务层24的具体结构。如图5所示，该消息服务层24包括：API规则确定模块24a以及整理适配模块24b。

API规则确定模块24a根据发送方式与消息转发平台获取对应的API规则。

其中，API规则为利用消息转发平台以发送方式进行消息发送时的接收数据标准格式。该API规则是指其对应的消息转发平台对接收数据的字段如何设置以及数据格式要求等，各消息转发平台的供应商均会向公众提供，以便公众利用该消息转发平台时向该消息转发平台发送的数据包能够被该消息转发平台有效识别和处理。

该消息服务层24在得知APP的消息发送请求对应的发送方式是发送短信还是推送消息后，结合对应的消息转发平台，获取该消息转发平台对应该种发送方式下的API规则，作为对数据进行适配处理的依据和准则。

整理适配模块24b根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包。

其中，整理适配模块24b以API规则作为准则，将配置信息和待发送消息整理成该消息转发平台能够识别和处理的数据格式。

具体地，该整理适配模块24b包括构建单元以及写单元。该构建单元基于消息转发平台的服务地址构建请求对象，请求对象包括：头文件和包数据；写单元将用户标识、密钥写入头文件，将消息发送目标标识以及待发送消息写入所述包数据中，生成消息数据包。

图6示出了采用图3所示不采用消息队列的同步模式消息发送平台实现消息发送的信令流程图。以用户B采用购物类APP通过网易云信向用户A推送购物优惠券短信为例，该购物类APP发起消息发送进程，调用该消息发送平台的API，向该消息发送平台发送一消息发送请求，该消息发送请求中包含以下信息：

发送方式：短信发送；

消息转发平台：网易云信；

消息转发平台的服务地址：网易云信服务端的URL地址；

消息发送目标标识：用户A的手机号；

消息转发平台的用户B的标识和密钥：用户标识是用户B在网易云信注册时网易云信分配给用户B以标识用户B的识别码，用户密钥是预购的网易运行的用户密钥；

待发送消息：购物优惠券的金额及其使用时限等。

该消息发送平台的接入层接收该消息发送请求，并根据预设格式对该消息发送请求进行校验，当校验结果显示该消息发送请求格式合格且信息完整时，将该消息发送请求推送至路由层。

路由层接收到该消息发送请求后，对该消息发送请求进行解析，获取对应的发送方式、消息转发平台、待发送消息、消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户密钥，并传输至消息服务层。

消息服务层接收到路由层发送的消息后，根据发送方式与消息转发平台，在预存的消息转发平台的API以及API规则中，搜索网易云信的短信服务对应的API规则，然后利用该API规则对上述消息转发平台的服务地址、消息发送目标标识、消息转发平台的用户密钥以及待发送消息进行整理适配，生成满足该API规则的消息数据包，然后调用网易云信的API，将消息数据包发至网易云信的服务端进行消息服务的后续处理，当网易云信处理完毕后，向消息服务层返回反馈信息，该消息服务层将该反馈信息顺序通过路由层、接入层返回至购物类APP，以此实现一个消息发送请求的处理流程。

其中，用户密钥具体包括：时间戳、通过密钥和时间戳计算得到的校验值以及对应所述校验值的随机数。利用该API规则对上述消息转发平台的服务地址、消息发送目标标识、消息转发平台的用户密钥以及待发送消息进行整理适配，生成满足该API规则的消息数据包，具体包括：

以网易云信短信服务地址(https://api.netease.im/sms/sendcode.action)构建请求对象HttpPost，将AppKey(用户B注册时网易运行分配给用户B的用户标识，用于唯一标识所述用户B)、Nonce(随机数)、CurTime(当前的时间戳)、CheckSum(通过密钥APP_SECRET和CurTime计算后的校验值)设置到HttpPost的头文件Header，将用户A的手机号、待发送消息(短信模板编号、模板内部参数值加入HttpPost的包数据，得到消息数据包，向网易云信服务器提交该消息数据包，网易云信服务器返回本次请求结果。

短信模板编号为云信云信官网中提供的模板的编号，模板内部参数值指待发送的内容和题目等。

图7示出了采用图4所示采用消息队列的异步模式消息发送平台实现消息发送的信令流程图。如图7所示，以用户W采用外卖类APP通过信鸽推送平台向用户群组B中的所有用户推送广告信息为例。该外卖类APP发起消息发送进程，调用该消息发送平台的API，向该消息发送平台发送一消息发送请求，该消息发送请求中包含以下信息：

发送方式：互联网消息推送；

消息转发平台：信鸽推送；

消息转发平台的服务地址：信鸽推送服务端的地址；

消息发送目标标识：用户群组B中所有用户的IP地址或注册ID；

消息转发平台的用户密钥：用户W的标识和预购的信鸽推送的用户W密钥；用户标识是用户W在信鸽推送注册时信鸽推送分配给用户W以标识用户W的识别码，用户W密钥是预购的网易运行的用户密钥；

待发送消息：广告信息。

该消息发送平台的接入层接收该消息发送请求，并根据预设格式对该消息发送请求进行校验，当校验结果显示该消息发送请求格式合格且信息完整时，将该消息发送请求推送至消息队列层。

该消息队列层对该消息发送请求进行存储，并向接收层反馈消息发送请求接收成功的消息，接收层再将该消息反馈至该外卖类APP。

当其他APP或该外卖类APP继续发起消息发送进程时，接收层接收消息发送请求，消息队列层存储消息发送请求，而不必考虑路由层是否处于空闲状态。

路由层在处理完一个消息发送请求后，从消息队列层中读取新的消息发送请求，并对该新的消息发送请求进行解析，获取对应的发送方式、消息转发平台、待发送消息、消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户密钥，并传输至消息服务层。

消息服务层接收到路由层发送的消息后，根据发送方式与消息转发平台，在预存的消息转发平台的API以及API规则中，搜索信鸽推送的消息推送服务对应的API规则，然后利用该API规则对上述消息转发平台的服务地址、消息发送目标标识、消息转发平台的用户密钥以及待发送消息进行整理适配，生成满足该API规则的消息数据包，然后调用信鸽推送的API，将消息数据包发至信鸽推送的服务端进行消息服务的后续处理，当信鸽推送处理完毕后，向消息服务层返回反馈信息，该消息服务层将该反馈信息反馈至路由层，以此实现一个消息发送请求的处理流程，该路由层在本次消息发送请求处理完成后，继续从消息队列层中读取新的消息发送请求，执行后续处理，如此往复。

其中，用户密钥具体包括：时间戳、通过密钥和时间戳计算得到的校验值以及对应所述校验值的随机数。利用该API规则对上述消息转发平台的服务地址、消息发送目标标识、消息转发平台的用户密钥以及待发送消息进行整理适配，生成满足该API规则的消息数据包，具体包括：

以信鸽推送的地址构建请求对象HttpPost，将用户标识、随机数、当前的时间戳、通过用户密钥和当前的时间戳计算后的校验值设置到HttpPost的头文件

Header，将用户群组B中所有用户的IP地址或注册ID、待发送消息加入HttpPost的包数据，得到消息数据包，向信鸽推送服务器提交该消息数据包，信鸽推送服务器返回本次请求结果。

本发明实施例提供的消息发送平台，从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费，并且不同移动互联网应用统一使用消息服务，实现解耦，降低了维护的复杂性。

基于同一发明构思，本申请实施例还提供了一种消息发送方法，用于实现上述实施例所描述的消息发送平台，如下面的实施例所述。由于消息发送方法解决问题的原理与上述平台相似，因此消息发送方法的实施可以参见上述平台的实施，重复之处不再赘述。

图8为本发明实施例消息发送方法的流程图一。如图8所示，该消息发送方法包括：

步骤S100：接收消息发送请求。

其中，该消息发送请求来自终端中的APP或其他应用软件。

步骤S200：解析消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息。

其中，配置信息包括：消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户标识以及密钥。

用户标识是用户在消息转发平台进行注册时，消息转发平台分配给用户的，是还用户的唯一标识码。

发送方式包括：消息推送服务和手机短信服务两种，但不限于此。

该消息转发平台包括：极光推送、信鸽推送、小米推送、网易云信等第三方云服务平台，但不限于此。

该配置信息包括：消息转发平台的服务地址、消息发送目标标识以及消息转发平台的用户密钥。该消息发送目标标识指目标发送对象的标识，比如当向用户手机发送短信时，该消息发送目标标识可以为用户的手机号；当向用户推送互联网消息时，该消息发送目标标识可以为用户的IP地址或注册ID等。

另外，当向单个用户发送消息时，该消息发送目标标识为一个，当向多个用户群发消息时，该消息发送目标标识为多个。

该待发送消息包括消息发送的具体内容以及标题等信息。

在一个可选的实施例中，还可以包括：接收并存储消息转发平台的用户密钥，使得一个企业的多个APP均通过一个用户密钥进行业务处理和计费即可，进而使得用户的消息发送请求中不需要每次都含有用户密钥。

步骤S300：根据发送方式与消息转发平台对配置信息和待发送消息进行整理适配，生成消息数据包。

步骤S400：调用消息转发平台的API，以使消息转发平台基于消息数据包进行对应的消息发送。

在一个可选的实施例中，该消息发送方法还可以包括：接收并存储多种消息转发平台的API以及对应的API规则的步骤。该API规则是指其对应的消息转发平台对接收数据的字段如何设置以及数据格式要求等，各消息转发平台的供应商均会向公众提供，以便公众利用该消息转发平台时向该消息转发平台发送的数据包能够被该消息转发平台有效识别和处理。

本发明实施例提供的消息发送方法，应用于企业内部的移动互联网应用消息服务管理，从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费，并且不同移动互联网应用统一使用消息服务，实现解耦，降低了维护的复杂性。

图9示出了图8中步骤S300的具体步骤。如图9所示，该步骤S300包括：

步骤S301：根据发送方式与消息转发平台获取对应的API规则。

其中，API规则为利用消息转发平台以发送方式进行消息发送时的接收数据标准格式。该API规则是指其对应的消息转发平台对接收数据的字段如何设置以及数据格式要求等，各消息转发平台的供应商均会向公众提供，以便公众利用该消息转发平台时向该消息转发平台发送的数据包能够被该消息转发平台有效识别和处理。

步骤S302：根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包。

其中，以API规则作为准则，将配置信息和待发送消息整理成该消息转发平台能够识别和处理的数据格式。

具体地，根据API规则对配置信息和待发送消息进行整理适配，生成消息数据包，包括：

基于消息转发平台的服务地址构建请求对象，请求对象包括：头文件和包数据；

将用户标识、密钥写入头文件；

将消息发送目标标识以及待发送消息写入包数据中，生成消息数据包。

图10为本发明实施例消息发送方法的流程图二。如图10所示，该消息发送方法在包含图8所示步骤的基础上，还包括：

步骤S500：将消息发送请求写入消息队列。

其中，该消息队列采用先进先出的原则，对接收到的消息发送请求进行顺序存储，处理完上一个消息发送请求后，从消息队列中读取本次消息发送请求，先存入消息队列的消息发送请求先被读取，以此实现依序对接收到的消息发送请求进行处理。

该消息队列可采用Alibaba的RocketMQ，其中，RocketMQ会对进入消息队列的消息进行持久化，当服务器出现崩溃或者死机的情况时，修复完成后，消息队列中的消息不会丢失，以此增加该方法的安全性和稳定性。

通过上述技术方案可知，当消息发送请求数量较多时，消息发送请求先暂存在消息队列中，防止拥堵，提高了用户体验。

图11为本发明实施例消息发送方法的流程图三。如图11所示，该消息发送方法在包含图10所示步骤的基础上，还包括：

步骤S600：根据预设格式对消息发送请求进行格式校验。

在一个可选的实施例中，该消息发送方法还可以包括：采用日志记录工具同步记录日志信息，该日志记录工具同步记录日志信息，即平台运行轨迹，在平台出错或异常的情况下有助于问题的分析和诊断。该日志记录工具可以采用现有成熟的日志记录工具Log4j1.2.17，每天滚动日志记录文件，以自然日为基本单位对日志进行归档保存，保留一个月内的日志文件以供查阅。

在一个可选的实施例中，该消息发送方法还可以包括：接收并记录报错信息；对该报错信息进行分类。通过记录并分类该报错信息，供系统维护人员作为异常判断和故障诊断的依据。

图12为本发明实施例计算机设备的结构图。如图12所示，该计算机设备具体可以包括存储器7m、处理器6m、通信接口8m、数据总线9m及存储在存储器7m上并可在处理器6m上运行的计算机程序，处理器6m执行计算机程序时实现上述任一实施例所描述消息发送方法的步骤。

本发明实施例提供的计算机设备，从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费，并且不同移动互联网应用统一使用消息服务，实现解耦，降低了维护的复杂性。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述消息发送方法的步骤。

本发明实施例提供的计算机可读存储介质，从API和部署上整合和优化不同消息转发平台的即时通信服务(如消息推送服务、手机短信服务等)，为企业内部提供一种降低开发者工作量和学习成本、利用统一管理和统一扩展、稳定性高、可用性高的消息服务解决方案，使得同类功能消息服务不需要重复部署，防止服务器资源浪费，并且不同移动互联网应用统一使用消息服务，实现解耦，降低了维护的复杂性。

值得说明的是，上述各实施例中，该接入层21也可以成为接收模块，路由层23也可以称为路由模块，消息服务层24也可以称为消息服务模块，消息队列层22也可以称为消息队列模块，基础服务层25也可以称为基础服务模块。

本申请实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

所述服务器与所述APP之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(RepresentationalState Transfer，表述性状态转移协议)等。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (16)

1.一种消息发送方法，其特征在于，包括：

接收消息发送请求；

解析所述消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；其中，所述配置信息包括：所述消息转发平台的服务地址、消息发送目标标识以及所述消息转发平台的用户标识以及密钥；

根据所述发送方式与所述消息转发平台对所述配置信息和所述待发送消息进行整理适配，生成消息数据包；

调用所述消息转发平台的API，以使所述消息转发平台基于所述消息数据包进行对应的消息发送。

2.根据权利要求1所述消息发送方法，其特征在于，在所述解析所述消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息之前，还包括：

将所述消息发送请求写入消息队列。

3.根据权利要求1或2所述消息发送方法，其特征在于，在所述解析所述消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息之前，还包括：

根据预设格式对所述消息发送请求进行格式校验。

4.根据权利要求3所述消息发送方法，其特征在于，所述根据所述发送方式与所述消息转发平台对所述配置信息和所述待发送消息进行整理适配，生成消息数据包，包括：

根据所述发送方式与所述消息转发平台获取对应的API规则；其中，所述API规则为利用所述消息转发平台以所述发送方式进行消息发送时的接收数据标准格式；

根据所述API规则对所述配置信息和所述待发送消息进行整理适配，生成所述消息数据包。

5.根据权利要求4所述消息发送方法，其特征在于，所述根据所述API规则对所述配置信息和所述待发送消息进行整理适配，生成所述消息数据包，包括：

基于所述消息转发平台的服务地址构建请求对象，所述请求对象包括：头文件和包数据；

将所述用户标识、密钥写入所述头文件；

将所述消息发送目标标识以及待发送消息写入所述包数据中，生成所述消息数据包。

6.根据权利要求4所述消息发送方法，其特征在于，所述发送方式包括：消息推送服务和手机短信服务。

7.根据权利要求6所述消息发送方法，其特征在于，还包括：

采用日志记录工具同步记录日志信息。

8.一种消息发送平台，其特征在于，包括：

接入层，接收消息发送请求；

路由层，解析所述消息发送请求以获取对应的发送方式、消息转发平台、配置信息以及待发送消息；其中，所述配置信息包括：所述消息转发平台的服务地址、消息发送目标标识以及所述消息转发平台的用户标识以及密钥；

消息服务层，根据所述发送方式与所述消息转发平台对所述配置信息和所述待发送消息进行整理适配，生成消息数据包，然后调用所述消息转发平台的API，以使所述消息转发平台基于所述消息数据包进行对应的消息发送。

9.根据权利要求8所述消息发送平台，其特征在于，还包括：

消息队列层，用于存放所述消息发送请求。

10.根据权利要求8或9所述消息发送平台，其特征在于，所述接入层还用于根据预设格式对所述消息发送请求进行格式校验。

11.根据权利要求10所述消息发送平台，其特征在于，所述消息服务层包括：

API规则确定模块，根据所述发送方式与所述消息转发平台获取对应的API规则；其中，所述API规则为利用所述消息转发平台以所述发送方式进行消息发送时的接收数据标准格式；

整理适配模块，根据所述API规则对所述配置信息和所述待发送消息进行整理适配，生成所述消息数据包。

12.根据权利要求11所述消息发送平台，其特征在于，所述整理适配模块包括：

构建单元，基于所述消息转发平台的服务地址构建请求对象，所述请求对象包括：头文件和包数据；

写单元，将所述用户标识、密钥写入所述头文件，将所述消息发送目标标识以及待发送消息写入所述包数据中，生成所述消息数据包。

13.根据权利要求11所述消息发送平台，其特征在于，所述发送类别包括：消息推送服务和手机短信服务。

14.根据权利要求12所述消息发送平台，其特征在于，还包括：

基础服务层，用于提供日志记录工具以同步记录日志信息。

15.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述消息发送方法的步骤。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7任一项所述消息发送方法的步骤。