CN117294667A - 分布式消息发送平台、消息发送方法、设备及存储介质 - Google Patents

Abstract

本发明涉及互联网技术领域，公开了一种分布式消息发送平台、消息发送方法、设备及存储介质。平台采用前后端分离设计，后端包括资源层、基础服务层、应用层和接口层；通过接口层实现用户与后端之间的人机交互；资源层用于获取对应开发工具中的事件数据；基础服务层用于作为消息中间件；应用层的基础功能模块用于实现租户管理、任务管理和消息管理，业务功能插件则用于监听对应开发工具中的目标事件，并调用相应基础功能模块将目标事件的事件数据封装为通知消息后发送至目标用户。本发明兼容多种开发工具，通过监听开发工具中的相关事件并生成对应通知消息发送给用户，从而提升用户开发工作效率。

Description

分布式消息发送平台、消息发送方法、设备及存储介质

技术领域

本发明涉及互联网技术领域，尤其涉及一种分布式消息发送平台、消息发送方法、设备及存储介质。

背景技术

在软件开发行业中，基于不同业务的开发需求，软件开发公司一般会同时使用多种开发工具辅助开发人员进行业务系统开发，比如多功能项目管理工具Jira、代码与文档管理工具Gitlab、容器化应用部署工具Kubernetes、源代码质量管理工具Sonarqube等，除上述行业通用的开发工具以外，开发人员也可以是在业务系统开发过程中使用自研的开发工具。在业务系统开发过程中，开发人员会在这些开发工具上面创建各自的业务需求，这些创建的业务需求需要开发人员及时跟进。

软件开发公司一般使用即时通讯软件进行沟通，比如飞书、钉钉、企业微信等，然而这些开发工具无法直接通过即时通讯软件提醒开发人员更新相应的业务，从而导致开发人员常常忘记业务更新进度，甚至遗忘创建过对应的业务流程，或者开发的业务有进展但对应的开发人员未能及时知道，从而影响工作效率，导致业务开发进度缓慢。

发明内容

本发明的主要目的在于提供一种分布式消息发送平台、消息发送方法、设备及存储介质，旨在解决如何让开发人员及时获知开发工具上的业务开发进度的技术问题。

本发明第一方面提供了一种分布式消息发送平台，所述分布式消息发送平台采用前端与后端分离设计，所述后端由下至上依次包括资源层、基础服务层、应用层和接口层；

所述前端为所述分布式消息发送平台的Web端，用于通过所述接口层实现用户与所述后端之间的人机交互；

所述资源层包括若干开发工具客户端，用于获取对应开发工具中的事件数据；

所述基础服务层包括消息队列及数据库，用于作为消息中间件；

所述应用层包括多个基础功能模块与若干业务功能插件，所述基础功能模块用于实现租户管理、任务管理和消息管理，所述业务功能插件用于监听对应开发工具中的目标事件，并调用相应基础功能模块将所述目标事件的事件数据封装为通知消息后发送至目标用户。

在本发明第一方面的第一种实现方式中，所述基础功能模块包括：

API服务模块，为所述分布式消息发送平台的通信入口，用于根据用户输入的参数调用对应基础功能模块处理并返回处理结果；

租户管理模块，用于注册或删除租户，并为新注册租户生成一个唯一的API Key，所述API Key用于调用所述API服务模块；

定时任务管理模块，用于对定时任务进行封装管理；

任务管理模块，用于管理调度所有消息任务；

通知模板管理模块，用于管理用户的消息模板，所述消息模板包括即时通讯卡片消息模板、文本消息模板和图文消息模板；

通知管理模块，用于管理通知消息的发送方式；

消息发送模块，用于将所有通知消息发送至对应目标用户；

消息查看模块，用于根据所述前端的查询请求返回相应的历史通知消息。

在本发明第一方面的第二种实现方式中，所述任务管理模块在本地数据库中设有周期任务队列、普通任务队列和实时任务队列；

