CN114726817A - 一种基于团队模式的业务通知方法及装置 - Google Patents

Abstract

本申请实施例公开了一种基于团队模式的业务通知方法及装置，应用于服务器，其中方法包括：接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息；根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道；根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则通过所述与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息。本申请实施例能够实现基于团队模式下的业务通知的目的，且能够节约带宽资源。

Description

一种基于团队模式的业务通知方法及装置

技术领域

本申请涉及互联网技术，应用于通信等领域，尤其涉及一种基于团队模式的业务通知方法及装置。

背景技术

随着公司的业务发展，越来越多的实训教学软件采用了团队模式来考核学生之间的合作精神以及业务理解，目前现有技术为了解决实现团队模式下的广播通知问题，通常采用的方案有两种。

方案一：采用轮询的方式，由浏览器客户端定时向服务器发送请求，服务器接收到请求后则立即查找消息返回给浏览器客户端。这种传统模式的缺点是浏览器需要不断的向服务器发送请求，然而HTTP请求包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这种方式会浪费带宽等很多资源。

方案二：采用WebSocket的技术建立双向连接通道，一旦服务器接收到消息，则立即通过建立的双向连接通道将消息推送给浏览器客户端。但Websocket技术要求全双工连接，而建立双向连接通道会导致服务器资源的浪费。

发明内容

本申请实施例提供了一种基于团队模式的业务通知方法及装置，能够实现基于团队模式下的业务通知的目的，且能够节约带宽资源。

第一方面，本申请实施例提供了一种基于团队模式的业务通知方法，应用于服务器，所述服务器属于业务系统，所述业务系统包括所述服务器和多个浏览器客户端，所述多个浏览器客户端用于多个开发人员协作进行项目开发，所述方法包括：

接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息，其中，所述请求消息包括团队的第一ID和所述每个浏览器客户端的第二ID，所述团队包括所述多个浏览器客户端；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道，其中，所述单向连接通道用于在所述第一ID的所述团队内发送订阅消息；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；

若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息，其中，所述第一浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在现有技术中，为了解决实现团队模式下的广播通知，通常采用建立双向连接通道的方式，一旦服务器接收到消息，立即通过建立的双向连接通道推送给浏览器客户端，或者是轮询的方式，由浏览器客户端定时发送请求给服务器，服务器接收到请求则立即查找消息，返回给浏览器客户端，而本申请根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的单向连接通道的方式，并根据团队的第一ID（如团体“工程项目三组”）和每个浏览器客户端的第二ID（如浏览器客户端1的ID为“秦总监”、浏览器客户端2的ID为“周工”、浏览器客户端3的ID为“李工”）建立针对多个浏览器客户端的监听队列，若通过监听队列接收到第一浏览器客户端发送的订阅请求（如秦总监完成了相应的业务，需要将项目开发信息广播通知项目组其他成员，则可以向服务器发送订阅请求，该订阅请求是为使得服务器向每个浏览器客户端发送订阅消息的请求消息），则通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息（服务器不会将项目开发消息直接发送给特定的浏览器客户端，而是需要先通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，该订阅消息用于多个浏览器客户端确认是否需要接受该项目开发消息），本申请通过建立的监听队列接收到第一浏览器客户端发送的订阅请求后，通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，能够实现基于团队模式下的业务通知的目的，且相较于现有技术而言，能够节约带宽资源。

在一种可能的实施方式中，所述接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息之前，还包括：

通过Python的Flask搭建轻量级别的通信接口，其中，所述通信接口还用于通过所述监听队列接收所述第一浏览器客户端发送的订阅请求。

在上述方法中，搭建轻量级别的服务器的方式可以是利用编程语言Python 的Flask编写的轻量级 Web 应用框架，但本申请并不限于上述方式为搭建服务器的唯一方式。在服务器搭建好后，在搭建好的服务器内暴露一个接口，该接口用于接收多个浏览器客户端中每个浏览器客户端发送的请求消息、与浏览器客户端建立单向连接通道、建立监听队列以及通过监听队列接收第一浏览器客户端发送的订阅请求，本申请主要是通过浏览器客户端调用服务器暴露的接口来接收/发送相关的数据信息。本申请利用编程语言Python的Flask编写的轻量级 Web 应用框架能够使得服务器搭建的精度更高、速度更快。

在另一种可能的实施方式中，所述订阅请求包括所述第一浏览器客户端提供的项目开发信息；所述通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息之后，还包括：

检测所述多个浏览器客户端是否返回针对所述订阅消息的确认消息；

若检测到第二浏览器客户端发送的所述确认消息，则向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息，所述第二浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在上述方法中，服务器可以根据每个浏览器客户端发送的个人第二ID以及所在的团队的第一ID（如ID为“秦总监”的浏览器客户端1所在的团队为“工程项目三组”、ID为“周工”的浏览器客户端2所在的团队为“工程项目三组”、ID为“李工”的浏览器客户端3所在的团队为“工程项目三组”、...、ID为“王工”的浏览器客户端n所在的团队为“工程项目三组”，其中，n为大于3的正整数），将团队的第一ID相同的浏览器客户端划分为同一个团体区域（如将同属于“工程项目三组的浏览器客户端”划分为同一个团体区域），在确定多个浏览器客户端的团队区域（如团队ID为“工程项目三组”）后，再根据团队的第一ID（“工程项目三组”团队）分别与浏览器客户端1（如ID为“秦总监”）、浏览器客户端2（如ID为“周工”）、浏览器客户端3（如ID为“李工”）、...、浏览器客户端n（如ID为“王工”）建立针对每个浏览器客户端的监听队列，每个团队主题相当于一个消息队列，订阅者（如订阅消息的浏览器客户端2、浏览器客户端3、...、浏览器客户端n）在接收消息之前需要先订阅一系列相关的主题（每个团队主题都生成并维护一个订阅者列表），该监听队列用于接收第一浏览器客户端发送的订阅请求。若存在针对多个浏览器客户端的监听队列，则服务器可以直接监听第一浏览器客户端是否向服务器发送订阅请求。本方案通过建立监听队列，能够使得及时接收第一浏览器客户端发送的订阅请求，实现基于团队模式下广播通知消息的目的。

