智能发送消息方法和装置
技术领域
本发明涉及计算机数据传输领域,尤其涉及一种智能发送消息方法和装置。
背景技术
随着智能终端技术的迅速发展,人们可以方便地通过多种移动设备(例如手机和平板电脑等)和PC端上通过浏览器打开网站页面或者通过客户端打开各类应用。虽然内容服务商可以通过消息机制利用上述多种途径向客户提供种类繁多的内容资源(例如文本资源、图像资源和影音资源等),但是不同的消息接收平台(例如移动端的iOS平台和Android平台)是基于不同的协议接收消息,使得消息接收平台的差异度高。
针对上述不同终端的消息发送问题,目前内容服务商虽然可通过第三方消息服务提供商提供相对统一的消息发送服务接口,然而仅依靠单一的消息服务提供商所提供的消息发送接口容易在网络的高峰期或不稳定时期出现单点故障及性能瓶颈,导致消息延迟甚至丢失。相反,若通过多位消息服务提供商所提供的消息发送接口发送消息,则由于每位消息服务提供商所提供的消息发送接口的协议并不一致,因此将其提供的消息发送接口接入系统难度较大,开发成本和日后的系统维护成本较高。
发明内容
本申请的目的是解决现有技术的不足,提供一种智能发送消息方法和装置,通过统一的消息发送管理及监控,能够获得屏蔽不同消息发送平台差异及底层细节的效果。
为了实现上述目的,本申请采用以下的技术方案。
首先,本申请提出一种智能发送消息方法,包括以下步骤:通过消息网关接收外部系统发送的加密的消息,验证签名并解密信息;根据路由算法选择消息发送的路由,并基于消息发送的路由将解密后的消息转换为基于统一的消息发送协议的消息,其中所述转换后的消息的数据被记录到日志文件中;发送转换后的消息至消息接收平台,并监听消息接收平台的返回结果;记录消息接收平台的返回结果至日志文件中,并更新数据记录的状态。
在本申请的一个方法实施例中,通过消息网关接收外部系统发送的加密消息后,至少监控消息的响应时间和完整性。
优选地,在本申请的上述方法实施例中,当消息响应时间监控检测到消息响应时间大于预设的第一响应时间阈值时,当前外部系统发送消息的接入渠道被标记为故障并将标记为故障的接入渠道记录到日志文件中。
进一步地,在本申请的上述方法实施例中,当外部系统发送消息的接入渠道被标记为故障时,根据日志文件将当前被标记为故障的接入渠道更改到未被标记为故障的接入渠道。
在本申请的一个方法实施例中,当等候消息接收平台返回结果的时间大于预设的第二响应时间阈值时,再次发送转换后的消息至消息接收平台。
优选地,在本申请的上述方法实施例中,当发送转换后的消息次数大于预设的发送阈值时,异常被抛出并将所述异常及对应的消息记录在日志文件中。
进一步地,在本申请的上述方法实施例中,基于记录在日志文件中异常所对应的消息类型,形成异常的可读统计文件并导出到外部。
其次,本申请还提出一种智能发送消息装置,包括以下模块:网关模块,用于通过消息网关接收外部系统发送的加密的消息,验证签名并解密信息;路由模块,用于根据路由算法选择消息发送的路由,并基于消息发送的路由将解密后的消息转换为基于统一的消息发送协议的消息,其中所述转换后的消息的数据被记录到日志文件中;发送模块,用于发送转换后的消息至消息接收平台,并监听消息接收平台的返回结果;记录模块,用于记录消息接收平台的返回结果至日志文件中,并更新数据记录的状态。
在本申请的一个装置实施例中,网关模块通过消息网关接收外部系统发送的加密消息后,至少监控消息的响应时间和完整性。
优选地,在本申请的上述装置实施例中,网关模块在消息响应时间监控检测到消息响应时间大于预设的第一响应时间阈值时,将前外部系统发送消息的接入渠道被标记为故障并将标记为故障的接入渠道记录到日志文件中。
进一步地,在本申请的上述装置实施例中,当外部系统发送消息的接入渠道被标记为故障时,路由模块根据日志文件将当前被标记为故障的接入渠道更改到未被标记为故障的接入渠道。
在本申请的一个装置实施例中,当等候消息接收平台返回结果的时间大于预设的第二响应时间阈值时,发送模块再次发送转换后的消息至消息接收平台。
优选地,在本申请的上述装置实施例中,当发送转换后的消息次数大于预设的发送阈值时,记录模块抛出异常并将所述异常及对应的消息记录在日志文件中。
进一步地,在本申请的上述方法实施例中,记录模块基于记录在日志文件中异常所对应的消息类型,形成异常的可读统计文件并导出到外部。
最后,本发明还公开了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如前述任一项所述方法的步骤。
本申请的有益效果为:通过使用统一的消息发送管理及监控,从而屏蔽不同消息发送平台差异及底层细节,使得系统的开发及运维成本降低。
附图说明
图1所示为本申请方法所基于的框架结构示意图;
图2所示为本申请的智能发送消息方法的方法流程图;
图3所示为基于图2所示方法流程图的用例流程图;
图4所示为本申请的一个实施例的子方法流程图;
图5所示为本申请的另一个实施例的子方法流程图;
图6所示为本申请的智能发送消息装置的模块结构图。
具体实施方式
以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整的描述,以充分地理解本发明的目的、方案和效果。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。附图中各处使用的相同的附图标记指示相同或相似的部分。
参照图1所示为框架结构图及图2所示的方法流程图,在本申请所公开的一个实施例中,智能发送消息方法包括如下步骤:通过消息网关接收外部系统发送的加密的消息,验证签名并解密信息;根据路由算法选择消息发送的路由,并基于消息发送的路由将解密后的消息转换为基于统一的消息发送协议的消息,其中所述转换后的消息的数据(即消息的发送时间、大小和来源等信息)被记录到日志文件中;发送转换后的消息至消息接收平台,并监听消息接收平台的返回结果;记录消息接收平台的返回结果至日志文件中,并更新数据记录的状态。具体地,参照图3所示的用例流程图,图1中的外部系统(例如手机、个人电脑和平板电脑等)通过统一的消息接口调用消息网关将加密后的消息发送至消息中心组件。消息中心将根据相应加密方式(例如本技术领域内常用的RSA加密方式)解密信息和验证签名,然后根据路由算法选择适合的路由并通过统一的消息接口分发消息。同时,消息中心组件对消息的整个发送过程(例如,消息发送的响应时间和各个发送渠道负载)进行监控,以保证消息发送过程的健壮性。由于上述过程都被封装在消息中心组件内,因此不同发送平台的差异和底层技术实现细节对内容服务商透明,从而使得内容服务商可以专注于其核心业务功能的开发。
在本申请的一个实施例中,通过消息网关接收外部系统发送的加密消息后,监控包括但是不限于消息的响应时间和完整性,以实时检测当前网络环境的稳定性,降低网络不稳定所带来的消息延迟及丢失率高的问题。具体的监控实现手段(例如获取消息的响应时间)可以采用本技术领域内的现有技术,本申请对此不予限定。
参照图4所示实施例的子方法流程图,在本申请的一个实施例中,当消息响应时间监控检测到消息响应时间大于预设的第一响应时间阈值时,当前外部系统发送消息的接入渠道被标记为故障并将标记为故障的接入渠道记录到日志文件中。其中,第一响应时间阈值可在初始化时设置(例如,设置为500毫秒)。由于网络高峰期或者网络状态不稳定,导致消息的响应时间大于所示第一响应时间阈值时,相应的接入渠道被标记并记录到日志文件中。相关日志文件可作为运维人员的处理渠道障碍的参考。当运维人员处理完毕后,接入渠道的标记被清除。
进一步地,在上述实施中,当外部系统发送消息的接入渠道被标记为故障时,根据日志文件将当前被标记为故障的接入渠道更改到未被标记为故障的接入渠道,使得消息可以自行通过没有故障发送,提高消息发送过程的健壮性。此外,当故障被运维人员处理后,相应渠道可被恢复以继续用于发送消息。
参照图5所示另一实施例的子方法流程图,在本申请的另一个实施例中,当等候消息接收平台返回结果的时间大于预设的第二响应时间阈值时,相关消息被认为在传输过程中丢失,需要再次发送转换后的消息至消息接收平台。类似地,第二响应时间阈值同样可在初始化时设置(例如,设置为500毫秒)。
进一步地,在上述实施例中,当发送转换后的消息次数大于预设的发送阈值时,异常被抛出并将所述异常及对应的消息记录在日志文件中。此时,消息接收平台被认为是被阻断的。抛出的异常可被用于定位问题的位置。可选地,相关的消息本身被备份到日志文件中,使得当问题被运营人员处理后可继续发送。
再进一步,在上述实施例中,基于记录在日志文件中异常所对应的消息类型,形成异常的可读统计文件并导出到外部。所述可读统计文件可用于运维人员优化消息发送过程的参考。
参照图6所示的模块结构图,在本申请所公开的一个实施例中,智能发送消息装置包括如下模块:网关模块,用于通过消息网关接收外部系统发送的加密的消息,验证签名并解密信息;路由模块,用于根据路由算法选择消息发送的路由,并基于消息发送的路由将解密后的消息转换为基于统一的消息发送协议的消息,其中所述转换后的消息的数据被记录到日志文件中;发送模块,用于发送转换后的消息至消息接收平台,并监听消息接收平台的返回结果;记录模块,用于记录消息接收平台的返回结果至日志文件中,并更新数据记录的状态。具体地,参照图3所示的用例流程图,外部系统(例如手机、个人电脑和平板电脑等)通过统一的消息接口调用消息网关将加密后的消息发送至消息中心组件。消息中心将根据相应加密方式(例如本技术领域内常用的RSA加密方式)解密信息和验证签名,然后根据路由算法选择适合的路由并通过统一的消息接口分发消息。同时,消息中心组件对消息的整个发送过程(例如,消息发送的响应时间和各个发送渠道负载)进行监控,以保证消息发送过程的健壮性。由于上述过程都被封装在消息中心组件内,因此不同发送平台的差异和底层技术实现细节对内容服务商透明,从而使得内容服务商可以专注于其核心业务功能的开发。
在本申请的一个实施例中,网关模块通过消息网关接收外部系统发送的加密消息后,监控包括但是不限于消息的响应时间和完整性,以实时检测当前网络环境的稳定性,降低网络不稳定所带来的消息延迟及丢失率高的问题。网关模块的具体监控实现手段(例如获取消息的响应时间)可以采用本技术领域内的现有技术,本申请对此不予限定。
在本申请的一个实施例中,网关模块在消息响应时间监控检测到消息响应时间大于预设的第一响应时间阈值时,将当前外部系统发送消息的接入渠道被标记为故障并将标记为故障的接入渠道记录到日志文件中。其中,第一响应时间阈值可在初始化时设置(例如,设置为500毫秒)。由于网络高峰期或者网络状态不稳定,导致消息的响应时间大于所示第一响应时间阈值时,相应的接入渠道被标记并记录到日志文件中。相关日志文件可作为运维人员的处理渠道障碍的参考。当运维人员处理完毕后,接入渠道的标记被清除。
进一步地,在上述实施中,当外部系统发送消息的接入渠道被标记为故障时,路由模块根据日志文件将当前被标记为故障的接入渠道更改到未被标记为故障的接入渠道,使得消息可以自行通过没有故障发送,提高消息发送过程的健壮性。此外,当故障被运维人员处理后,相应渠道可被恢复以继续用于发送消息。
在本申请的另一个实施例中,当等候消息接收平台返回结果的时间大于预设的第二响应时间阈值时,相关消息被认为在传输过程中丢失,发送模块需要再次发送转换后的消息至消息接收平台。类似地,第二响应时间阈值同样可在初始化时设置(例如,设置为500毫秒)。
进一步地,在上述实施例中,当发送转换后的消息次数大于预设的发送阈值时,记录模块抛出异常出并将所述异常及对应的消息记录在日志文件中。此时,消息接收平台被认为是被阻断的。抛出的异常可被用于定位问题的位置。可选地,相关的消息本身被备份到日志文件中,使得当问题被运营人员处理后可继续发送。
再进一步,在上述实施例中,记录模块基于记录在日志文件中异常所对应的消息类型,形成异常的可读统计文件并导出到外部。所述可读统计文件可用于运维人员优化消息发送过程的参考。
尽管本发明的描述已经相当详尽且特别对几个所述实施例进行了描述,但其并非旨在局限于任何这些细节或实施例或任何特殊实施例,而是应当将其视作是通过参考所附权利要求考虑到现有技术为这些权利要求提供广义的可能性解释,从而有效地涵盖本发明的预定范围。此外,上文以发明人可预见的实施例对本发明进行描述,其目的是为了提供有用的描述,而那些目前尚未预见的对本发明的非实质性改动仍可代表本发明的等效改动。