所述任务管理模块用于将需要周期执行的定时任务写入所述周期任务队列；将普通任务或业务任务写入所述普通任务队列；将准备发送的消息或实时任务写入所述实时任务队列。

在本发明第一方面的第三种实现方式中，所述通知管理模块包括：

消息管理模块，用于将所述实时任务队列中的所有消息或所有实时任务封装成通知消息，并将通知消息提交至所述消息发送模块以发送至对应目标用户。

在本发明第一方面的第四种实现方式中，所述定时任务管理模块包括：

任务管理单元，用于根据预置过滤条件确定待封装任务的任务对象，以及确定待封装任务选择的通知模式；

通知模式单元，用于确定待封装任务的周期、通知时间的门限、通知策略以及选择的通知器，所述通知器包括即时通讯软件、邮件和短信；

通知策略单元，用于确定通知消息的级别及该级别通知消息对应的发送时间间隔、通知采用的颜色。

在本发明第一方面的第五种实现方式中，所述定时任务管理模块具体用于：

加载预先注册的Celery任务处理函数进行初始化；

从所述周期任务队列中读取定时任务并更新到任务列表中；

判断所述周期任务队列中是否存在新建或更新的定时任务，若存在，则将所述新建或更新的定时任务更新到所述任务列表中；

循环读取所述任务列表中下一个待执行的定时任务，并判断当前读取的定时任务是否到达执行时间；

若当前读取的定时任务到达执行时间，则采用异步执行方式将当前读取的定时任务进行拆分后分别封装成单独的普通任务并提交至所述普通任务队列进行调度执行；

若当前读取的定时任务未到达执行时间，则等待预置时长后将当前读取的定时任务重新更新到所述任务列表中。

本发明第二方面还提供一种消息发送方法，应用于上述第一方面及其任一种实现方式所述的分布式消息发送平台，所述消息发送方法包括：

业务功能插件监听对应开发工具中的目标事件；

当监听到目标事件时，所述业务功能插件通过对应开发工具客户端获取所述开发工具中的事件数据；

所述业务功能插件调用第一基础功能模块将所述事件数据封装成相应的消息任务并写入任务队列中；

所述业务功能插件调用第二基础功能模块将所述任务队列中的所有消息任务分别封装成通知消息并提交至第三基础功能模块以发送至对应目标用户。

在本发明第二方面的一种实现方式中，所述第一基础功能模块将所述事件数据封装成相应的消息任务包括：

所述第一基础功能模块加载预先注册的Celery任务处理函数进行初始化；

所述第一基础功能模块从所述任务管理模块的周期任务队列中读取定时任务并更新到任务列表中；

所述第一基础功能模块判断所述周期任务队列中是否存在新建或更新的定时任务，若存在，则将所述新建或更新的定时任务更新到所述任务列表中；

所述第一基础功能模块循环读取所述任务列表中下一个待执行的定时任务，并判断当前读取的定时任务是否到达执行时间；

若当前读取的定时任务到达执行时间，则所述第一基础功能模块采用异步执行方式将当前读取的定时任务进行拆分后分别封装成单独的普通任务并提交至所述普通任务队列进行调度执行；

若当前读取的定时任务未到达执行时间，则所述第一基础功能模块等待预置时长后将当前读取的定时任务重新更新到所述任务列表中。

本发明第三方面提供了一种计算机设备，包括：存储器和至少一个处理器，所述存储器中存储有指令；所述至少一个处理器调用所述存储器中的所述指令，以使得所述计算机设备执行上述第一方面及其任一种实现方式的消息发送方法。

本发明的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面及其任一种实现方式的消息发送方法。