在又一种可能的实施方式中，还包括：

若未检测到所述第二浏览器客户端发送的所述确认消息，则与所述第二浏览器客户端建立仿双向连接通道；

通过所述仿双向连接通道接收所述第二浏览器客户端发送的针对所述订阅消息的提醒消息，其中，所述提醒消息用于提醒所述第二浏览器客户端未接收到所述订阅消息；

通过所述仿双向连接通道向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息。

在上述方法中，若未检测到第二浏览器客户端发送的确认信息，则表明该第二浏览器客户端可能未接收到服务器发送的订阅消息，此时为确认第二浏览器客户端是否接收到服务器发送的订阅消息，可以单独建立服务器与第二浏览器客户端之间的仿双向连接通道，服务器通过仿双向连接通道接收第二浏览器客户端发送的针对订阅消息的提醒信息，该提醒消息表明第二浏览器客户端未接收到订阅消息，为确保第二浏览器客户端此次能接收到项目开发消息，服务器通过仿双向连接通道向第二浏览器客户端发送第一浏览器客户端提供的项目开发信息。本申请能够针对浏览器客户端未接收到订阅消息的情况输出解决方案，使得未接收到订阅消息的第二浏览器客户端也能够接收到第一浏览器客户端提供的项目开发信息。

在又一种可能的实施方式中，所述根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列，包括：

若不存在针对所述多个浏览器客户端的监听队列，则根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列。

在上述方法中，若预先未建立针对多个浏览器客户端的监听队列，则需要根据团队的第一ID和每个浏览器客户端的第二ID预先建立监听队列，为后续接收来自第一浏览器客户端的订阅请求做铺垫。只有预先建立了监听队列，当第一浏览器客户端向服务器发送订阅请求时，才能触发服务器通过监听队列接收该订阅请求，然后监听队列产生相应的事件对象，并把该事件对象发送给与之关联的事件处理器。最后事件处理器启动并执行相关的代码来处理该订阅请求。

在又一种可能的实施方式中，所述通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息之后，还包括：

若当前时间段满足预设条件，则设置所述单向连接通道为待机状态。

在上述方法中，为解决服务器、带宽等资源的浪费问题，可以在非工作时间内将单向连接通道设置为待机状态，如若工程项目三组的工作时间为周一到周五的白天9-12点、下午14-18点，晚上加班的工作时间为20-21点，在上述时间段内单向连接通道保持畅通，但在除上述时间外的休息时间或下班时间内，系统检测到当前时间段为非工作时间，则自动触发服务器/浏览器客户端将单向连接通道设置为待机状态，此时浏览器客户端与服务器暂时无法相互接收/发送消息，本申请通过满足预设条件，则将单向连接通道设置为待机状态的方案，能够有效节约带宽等资源。

第二方面，本申请实施例提供一种基于团队模式的业务通知装置，该业务通知装置包括接收单元、建立单元和发送单元，该业务通知装置用于实现第一方面或第一方面任一种可能的实施方式所描述的方法。

需要说明的是，上述第二方面所描述的业务通知装置所包含的处理器，可以是专门用于执行这些方法的处理器（便于区别称为专用处理器），也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。

可选的，上述计算机程序可以存在存储器中。示例性的，存储器可以为非瞬时性（non-transitory）存储器，例如只读存储器（Read Only Memory，ROM），其可以与处理器集成在同一块器件上，也可以分别设置在不同的器件上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

在一种可能的实施方式中，上述至少一个存储器位于上述业务通知装置之外。

在又一种可能的实施方式中，上述至少一个存储器位于上述业务通知装置之内。

在又一种可能的实施方式之中，上述至少一个存储器的部分存储器位于上述业务通知装置之内，另一部分存储器位于上述业务通知装置之外。

本申请中，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可以被集成在一起。

第三方面，本申请实施例提供一种基于团队模式的业务通知设备，该业务通知设备包括处理器和存储器；所述存储器中存储有计算机程序；处理器执行计算机程序时，计算设备执行前述第一或者第一方面任一项所描述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现前述第一至第四方面任一项所描述的方法。

第五方面，本申请提供了一种计算机程序产品，计算机程序产品包括计算机指令，当所述指令在至少一个处理器上运行时，实现前述第一至第四方面任一项所描述的方法。该计算机程序产品可以为一个软件安装包，在需要使用前述方法的情况下，可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。

本申请第二至第五方面所提供的技术方法，其有益效果可以参考第一方面的技术方案的有益效果，此处不再赘述。

附图说明

下面将对实施例描述中所需要使用的附图作简单的介绍。

图1是本申请实施例提供的一种基于团队模式的业务通知系统的架构示意图；

图2是本申请实施例提供的一种基于团队模式的业务通知方法的流程示意图；

图3是本申请实施例提供的一种服务器与每个浏览器客户端之间建立单向连接通道的示意图；

图4是本申请实施例提供的一种基于团队模式的业务通知装置40的结构示意图；

图5是本申请实施例提供的一种基于团队模式的业务通知设备50的结构示意图。

具体实施方式

下面结合附图对本申请实施例进行详细介绍。

为了便于理解，先对本申请实施例涉及的技术术语进行简单介绍。

1.订阅消息，在软件架构中是一种消息范式，订阅消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者），而是将发布的消息分为不同的类别后，向服务器发送包括相关信息的订阅请求，服务器接收到该订阅请求后，向不特定多数人发送该订阅消息，而无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收自身需要的消息。

2.事件源（EventSource），是一种使用超文本传输协议(Hyper Text TransferProtocol，HTTP)传输的单向通信技术，它的简单模型是一个客户端去从服务器端订阅一条“流”，之后服务端可以发送消息给客户端直到服务端或者客户端关闭该“流”，因此EventSource也被称为"Server-Sent-Event"。