本发明提供的技术方案中，为将开发软件上的业务开发进度及时通知开发人员，因此提供一种分布式消息发送平台，该平台采用前端与后端分离设计，后端由下至上依次包括资源层、基础服务层、应用层和接口层。前端为分布式消息发送平台的Web端，通过后端的接口层可实现用户与后端之间的人机交互，比如注册、消息模板设置、消息发送方式设置等。资源层包括若干开发工具客户端，通过该客户端可获取对应开发工具中的事件数据，该事件数据可用于反映业务开发进度。为实现高并发的消息发送，在后端基础服务层设有消息队列及数据库，用于作为消息中间件。为将开发工具中的事件数据转换成通知消息，因此进一步在后端应用层设置有多个基础功能模块与若干业务功能插件，基础功能模块用于实现租户管理、任务管理和消息管理等通用基础功能，而业务功能插件则用于监听对应开发工具中的目标事件，并调用相应基础功能模块将目标事件的事件数据封装为通知消息后发送至目标用户。本发明兼容多种开发工具，可自动监听各开发工具中的相关事件以及生成对应通知消息，同时还兼容多种消息发送方式，比如即时通讯软件、邮件、短信等，提升了通知消息发送的及时性，进而提升用户开发工作效率。

附图说明

图1为本发明实施例中分布式消息发送平台一实施例的技术架构示意图；

图2为本发明实施例中不同任务队列的任务流转示意图；

图3为本发明实施例中消息发送方法一实施例的流程示意图；

图4为本发明实施例中定时任务的封装流程示意图；

图5为本发明实施例中计算机设备的一个实施例示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

另外，为了更好地说明本发明，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本发明同样能够实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本发明的主旨。

在软件开发行业中，基于不同业务的开发需求，软件开发公司一般会同时使用多种开发工具辅助开发人员进行业务系统开发，比如事务跟踪工具Jira、代码与文档管理工具Gitlab、容器化应用部署工具Kubernetes、源代码质量管理工具Sonarqube等，除上述行业通用的开发工具以外，开发人员也可以是在业务系统开发过程中使用自研的开发工具。在业务系统开发过程中，开发人员会在这些开发工具上面创建各自的业务需求，这些创建的业务需求需要开发人员及时跟进。软件开发公司一般使用即时通讯软件进行沟通，比如飞书、钉钉、企业微信等，然而这些开发工具无法直接通过即时通讯软件提醒开发人员更新相应的业务，从而导致开发人员常常忘记业务更新进度，甚至遗忘创建过对应的业务流程，或者开发的业务有进展但对应的开发人员未能及时知道，从而影响工作效率，导致业务开发进度缓慢。为解决上述技术问题，本发明实施例提供一种分布式消息发送平台，通过该平台可以自动监听开发工具上与开发人员创建的开发需求相关的各类事件，同时还可进一步将事件相关的数据封装为通知消息然后再发送给对应的开发人员，从而保证开发人员在收到通知消息后能够及时跟进开发进度，提升开发效率。

为便于理解，下面对本发明实施例的具体实现方式进行描述，请参阅图1，图1为本发明实施例中分布式消息发送平台一实施例的技术架构示意图。

本实施例中，分布式消息发送平台(以下简称平台)由前端和后端构成，前端与后端采用分离设计，前端为平台Web端，通过Vue+Nodejs开发完成，后端则是采用Fastapi+Celery分布式架构设计，采用Rabbitmq+Redis+MySQL作为中间件进行解耦和。后端采用RESTful API接口设计与前端对接。

本发明实施例的分布式消息发送平台是基于Celery实现的。Celery是一种简单灵活且可靠的分布式系统，可以处理大量消息，同时为操作提供维护该系统所需的工具。Celery是一个任务队列，着重于实时处理，同时还支持任务调度。Celery任务队列一般用于线程或计算机之间分配工作的一种机制。任务队列的输入是一个称为任务的工作单元，有专门的工作进行不断的监视任务队列，进行执行新的任务工作。Celery需要消息中间件来进行发送和接收消息。Celery可以在一台机器上运行，也可以在多台机器上运行，甚至可以跨数据中心运行。Celery通过消息机制进行通信，通常使用中间人(Broker)作为客户端和工人(Worker)执行。启动一个任务，客户端向消息队列发送一条消息，然后中间人(Broker)将消息传递给一个工人(Worker)，最后由工人(Worker)进行执行中间人(Broker)分配的任务。一个Celery系统可以由多个工人(Worker)和多个中间人(Broker)组成，用来提高Celery的高可用性以及横向扩展能力。

在一实施例中，优选将平台部署在Kubernetes上，通过kafka处理日志，由通道logstash消费并存储到分布式搜索引擎Elasticsearch上，支持记录所有发出的消息、接收的事件等以实现审计功能。

本实施例中，后端运行环境可以是Linux系统或者Ubuntu系统。后端由下至上依次包括资源层、基础服务层、应用层和接口层。

(1)资源层

资源层包括若干个开发工具客户端，比如Jira客户端、Gitlab客户端、Kubernetes客户端、Sonarqube客户端等，各开发工具客户端可与对应开发工具建立通信连接，进而可获取对应开发工具中的事件数据。例如，通过Jira客户端可获取Jira资源和事件数据，通过Gitlab客户端可获取Gitlab资源和事件数据，通过Kubernetes客户端可获取部署的容器事件数据。此外，资源层还可以包括其他自研开发工具的客户端，进而可获取自研开发工具中的相关事件数据，若自研开发工具需要增加通知功能，也可以使用本发明实施例的平台实现研发过程中相关事件的消息通知。

(2)基础服务层

基础服务层包括消息队列及数据库，用于作为消息中间件进行解耦和。例如，使用Rabbitmq消息队列+Redis数据库+MySQL数据库作为消息中间件。

(3)应用层

应用层包括多个基础功能模块与若干业务功能插件，基础功能模块用于实现租户管理、任务管理和消息管理。

在一实施例中，基础功能模块包括：

API服务模块，为分布式消息发送平台的通信入口，用于根据用户输入的参数调用对应基础功能模块处理并返回处理结果；例如，用户设置各种任务参数、发起查询请求等。

租户管理模块，用于注册或删除租户，并为新注册租户生成一个唯一的API Key，API Key用于调用API服务模块，比如调用API服务模块创建定时任务、注册通知模板、发送消息等等。

定时任务管理模块，用于对定时任务进行封装管理，定时任务指需要周期执行的任务，定时任务封装过程中会设定任务的各种参数，比如任务的通知模式、通知策略、使用的通知器等。

任务管理模块，用于管理调度所有消息任务。

通知模板管理模块，用于管理用户的消息模板，消息模板包括即时通讯卡片消息模板、文本消息模板和图文消息模板，支持自定义消息模板，同时还支持上传消息模板、下载消息模板。

通知管理模块，用于管理通知消息的发送方式。比如管理飞书、邮件、短信等发送消息的方式，支持用户注册自定义即时通讯应用机器人，可以使用自定义即时通讯应用器人发送消息。

消息发送模块，用于将所有通知消息发送至对应目标用户，例如使用飞书将通知消息发送给飞书个人用户或飞书用户组、飞书群组等。

消息查看模块，用于根据前端的查询请求返回相应的历史通知消息。平台所有发送出去的消息都会记录到分布式搜索引擎中，用户可以通过前端的历史消息列表进行查看，同时分布式搜索引擎还可以记录所有收到的开发工具客户端发送过来的事件数据，也即实现从进入本平台到出本平台，整个消息的生命周期形成数据闭环。

在一实施例中，任务管理模块在本地数据库中设有周期任务队列、普通任务队列和实时任务队列；

任务管理模块用于将需要周期执行的定时任务写入周期任务队列；将普通任务或业务任务写入普通任务队列；将准备发送的消息或实时任务写入实时任务队列。