3.WebSocket，是一种在单个传输控制协议(Transmission Control Protocol，TCP)连接上进行全双工通信的协议，WebSocket使得浏览器客户端和服务器之间的数据交换变得更加简单，它允许服务器主动向浏览器客户端推送数据。在WebSocket API中（WebSocket API是一个使用WebSocket协议的接口，通过该接口建立全双工通道来接收/发送消息），浏览器客户端和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

4.轮询，是指在特定的时间间隔（如每1秒），由浏览器客户端定时向服务器发送HTTP协议请求，服务器接收到请求后立即查找消息，然后向浏览器客户端返回最新的数据。

5.Flask，是一个使用编程语言Python 编写的轻量级 Web 应用框架。

上述相关的术语解释可以应用于下文的实施例中。

下面对本申请实施例的架构进行介绍。

请参见图1，图1是本申请实施例提供的一种基于团队模式的业务通知系统的架构示意图，该系统包括服务器101和浏览器客户端102，服务器101为浏览器客户端102提供计算或应用服务以及进行信息交互。

服务器101可以为一个服务器或者多个服务器组成的服务器集群，可以是电脑、上位机，服务器101主要用于通过内部暴露的接口接收多个浏览器客户端102中每个浏览器客户端发送的请求消息、接收第一浏览器客户端102发送的订阅请求、根据团队的第一ID和每个浏览器客户端102的第二ID建立与每个浏览器客户端102之间的单向连接通道、根据团队的第一ID和每个浏览器客户端102的第二ID建立针对多个浏览器客户端102的监听队列以及通过与每个浏览器客户端102之间的单向连接通道向每个浏览器客户端102发送订阅消息。浏览器客户端102用于向服务器101发送订阅请求、与服务器101建立单向连接通道以及接收服务器101发送的订阅消息，在本申请实施例中，浏览器客户端是安装了浏览器的客户端，浏览器是可以显示网页服务器或者文件系统的超文本标记语言(Hyper Text MarkupLanguage，HTML)文件内容（即标准通用标记语言的一个应用），具有处理能力和数据收发能力并使得用户能够与这些文件交互的一种软件程序，能够显示在国际互联网或局域网等内的文字、图像及其他信息，比如，该浏览器客户端102可以为业务人员（或开发人员）处理业务的设备，比如笔记本电脑、平板电脑、掌上电脑、手机、超级移动个人计算机（Ultra-mobile Personal Computer，UMPC）、上网本以及个人数字助理（Personal DigitalAssistant，PDA）。

下面对本申请实施例的方法进行详细介绍。

请参见图2，图2是本申请实施例提供的一种基于团队模式的业务通知方法的流程示意图。可选的，该方法可以应用图1所述系统。

如图2所述的基于团队模式的业务通知方法至少包括步骤S201至步骤S204。

步骤S201：服务器接收多个浏览器客户端中每个浏览器客户端发送的请求消息。

其中，请求消息包括团队的第一ID和每个浏览器客户端的第二ID，团队包括多个浏览器客户端，多个浏览器客户端包括浏览器客户端1、浏览器客户端2、浏览器客户端3、...、 浏览器客户端n（n为大于3的正整数）。

应说明的是，在本申请实施例中，轻量级别的服务器可以是通过编程语言Python的Flask编写搭建而成的轻量级 Web 应用框架，通过此种方式搭建的轻量级别的服务器精度更高、速度更快。但本申请并不限于上述方式为搭建服务器的唯一方式。

具体的，本申请可以通过服务器的通信接口接收多个浏览器客户端中每个浏览器客户端发送的请求消息。举例来说，若某一团队的第一ID为“工程项目三组”，其中，该团队内的每个浏览器客户端的第二ID可以表示为：浏览器客户端1的ID为“秦总监”、浏览器客户端2的ID为“周工”、浏览器客户端3的ID为“李工”等，多个浏览器客户端中每个浏览器客户端将其所在的团队的第一ID及每个浏览器客户端的第二ID分别发送给服务器，服务器接收到多个浏览器客户端中每个浏览器客户端发送的请求消息后，针对所在的相同团队ID的浏览器客户端确定同一团队区域，以方便后续针对相同团队的浏览器客户端广播通知相关信息。

步骤S202：服务器根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的单向连接通道。

具体的，服务器在针对所在的相同团队ID的浏览器客户端确定同一团队区域后，可以根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的EventSource的单向连接通道，如图3所示，图3是本申请实施例提供的一种服务器与每个浏览器客户端之间建立单向连接通道的示意图，举例来说，若确定多个浏览器客户端的团队区域（如团队ID为“工程项目三组”）后，分别与浏览器客户端1（如ID为“秦总监”）、浏览器客户端2（如ID为“周工”）、浏览器客户端3（如ID为“李工”）、...、浏览器客户端n（如ID为“王工”）建立单向连接通道，其中，事件源EventSource使用的是超文本传输协议(Hyper TextTransfer Protocol，HTTP)传输的单向通信技术，作为服务器推送的一个网络事件接口，其模型是第一浏览器客户端在服务器订阅一条“流”，先向服务器发出订阅请求，服务器才给予响应。在服务器接收到该订阅请求后，可以向其它浏览器客户端发送订阅消息，一个EventSource实例会对服务器开启一个持久化的连接，直至服务器或者浏览器客户端关闭该“流”，单向连接通道才会关闭。在本方案中，单向连接通道用于服务器在第一ID的团队内向团队内的成员对应的浏览器客户端发送订阅消息。这种单向通信方式在互联网领域能够发挥巨大的作用，服务器可以是无状态的，极大地简化了服务器的服务流程，提高数据的传输效率。

步骤S203：服务器根据团队的第一ID和每个浏览器客户端的第二ID建立针对多个浏览器客户端的监听队列。