如图2所示，图2为本发明实施例中不同任务队列的任务流转示意图。周期任务队列(periodic-queue)、普通任务队列(common-queue)和实时任务队列(notifier-queue)都是基于Celery实现，并且采用Rabbitmq+Redis+MySQL作为消息中间件(Broker)，运行任务管理模块的进程则作为Worker消费Broker提供过来的任务。周期任务、普通任务、实时任务既可以分别独立运行，也可以同时并行运行。也即三种队列可以是按以下任意一种顺序执行：1)周期任务->拆成普通任务->封装成实时任务->发送；2)普通任务->封装成实时任务->发送；3)实时任务->发送。

其中，周期任务队列中存储需要周期执行的定时任务，周期任务队列中的定时任务需要拆分成单独的普通任务后写入普通任务队列。普通任务指包含事件、通知器、通知对象等信息的集合，普通任务不需要拆分处理，需要封装成消息体后作为实时任务写入实时任务队列。实时任务指可以直接发送的任务，实时任务包含通知器、通知对象、消息体、消息模板等。实时任务队列中的所有消息或实时任务最后通过消息发送模块发送给对应目标用户。

在一实施例中，通知管理模块包括：

消息管理模块，用于将实时任务队列中的所有消息或所有实时任务封装成通知消息，并将通知消息提交至消息发送模块以发送至对应目标用户。

消息管理模块根据用户设置的消息发送参数，选择相应消息模板、消息通知方式对实时任务队列中的消息或实时任务进行封装以形成可以发送的通知消息，然后提交至消息发送模块发送至对应目标用户。

在一实施例中，定时任务管理模块包括：

任务管理单元，用于根据预置过滤条件确定待封装任务的任务对象，以及确定待封装任务选择的通知模式；

定时任务的任务对象包括project、issue等类型，任务对象的过滤条件可以由用户设置，也可以用户选择的任务决定。通知模式包括通知策略和通知器类型，用于设置消息发送方式。

通知模式单元，用于确定待封装任务的周期、通知时间的门限、通知策略以及选择的通知器，通知器包括即时通讯软件、邮件和短信；

通知策略单元，用于确定通知消息的级别及该级别通知消息对应的发送时间间隔、通知采用的颜色。

在一实施例中，业务功能插件用于监听对应开发工具中的目标事件，并调用相应基础功能模块将目标事件的事件数据封装为通知消息后发送至目标用户。比如Jira插件、Gitlab插件、Keel插件、Sonarqube插件等。

平台支持自定义插件开发，并提供开发插件的脚手架，自动生成插件目录，辅助开发人员完成插件开发，开发人员只需实现相应接口即可，具体使用create_plugins.py脚手架生成对应插件的接口模板，该插件目录由API目录、Tables目录、Tests目录三部分构成，对应的目录说明如下：

API目录：该目录下主要定义插件需要暴露的API接口，比如处理webhook事件的接口；

Tables目录：该目录下定义该插件使用的数据库表以及相应的模板；

Tasks目录：该目录下定义注册的celery任务、周期任务和相应的处理逻辑过程等；

Tests目录：该目录主要定义插件的测试用例。

(4)接口层

接口层采用RESTful API接口设计与前端对接，前端通过接口层，实现用户与后端之间的人机交互。例如，用户注册或者设置消息发送相关参数，比如，用户自定义用户组，可以同时发送到企业内某个人、用户组或飞书群组；用户还可以自定义消息模板，比如即时通讯卡片消息模板、文本消息模板和图文消息模板等；用户还可以自定义飞书应用机器人，使用指定机器人发送指定消息；用户还可以自定义通知策略、调度模式、创建定时任务发送消息、周报等，调度模式中包含通知方式、门限(指达到这个门限条件再去匹配通知策略)、周期(指固定多少秒调度一次，或到达什么时间点调度)、通知策略等，比如：使用飞书通知未更新超过2天的issue事件，每2小时按照默认策略调度一次。

本发明实施例的分布式消息发送平台兼容多种开发工具，可自动监听各开发工具中的相关事件以及生成对应通知消息，同时还兼容多种消息发送方式，比如即时通讯软件、邮件、短信等，提升了通知消息发送的及时性，进而提升用户开发工作效率。

请参阅图3，图3为本发明实施例中消息发送方法一实施例的流程示意图。本实施例的消息发送方法应用于上述实施例的分布式消息发送平台，消息发送方法包括：

步骤S10，业务功能插件监听对应开发工具中的目标事件；

业务功能插件通过自身暴露的API接口，通过webhook监听开发工具中的目标事件，比如Gira中的issue创建、更新、删除或者评论等操作触发的对应事件；Gitlab中的向仓库提交代码、创建merge request、执行pipeline和job、代码review、添加评论等操作触发的对应事件；由Kubernetes的keel组件获取到的应用部署信息，然后将应用部署信息以事件方式推送到本平台并被业务功能插件监听到。

步骤S20，当监听到目标事件时，业务功能插件通过对应开发工具客户端获取开发工具中的事件数据；

平台支持的开发工具客户端很多，比如Jira客户端、Gitlab客户端、Kubernetes客户端、Sonarqube客户端等，各开发工具客户端可与对应开发工具建立通信连接，进而可获取对应开发工具中的事件数据。例如，通过Jira客户端可获取Jira资源和事件数据，通过Gitlab客户端可获取Gitlab资源和事件数据，通过Kubernetes客户端可获取部署的容器事件数据。

步骤S30，业务功能插件调用第一基础功能模块将事件数据封装成相应的消息任务并写入任务队列中；

业务功能插件通过开发工具客户端获取开发工具中的事件数据后，需要进一步调用第一基础功能模块将事件数据封装成相应的消息任务，然后再将封装好的消息任务写入任务队列中。

消息任务的类型包括定时任务、普通任务、实时任务，不同任务存入各自对应的任务队列。周期任务队列中存储需要周期执行的定时任务，周期任务队列中的定时任务需要拆分成单独的普通任务后写入普通任务队列。普通任务不需要拆分处理，需要封装成消息体后作为实时任务写入实时任务队列。

下面以第一基础功能模块为定时任务管理模块对定时任务进行封装进行举例说明，如图4所示的定时任务的封装流程示意图。

在一实施例中，定时任务管理模块对定时任务进行封装的实现方式如下：

步骤S301：加载预先注册的Celery任务处理函数进行初始化；

加载预先注册的Celery任务处理函数，可以保证在不同机器上都能找到对应任务的执行入口。

步骤S302：从周期任务队列中读取定时任务并更新到任务列表中；

步骤S303：判断周期任务队列中是否存在新建或更新的定时任务；

步骤S304：若存在新建或更新的定时任务，则将新建或更新的定时任务更新到任务列表中；

步骤S305：循环读取任务列表中下一个待执行的定时任务；

步骤S306：判断当前读取的定时任务是否到达执行时间；

步骤S307：若当前读取的定时任务到达执行时间，则采用异步执行方式将当前读取的定时任务进行拆分后分别封装成单独的普通任务并提交至普通任务队列进行调度执行；

步骤S308：若当前读取的定时任务未到达执行时间，则等待预置时长后将当前读取的定时任务重新更新到任务列表中。预置时长可以由用户设置，也可以默认设置，比如每隔60s将当前未到达执行时间的定时任务重新更新到任务列表中等待下一次读取。

步骤S40，业务功能插件调用第二基础功能模块将任务队列中的所有消息任务分别封装成通知消息并提交至第三基础功能模块以发送至对应目标用户。

普通任务中包含事件数据、通知器、通知对象等信息。普通任务写入实时任务队列后还需要进一步封装为通知消息，然后再通过消息发送模块发送给对应目标用户。通知消息包含事件数据、通知器、通知对象、消息模板、消息通知方式等信息。