具体的，服务器根据团队的第一ID和每个浏览器客户端的第二ID建立针对多个浏览器客户端的监听队列的具体步骤为：服务器可以根据每个浏览器客户端发送的个人第二ID以及所在的团队的第一ID（如ID为“秦总监”的浏览器客户端1所在的团队为“工程项目三组”、ID为“周工”的浏览器客户端2所在的团队为“工程项目三组”、ID为“李工”的浏览器客户端3所在的团队为“工程项目三组”、...、ID为“王工”的浏览器客户端n所在的团队为“工程项目三组”，其中，n为大于3的正整数），将团队的第一ID相同的浏览器客户端划分为同一个团体区域（如将同属于“工程项目三组的浏览器客户端”划分为同一个团体区域），在确定多个浏览器客户端的团队区域（如团队ID为“工程项目三组”）后，再根据团队的第一ID（“工程项目三组”团队）分别与浏览器客户端1（如ID为“秦总监”）、浏览器客户端2（如ID为“周工”）、浏览器客户端3（如ID为“李工”）、...、浏览器客户端n（如ID为“王工”）建立针对每个浏览器客户端的监听队列，每个团队主题相当于一个消息队列，订阅者（如订阅消息的浏览器客户端2、浏览器客户端3、...、浏览器客户端n）在接收消息之前需要先订阅一系列相关的主题（每个团队主题都生成并维护一个订阅者列表），该监听队列用于接收第一浏览器客户端发送的订阅请求。若存在针对多个浏览器客户端的监听队列，则服务器可以直接监听第一浏览器客户端是否向服务器发送订阅请求。

可选的，若不存在针对多个浏览器客户端的监听队列，则重复上述步骤，预先根据团队的第一ID和每个浏览器客户端的第二ID建立针对多个浏览器客户端的监听队列。

步骤S204：若通过监听队列接收到第一浏览器客户端发送的订阅请求，则服务器通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息。

应说明的是，第一浏览器客户端为多个浏览器客户端中的任意一个浏览器客户端，本申请并不限定只有某一个固定的浏览器客户端才能向服务器发送订阅请求，多个浏览器客户端中的任意一个浏览器客户端均可以向服务器发送订阅请求。

具体的，若ID为“秦总监”的浏览器客户端1完成了相应工程项目二期的业务后，需要通知项目组成员的进度或者是需要向项目组成员发布新的指示，此时需要向某个团队主题发送订阅请求（订阅请求包括ID为“秦总监”的浏览器客户端1，即第一浏览器客户端提供的项目开发信息），服务器通过监听队列接收到第一浏览器客户端发送的订阅请求后，会将该订阅消息发送给该团队主题的所有订阅者（如订阅消息的浏览器客户端2、浏览器客户端3、...、浏览器客户端n），同一团队主题的订阅者接收到的订阅消息是完全一样的，也即一份消息数据可以被多次消费。订阅消息的应用也比较广泛，比如大量物联网设备和物联网云平台之间的消息传递、网络中各节点之间的消息传递、进程或服务之间的复杂消息传递等。

可选的，服务器通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息之后，为解决服务器、带宽等资源的浪费问题，服务器/浏览器客户端可以在非工作时间内将单向连接通道设置为待机状态，举例来说，若工程项目三组的工作时间为周一到周五的白天9-12点、下午14-18点，晚上若加班的话，工作时间为20-21点，在上述时间段内保持单向连接通道畅通，但在除上述时间外的休息时间或下班时间内，系统若检测到当前时间段为非工作时间，则自动触发服务器/浏览器客户端将单向连接通道设置为待机状态，此时浏览器客户端与服务器暂时中止相互接收/发送消息。若当前时间段满足预设条件，则将单向连接通道设置为待机状态的方案，能够有效节约带宽等资源。可选的，服务器通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息之后，还可以检测多个浏览器客户端是否都返回了针对订阅消息的确认消息，用以确认每个浏览器客户端是否都接收到了该订阅消息，得到的检测结果有两种可能性。

结果一，若服务器检测到第二浏览器客户端发送的确认消息，则服务器向第二浏览器客户端发送第一浏览器客户端提供的项目开发信息，举例来说，若ID为“周工”的浏览器客户端2接收到服务器发送的订阅消息后，确认需要该项目的相关信息，则向服务器发送针对该订阅消息的确认消息，如点击弹框按钮中的“确认”键，服务器会接收到ID为“周工”的浏览器客户端2发送的确认消息，则向ID为“周工”的浏览器客户端2发送ID为“秦总监”的浏览器客户端1提供的项目开发信息（如项目开发信息内容可以为“此次项目的各部分负责人需要完成针对各自负责的部分的策划书，要求内容详细且合理，下周三18点之前输出给我”）。应说明的是，第二浏览器客户端为多个浏览器客户端中的任意一个浏览器客户端，服务器检测第二浏览器客户端发送的确认消息表明服务器对于多个浏览器客户端中的任意一个浏览器客户端均需要进行检测。

结果二，若服务器未检测到第二浏览器客户端（如ID为“周工”的浏览器客户端2）发送的确认消息，则表明该第二浏览器客户端可能未接收到服务器发送的订阅消息，此时为确认第二浏览器客户端是否接收到服务器发送的订阅消息，可以单独建立服务器与第二浏览器客户端之间的仿双向连接通道，服务器通过仿双向连接通道接收第二浏览器客户端发送的针对订阅消息的提醒信息，该提醒消息表明第二浏览器客户端未接收到订阅消息，为确保第二浏览器客户端此次能接收到项目开发消息，服务器可以通过仿双向连接通道向第二浏览器客户端发送第一浏览器客户端提供的项目开发信息。本申请能够针对浏览器客户端未接收到订阅消息的情况输出合理的解决方案，使得未接收到订阅消息的第二浏览器客户端也能够接收到第一浏览器客户端提供的项目开发信息。