在一实施例中，第二基础功能模块优选为通知管理模块，第三基础功能模块优选为消息发送模块。业务功能插件调用通知管理模块将实时任务队列中的所有消息任务分别封装成通知消息，然后再将各通知消息提交至消息发送模块，由消息发送模块调用通知器的消息发送接口，按照用户设置的消息发送方式将各通知消息发送至对应目标用户。

本发明实施例中，为将开发软件上的业务开发进度及时通知开发人员，因此提供一种分布式消息发送平台，该平台采用前端与后端分离设计，后端由下至上依次包括资源层、基础服务层、应用层和接口层。前端为分布式消息发送平台的Web端，通过后端的接口层可实现用户与后端之间的人机交互，比如注册、消息模板设置、消息发送方式设置等。资源层包括若干开发工具客户端，通过该客户端可获取对应开发工具中的事件数据，该事件数据可用于反映业务开发进度。为实现高并发的消息发送，在后端基础服务层设有消息队列及数据库，用于作为消息中间件。为将开发工具中的事件数据转换成通知消息，因此进一步在后端应用层设置有多个基础功能模块与若干业务功能插件，基础功能模块用于实现租户管理、任务管理和消息管理等通用基础功能，而业务功能插件则用于监听对应开发工具中的目标事件，并调用相应基础功能模块将目标事件的事件数据封装为通知消息后发送至目标用户。

本发明实施例的分布式消息发送平台兼容多种开发工具，可自动监听各开发工具中的相关事件以及生成对应通知消息，同时还兼容多种消息发送方式，比如即时通讯软件、邮件、短信等，提升了通知消息发送的及时性，进而提升用户开发工作效率。

图5是本发明实施例提供的一种计算机设备的结构示意图，该计算机设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(centralprocessing units，CPU)510(例如，一个或一个以上处理器)和存储器520，一个或一个以上存储应用程序533或数据532的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器520和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备500中的一系列指令操作。更进一步地，处理器510可以设置为与存储介质530通信，在计算机设备500上执行存储介质530中的一系列指令操作。

计算机设备500还可以包括一个或一个以上电源540，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口560，和/或，一个或一个以上操作系统531，例如Windows Serve，Mac OS X，Unix，Linux，FreeBSD等等。本领域技术人员可以理解，图5示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明还提供一种计算机设备，计算机设备包括存储器和处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时，使得处理器执行上述实施例中的消息发送方法的步骤。

本发明还提供一种计算机可读存储介质，该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在计算机上运行时，使得计算机执行上述实施例中的消息发送方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种分布式消息发送平台，其特征在于，所述分布式消息发送平台采用前端与后端分离设计，所述后端由下至上依次包括资源层、基础服务层、应用层和接口层；

所述前端为所述分布式消息发送平台的Web端，用于通过所述接口层实现用户与所述后端之间的人机交互；

所述资源层包括若干开发工具客户端，用于获取对应开发工具中的事件数据；

所述基础服务层包括消息队列及数据库，用于作为消息中间件；

所述应用层包括多个基础功能模块与若干业务功能插件，所述基础功能模块用于实现租户管理、任务管理和消息管理，所述业务功能插件用于监听对应开发工具中的目标事件，并调用相应基础功能模块将所述目标事件的事件数据封装为通知消息后发送至目标用户。

2.根据权利要求1所述的分布式消息发送平台，其特征在于，所述基础功能模块包括：

API服务模块，为所述分布式消息发送平台的通信入口，用于根据用户输入的参数调用对应基础功能模块处理并返回处理结果；

租户管理模块，用于注册或删除租户，并为新注册租户生成一个唯一的API Key，所述API Key用于调用所述API服务模块；

定时任务管理模块，用于对定时任务进行封装管理；

任务管理模块，用于管理调度所有消息任务；

通知模板管理模块，用于管理用户的消息模板，所述消息模板包括即时通讯卡片消息模板、文本消息模板和图文消息模板；

通知管理模块，用于管理通知消息的发送方式；

消息发送模块，用于将所有通知消息发送至对应目标用户；

消息查看模块，用于根据所述前端的查询请求返回相应的历史通知消息。

3.根据权利要求2所述的分布式消息发送平台，其特征在于，所述任务管理模块在本地数据库中设有周期任务队列、普通任务队列和实时任务队列；

所述任务管理模块用于将需要周期执行的定时任务写入所述周期任务队列；将普通任务或业务任务写入所述普通任务队列；将准备发送的消息或实时任务写入所述实时任务队列。

4.根据权利要求3所述的分布式消息发送平台，其特征在于，所述通知管理模块包括：

消息管理模块，用于将所述实时任务队列中的所有消息或所有实时任务封装成通知消息，并将通知消息提交至所述消息发送模块以发送至对应目标用户。

5.根据权利要求2所述的分布式消息发送平台，其特征在于，所述定时任务管理模块包括：

任务管理单元，用于根据预置过滤条件确定待封装任务的任务对象，以及确定待封装任务选择的通知模式；

通知模式单元，用于确定待封装任务的周期、通知时间的门限、通知策略以及选择的通知器，所述通知器包括即时通讯软件、邮件和短信；

通知策略单元，用于确定通知消息的级别及该级别通知消息对应的发送时间间隔、通知采用的颜色。

6.根据权利要求5所述的分布式消息发送平台，其特征在于，所述定时任务管理模块具体用于：

加载预先注册的Celery任务处理函数进行初始化；

从所述周期任务队列中读取定时任务并更新到任务列表中；

判断所述周期任务队列中是否存在新建或更新的定时任务，若存在，则将所述新建或更新的定时任务更新到所述任务列表中；

循环读取所述任务列表中下一个待执行的定时任务，并判断当前读取的定时任务是否到达执行时间；

若当前读取的定时任务到达执行时间，则采用异步执行方式将当前读取的定时任务进行拆分后分别封装成单独的普通任务并提交至所述普通任务队列进行调度执行；

若当前读取的定时任务未到达执行时间，则等待预置时长后将当前读取的定时任务重新更新到所述任务列表中。

7.一种消息发送方法，应用于权利要求1-6中任一项所述的分布式消息发送平台，其特征在于，所述消息发送方法包括：

业务功能插件监听对应开发工具中的目标事件；

当监听到目标事件时，所述业务功能插件通过对应开发工具客户端获取所述开发工具中的事件数据；

所述业务功能插件调用第一基础功能模块将所述事件数据封装成相应的消息任务并写入任务队列中；

所述业务功能插件调用第二基础功能模块将所述任务队列中的所有消息任务分别封装成通知消息并提交至第三基础功能模块以发送至对应目标用户。

8.根据权利要求7所述的消息发送方法，其特征在于，所述第一基础功能模块将所述事件数据封装成相应的消息任务包括：

所述第一基础功能模块加载预先注册的Celery任务处理函数进行初始化；

所述第一基础功能模块从所述任务管理模块的周期任务队列中读取定时任务并更新到任务列表中；

所述第一基础功能模块判断所述周期任务队列中是否存在新建或更新的定时任务，若存在，则将所述新建或更新的定时任务更新到所述任务列表中；

所述第一基础功能模块循环读取所述任务列表中下一待执行的定时任务，并判断当前读取的定时任务是否到达执行时间；

若当前读取的定时任务到达执行时间，则所述第一基础功能模块采用异步执行方式将当前读取的定时任务进行拆分后分别封装成单独的普通任务并提交至所述普通任务队列进行调度执行；

若当前读取的定时任务未到达执行时间，则所述第一基础功能模块等待预置时长后将当前读取的定时任务重新更新到所述任务列表中。

9.一种计算机设备，其特征在于，所述计算机设备包括：存储器和至少一个处理器，所述存储器中存储有指令；

所述至少一个处理器调用所述存储器中的所述指令，以使得所述计算机设备执行如权利要求7或8所述的消息发送方法。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现如权利要求7或8所述的消息发送方法。