在现有技术中，为了解决实现团队模式下的广播通知，通常采用建立双向连接通道的方式，一旦服务器接收到消息，立即通过建立的双向连接通道推送给浏览器客户端，或者是轮询的方式，由浏览器客户端定时发送请求给服务器，服务器接收到请求则立即查找消息，返回给浏览器客户端，而本申请根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的单向连接通道的方式，并根据团队的第一ID（如团体“工程项目三组”）和每个浏览器客户端的第二ID（如浏览器客户端1的ID为“秦总监”、浏览器客户端2的ID为“周工”、浏览器客户端3的ID为“李工”）建立针对多个浏览器客户端的监听队列，若通过监听队列接收到第一浏览器客户端发送的订阅请求（如秦总监完成了相应的业务，需要将项目开发信息广播通知项目组其他成员，则可以向服务器发送订阅请求，该订阅请求是为使得服务器向每个浏览器客户端发送订阅消息的请求消息），则通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息（服务器不会将项目开发消息直接发送给特定的浏览器客户端，而是需要先通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，该订阅消息用于多个浏览器客户端确认是否需要接受该项目开发消息），本申请通过建立的监听队列接收到第一浏览器客户端发送的订阅请求后，通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，能够实现基于团队模式下的业务通知的目的，且相较于现有技术而言，能够节约带宽资源。

上述详细阐述了本申请实施例的方法，下面提供本申请实施例的装置。

可以理解的是，本申请实施例提供的多个装置，例如业务通知装置，为了实现上述方法实施例中的功能，其包含了执行各个功能相应的硬件结构、软件模块、或硬件结构和软件结构的组合等。

本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以在不同的使用场景中，使用不同的装置实现方式来实现前述的方法实施例，对于装置的不同实现方式不应认为超出本申请实施例的范围。

本申请实施例可以对装置进行功能模块的划分。例如，可对应各个功能划分各个功能模块，也可将两个或两个以上的功能集成在一个功能模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

例如，以采用集成的方式划分装置各个功能模块的情况下，本申请例举几种可能的处理装置。

请参见图4，图4是本申请实施例提供的一种基于团队模式的业务通知装置40的结构示意图，该业务通知装置40可以为服务器或者为服务器中的一个器件，例如芯片、软件模块、集成电路等。该业务通知装置40用于实现前述的基于团队模式的业务通知方法，例如图2所述的基于团队模式的业务通知方法。

一种可能的实施方式中，该业务通知装置40可以包括接收单元401、建立单元402和发送单元403。

所述接收单元401，用于接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息，其中，所述请求消息包括团队的第一ID和所述每个浏览器客户端的第二ID，所述团队包括所述多个浏览器客户端；

所述建立单元402，用于根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道，其中，所述单向连接通道用于在所述第一ID的所述团队内发送订阅消息；

所述建立单元402，还用于根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；

若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则所述发送单元403，用于通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息，其中，所述第一浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在现有技术中，为了解决实现团队模式下的广播通知，通常采用建立双向连接通道的方式，一旦服务器接收到消息，立即通过建立的双向连接通道推送给浏览器客户端，或者是轮询的方式，由浏览器客户端定时发送请求给服务器，服务器接收到请求则立即查找消息，返回给浏览器客户端，而本申请根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的单向连接通道的方式，并根据团队的第一ID（如团体“工程项目三组”）和每个浏览器客户端的第二ID（如浏览器客户端1的ID为“秦总监”、浏览器客户端2的ID为“周工”、浏览器客户端3的ID为“李工”）建立针对多个浏览器客户端的监听队列，若通过监听队列接收到第一浏览器客户端发送的订阅请求（如秦总监完成了相应的业务，需要将项目开发信息广播通知项目组其他成员，则可以向服务器发送订阅请求，该订阅请求是为使得服务器向每个浏览器客户端发送订阅消息的请求消息），则通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息（服务器不会将项目开发消息直接发送给特定的浏览器客户端，而是需要先通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，该订阅消息用于多个浏览器客户端确认是否需要接受该项目开发消息），本申请通过建立的监听队列接收到第一浏览器客户端发送的订阅请求后，通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，能够实现基于团队模式下的业务通知的目的，且相较于现有技术而言，能够节约带宽资源。

另一种可能的实施方式中，还包括：

搭建单元，用于通过Python的Flask搭建轻量级别的通信接口，其中，所述通信接口还用于通过所述监听队列接收所述第一浏览器客户端发送的订阅请求。

在上述方法中，搭建轻量级别的服务器的方式可以是利用编程语言Python 的Flask编写的轻量级 Web 应用框架，但本申请并不限于上述方式为搭建服务器的唯一方式。在服务器搭建好后，在搭建好的服务器内暴露一个接口，该接口用于接收多个浏览器客户端中每个浏览器客户端发送的请求消息、与浏览器客户端建立单向连接通道、建立监听队列以及通过监听队列接收第一浏览器客户端发送的订阅请求，本申请主要是通过浏览器客户端调用服务器暴露的接口来接收/发送相关的数据信息。本申请利用编程语言Python的Flask编写的轻量级Web 应用框架能够使得服务器搭建的精度更高、速度更快。

又一种可能的实施方式中，还包括：

检测单元，用于检测所述多个浏览器客户端是否返回针对所述订阅消息的确认消息；

若检测到第二浏览器客户端发送的所述确认消息，则所述发送单元403，还用于向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息，所述第二浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在本申请实施例中，服务器可以根据每个浏览器客户端发送的个人第二ID以及所在的团队的第一ID（如ID为“秦总监”的浏览器客户端1所在的团队为“工程项目三组”、ID为“周工”的浏览器客户端2所在的团队为“工程项目三组”、ID为“李工”的浏览器客户端3所在的团队为“工程项目三组”、...、ID为“王工”的浏览器客户端n所在的团队为“工程项目三组”，其中，n为大于3的正整数），将团队的第一ID相同的浏览器客户端划分为同一个团体区域（如将同属于“工程项目三组的浏览器客户端”划分为同一个团体区域），在确定多个浏览器客户端的团队区域（如团队ID为“工程项目三组”）后，再根据团队的第一ID（“工程项目三组”团队）分别与浏览器客户端1（如ID为“秦总监”）、浏览器客户端2（如ID为“周工”）、浏览器客户端3（如ID为“李工”）、...、浏览器客户端n（如ID为“王工”）建立针对每个浏览器客户端的监听队列，每个团队主题相当于一个消息队列，订阅者（如订阅消息的浏览器客户端2、浏览器客户端3、...、浏览器客户端n）在接收消息之前需要先订阅一系列相关的主题（每个团队主题都生成并维护一个订阅者列表），该监听队列用于接收第一浏览器客户端发送的订阅请求。若存在针对多个浏览器客户端的监听队列，则服务器可以直接监听第一浏览器客户端是否向服务器发送订阅请求。本方案通过建立监听队列，能够使得及时接收第一浏览器客户端发送的订阅请求，实现基于团队模式下广播通知消息的目的。

又一种可能的实施方式中，还包括：

若未检测到所述第二浏览器客户端发送的所述确认消息，则所述建立单元402，还用于与所述第二浏览器客户端建立仿双向连接通道；

所述接收单元401，还用于通过所述仿双向连接通道接收所述第二浏览器客户端发送的针对所述订阅消息的提醒消息，其中，所述提醒消息用于提醒所述第二浏览器客户端未接收到所述订阅消息；

所述发送单元403，还用于通过所述仿双向连接通道向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息。

在本申请实施例中，若未检测到第二浏览器客户端发送的确认信息，则表明该第二浏览器客户端可能未接收到服务器发送的订阅消息，此时为确认第二浏览器客户端是否接收到服务器发送的订阅消息，可以单独建立服务器与第二浏览器客户端之间的仿双向连接通道，服务器通过仿双向连接通道接收第二浏览器客户端发送的针对订阅消息的提醒信息，该提醒消息表明第二浏览器客户端未接收到订阅消息，为确保第二浏览器客户端此次能接收到项目开发消息，服务器通过仿双向连接通道向第二浏览器客户端发送第一浏览器客户端提供的项目开发信息。本申请能够针对浏览器客户端未接收到订阅消息的情况输出解决方案，使得未接收到订阅消息的第二浏览器客户端也能够接收到第一浏览器客户端提供的项目开发信息。

又一种可能的实施方式中，若不存在针对所述多个浏览器客户端的监听队列，则所述建立单元402，还用于根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列。

在本申请实施例中，若预先未建立针对多个浏览器客户端的监听队列，则需要根据团队的第一ID和每个浏览器客户端的第二ID预先建立监听队列，为后续接收来自第一浏览器客户端的订阅请求做铺垫。只有预先建立了监听队列，当第一浏览器客户端向服务器发送订阅请求时，才能触发服务器通过监听队列接收该订阅请求，然后监听队列产生相应的事件对象，并把该事件对象发送给与之关联的事件处理器。最后事件处理器启动并执行相关的代码来处理该订阅请求。

又一种可能的实施方式中，还包括：

若当前时间段满足预设条件，则设置单元，用于设置所述单向连接通道为待机状态。

在本申请实施例中，为解决服务器、带宽等资源的浪费问题，可以在非工作时间内将单向连接通道设置为待机状态，如若工程项目三组的工作时间为周一到周五的白天9-12点、下午14-18点，晚上加班的工作时间为20-21点，在上述时间段内单向连接通道保持畅通，但在除上述时间外的休息时间或下班时间内，系统检测到当前时间段为非工作时间，则自动触发服务器/浏览器客户端将单向连接通道设置为待机状态，此时浏览器客户端与服务器暂时无法相互接收/发送消息，本申请通过满足预设条件，则将单向连接通道设置为待机状态的方案，能够有效节约带宽等资源。

请参见图5，图5是本申请实施例提供的一种基于团队模式的业务通知设备50的结构示意图，该业务通知设备50可以为服务器或者为服务器中的一个器件，例如芯片、软件模块、集成电路等。该业务通知设备50可以包括至少一个处理器501。可选的还可以包括至少一个存储器503。进一步可选的，该业务通知设备50还可以包括通信接口502。更进一步可选的，还可以包含总线504，其中，处理器501、通信接口502和存储器503通过总线504相连。

其中，处理器501是进行算术运算和/或逻辑运算的模块，具体可以是中央处理器（Central Processing Unit，CPU）、图片处理器（Graphics Processing Unit，GPU）、微处理器（Microprocessor Unit，MPU）、专用集成电路（Application Specific IntegratedCircuit，ASIC）、现场可编程逻辑门阵列（Field Programmable Gate Array，FPGA）、复杂可编程逻辑器件（Complex Programmable Logic Device，CPLD）、协处理器（协助中央处理器完成相应处理和应用）、微控制单元（Microcontroller Unit，MCU）等处理模块中的一种或者多种的组合。

通信接口502可以用于为所述至少一个处理器提供信息输入或者输出。和/或，所述通信接口502可以用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路（Wi-Fi、蓝牙、通用无线传输、车载短距通信技术以及其他短距无线通信技术等）接口。可选的，通信接口502还可以包括与接口耦合的发射器（如射频发射器、天线等），或者接收器等。

存储器503用于提供存储空间，存储空间中可以存储操作系统和计算机程序等数据。存储器503可以是随机存储记忆体（Random Access Memory，RAM）、只读存储器（Read-only Memory，ROM）、可擦除可编程只读存储器（Erasable Programmable Read-onlyMemory，EPROM）、或便携式只读存储器（Compact Disc Read-only Memory，CD-ROM）等等中的一种或者多种的组合。

该业务通知设备50中的至少一个处理器501用于执行前述的方法，例如图2所述实施例所描述的方法。

可选的，处理器501，可以是专门用于执行这些方法的处理器（便于区别称为专用处理器），也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。可选的，在计算设备包括至少一个处理器501的情况下，上述计算机程序可以存在存储器503中。

可选的，该业务通知设备50中的至少一个处理器501用于执行调用计算机指令，以执行以下操作：

接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息，其中，所述请求消息包括团队的第一ID和所述每个浏览器客户端的第二ID，所述团队包括所述多个浏览器客户端；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道，其中，所述单向连接通道用于在所述第一ID的所述团队内发送订阅消息；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；

若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息，其中，所述第一浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在现有技术中，为了解决实现团队模式下的广播通知，通常采用建立双向连接通道的方式，一旦服务器接收到消息，立即通过建立的双向连接通道推送给浏览器客户端，或者是轮询的方式，由浏览器客户端定时发送请求给服务器，服务器接收到请求则立即查找消息，返回给浏览器客户端，而本申请根据团队的第一ID和每个浏览器客户端的第二ID建立与每个浏览器客户端之间的单向连接通道的方式，并根据团队的第一ID（如团体“工程项目三组”）和每个浏览器客户端的第二ID（如浏览器客户端1的ID为“秦总监”、浏览器客户端2的ID为“周工”、浏览器客户端3的ID为“李工”）建立针对多个浏览器客户端的监听队列，若通过监听队列接收到第一浏览器客户端发送的订阅请求（如秦总监完成了相应的业务，需要将项目开发信息广播通知项目组其他成员，则可以向服务器发送订阅请求，该订阅请求是为使得服务器向每个浏览器客户端发送订阅消息的请求消息），则通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息（服务器不会将项目开发消息直接发送给特定的浏览器客户端，而是需要先通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，该订阅消息用于多个浏览器客户端确认是否需要接受该项目开发消息），本申请通过建立的监听队列接收到第一浏览器客户端发送的订阅请求后，通过与每个浏览器客户端之间的单向连接通道向每个浏览器客户端发送订阅消息，能够实现基于团队模式下的业务通知的目的，且相较于现有技术而言，能够节约带宽资源。

可选的，所述处理器501还用于：

通过Python的Flask搭建轻量级别的通信接口，其中，所述通信接口还用于通过所述监听队列接收所述第一浏览器客户端发送的订阅请求。

在本申请实施例中，搭建轻量级别的服务器的方式可以是利用编程语言Python的Flask编写的轻量级 Web 应用框架，但本申请并不限于上述方式为搭建服务器的唯一方式。在服务器搭建好后，在搭建好的服务器内暴露一个接口，该接口用于接收多个浏览器客户端中每个浏览器客户端发送的请求消息、与浏览器客户端建立单向连接通道、建立监听队列以及通过监听队列接收第一浏览器客户端发送的订阅请求，本申请主要是通过浏览器客户端调用服务器暴露的接口来接收/发送相关的数据信息。本申请利用编程语言Python的Flask编写的轻量级 Web 应用框架能够使得服务器搭建的精度更高、速度更快。

可选的，所述处理器501还用于：

检测所述多个浏览器客户端是否返回针对所述订阅消息的确认消息；

若检测到第二浏览器客户端发送的所述确认消息，则向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息，所述第二浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

在本申请实施例中，服务器可以根据每个浏览器客户端发送的个人第二ID以及所在的团队的第一ID（如ID为“秦总监”的浏览器客户端1所在的团队为“工程项目三组”、ID为“周工”的浏览器客户端2所在的团队为“工程项目三组”、ID为“李工”的浏览器客户端3所在的团队为“工程项目三组”、...、ID为“王工”的浏览器客户端n所在的团队为“工程项目三组”，其中，n为大于3的正整数），将团队的第一ID相同的浏览器客户端划分为同一个团体区域（如将同属于“工程项目三组的浏览器客户端”划分为同一个团体区域），在确定多个浏览器客户端的团队区域（如团队ID为“工程项目三组”）后，再根据团队的第一ID（“工程项目三组”团队）分别与浏览器客户端1（如ID为“秦总监”）、浏览器客户端2（如ID为“周工”）、浏览器客户端3（如ID为“李工”）、...、浏览器客户端n（如ID为“王工”）建立针对每个浏览器客户端的监听队列，每个团队主题相当于一个消息队列，订阅者（如订阅消息的浏览器客户端2、浏览器客户端3、...、浏览器客户端n）在接收消息之前需要先订阅一系列相关的主题（每个团队主题都生成并维护一个订阅者列表），该监听队列用于接收第一浏览器客户端发送的订阅请求。若存在针对多个浏览器客户端的监听队列，则服务器可以直接监听第一浏览器客户端是否向服务器发送订阅请求。本方案通过建立监听队列，能够使得及时接收第一浏览器客户端发送的订阅请求，实现基于团队模式下广播通知消息的目的。

可选的，所述处理器501还用于：

若未检测到所述第二浏览器客户端发送的所述确认消息，则与所述第二浏览器客户端建立仿双向连接通道；

通过所述仿双向连接通道接收所述第二浏览器客户端发送的针对所述订阅消息的提醒消息，其中，所述提醒消息用于提醒所述第二浏览器客户端未接收到所述订阅消息；

通过所述仿双向连接通道向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息。

在本申请实施例中，若未检测到第二浏览器客户端发送的确认信息，则表明该第二浏览器客户端可能未接收到服务器发送的订阅消息，此时为确认第二浏览器客户端是否接收到服务器发送的订阅消息，可以单独建立服务器与第二浏览器客户端之间的仿双向连接通道，服务器通过仿双向连接通道接收第二浏览器客户端发送的针对订阅消息的提醒信息，该提醒消息表明第二浏览器客户端未接收到订阅消息，为确保第二浏览器客户端此次能接收到项目开发消息，服务器通过仿双向连接通道向第二浏览器客户端发送第一浏览器客户端提供的项目开发信息。本申请能够针对浏览器客户端未接收到订阅消息的情况输出解决方案，使得未接收到订阅消息的第二浏览器客户端也能够接收到第一浏览器客户端提供的项目开发信息。

可选的，所述处理器501还用于：

若不存在针对所述多个浏览器客户端的监听队列，则根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列。

在本申请实施例中，若预先未建立针对多个浏览器客户端的监听队列，则需要根据团队的第一ID和每个浏览器客户端的第二ID预先建立监听队列，为后续接收来自第一浏览器客户端的订阅请求做铺垫。只有预先建立了监听队列，当第一浏览器客户端向服务器发送订阅请求时，才能触发服务器通过监听队列接收该订阅请求，然后监听队列产生相应的事件对象，并把该事件对象发送给与之关联的事件处理器。最后事件处理器启动并执行相关的代码来处理该订阅请求。

可选的，所述处理器501还用于：

若当前时间段满足预设条件，则设置所述单向连接通道为待机状态。

在本申请实施例中，为解决服务器、带宽等资源的浪费问题，可以在非工作时间内将单向连接通道设置为待机状态，如若工程项目三组的工作时间为周一到周五的白天9-12点、下午14-18点，晚上加班的工作时间为20-21点，在上述时间段内单向连接通道保持畅通，但在除上述时间外的休息时间或下班时间内，系统检测到当前时间段为非工作时间，则自动触发服务器/浏览器客户端将单向连接通道设置为待机状态，此时浏览器客户端与服务器暂时无法相互接收/发送消息，本申请通过满足预设条件，则将单向连接通道设置为待机状态的方案，能够有效节约带宽等资源。

本申请还提供了一种算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现前述的基于团队模式的业务通知方法，例如图2所述的方法。

本申请还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，在被计算设备执行时，实现前述的基于团队模式的业务通知方法，例如图2所述的方法。

本申请实施例中，“举例来说”或者“比如”等词用于表示作例子、例证或说明。本申请中被描述为“举例来说”或者“比如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“举例来说”或者“比如”等词旨在以具体方式呈现相关概念。

本申请中实施例提到的“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项（个）或复数项（个）的任意组合。例如，a、b、或c中的至少一项（个），可以表示：a、b、c、（a和b）、（a和c）、（b和c）、或（a和b和c），其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一设备和第二设备，只是为了便于描述，而并不是表示这第一设备和第二设备的结构、重要程度等的不同，在某些实施例中，第一设备和第二设备还可以是同样的设备。

上述实施例中所用，根据上下文，术语“当……时”可以被解释为意思是“如果……”或“在……后”或“响应于确定……”或“响应于检测到……”。以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的构思和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种基于团队模式的业务通知方法，其特征在于，应用于服务器，所述服务器属于业务系统，所述业务系统包括所述服务器和多个浏览器客户端，所述多个浏览器客户端用于多个开发人员协作进行项目开发，所述方法包括：

接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息，其中，所述请求消息包括团队的第一ID和所述每个浏览器客户端的第二ID，所述团队包括所述多个浏览器客户端；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道，其中，所述单向连接通道用于在所述第一ID的所述团队内发送订阅消息；

根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；

若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息，其中，所述第一浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

2.根据权利要求1所述的方法，其特征在于，所述接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息之前，还包括：

通过Python的Flask搭建轻量级别的通信接口，其中，所述通信接口还用于通过所述监听队列接收所述第一浏览器客户端发送的订阅请求。

3.根据权利要求1或2所述的方法，其特征在于，所述订阅请求包括所述第一浏览器客户端提供的项目开发信息；所述通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息之后，还包括：

检测所述多个浏览器客户端是否返回针对所述订阅消息的确认消息；

若检测到第二浏览器客户端发送的所述确认消息，则向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息，所述第二浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

4.根据权利要求3所述的方法，其特征在于，还包括：

若未检测到所述第二浏览器客户端发送的所述确认消息，则与所述第二浏览器客户端建立仿双向连接通道；

通过所述仿双向连接通道接收所述第二浏览器客户端发送的针对所述订阅消息的提醒消息，其中，所述提醒消息用于提醒所述第二浏览器客户端未接收到所述订阅消息；

通过所述仿双向连接通道向所述第二浏览器客户端发送所述第一浏览器客户端提供的项目开发信息。

5.根据权利要求1或2所述的方法，其特征在于，所述根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列，包括：

若不存在针对所述多个浏览器客户端的监听队列，则根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列。

6.根据权利要求1或2所述的方法，其特征在于，所述通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息之后，还包括：

若当前时间段满足预设条件，则设置所述单向连接通道为待机状态。

7.一种基于团队模式的业务通知服务器，其特征在于，应用于业务系统，所述业务系统包括所述服务器和多个浏览器客户端，所述多个浏览器客户端用于多个开发人员协作进行项目开发，所述服务器包括接收单元、建立单元和发送单元，其中：

所述接收单元，用于接收所述多个浏览器客户端中每个浏览器客户端发送的请求消息，其中，所述请求消息包括团队的第一ID和所述每个浏览器客户端的第二ID，所述团队包括所述多个浏览器客户端；

所述建立单元，用于根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立与所述每个浏览器客户端之间的单向连接通道，其中，所述单向连接通道用于在所述第一ID的所述团队内发送订阅消息；

所述建立单元，还用于根据所述团队的第一ID和所述每个浏览器客户端的第二ID建立针对所述多个浏览器客户端的监听队列；

若通过所述监听队列接收到第一浏览器客户端发送的订阅请求，则所述发送单元，用于通过与所述每个浏览器客户端之间的单向连接通道向所述每个浏览器客户端发送订阅消息，其中，所述第一浏览器客户端为所述多个浏览器客户端中的任意一个浏览器客户端。

8.根据权利要求7所述的服务器，其特征在于，还包括：

搭建单元，用于通过Python的Flask搭建轻量级别的通信接口，其中，所述通信接口还用于通过所述监听队列接收第一浏览器客户端发送的订阅请求。

9.一种基于团队模式的业务通知设备，其特征在于，所述设备包括处理器和存储器，所述存储器用于存储计算机指令，所述处理器用于调用所述计算机指令，以实现权利要求1-6中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现如权利要求1-6中任一项所述的方法。

Images