一种应用服务器的消息通知方法及装置与流程

本发明涉及服务的消息通知领域，特别是涉及一种应用服务器的消息通知方法及装置。

背景技术：

随着国产应用服务器的不断发展，客户对于应用服务器的功能和性能要求也越来越高。

在中大型企业的应用服务器集群环境中，应用服务器的数量往往都在成百上千台，在数量如此庞大的应用服务器同时工作时难免会有集群中的应用服务器因为访问量过大的原因导致性能降低而需要告知用户的情况。另外，应用服务器在执行自身的某些服务功能后使用者需要得知具体的执行情况等一系列信息并进行后续操作。可见应用服务器向用户进行消息的反馈能够更方便用户对于应用服务器情况的了解。

但是目前的国产应用服务器在自身出现问题后和执行功能后的信息反馈方面还有所欠缺，因此会造成用户不能具体清楚的了解应用服务器的状态的情况或是功能执行的情况，进而降低应用服务器的整体实用性以及用户的体验性。

由此可见，提供一种应用服务器的消息通知方法以提高应用服务器的整体实用性以及用户的体验感，是本领域技术人员亟待解决的问题。

技术实现要素：

本发明的目的是提供一种应用服务器的消息通知方法及装置，进一步提高了应用服务器整体的实用性及用户的体验性。

为解决上述技术问题，本发明提供一种应用服务器的消息通知方法，包括：

设置进行消息通知的通知途径；

判断应用服务器运行时是否有状态事件发生；

如果是，则根据状态事件的内容对状态事件进行相应的转化，以得到通知消息；

将通知消息通过通知途径进行反馈。

优选的，在设置进行消息通知的通知途径之前，该方法进一步包括：

设置用于开启或关闭消息通知功能的配置参数；

其中，配置参数表征开启消息通知功能。

优选的，在设置进行消息通知的通知途径之前，该方法进一步包括：

获取包括所有可选择的通知途径在内的配置列表；

相应的，设置进行消息通知的通知途径，具体为：

在配置列表中设置进行消息通知的通知途径。

优选的，在将通知消息通过通知途径进行反馈后，该方法进一步包括：

将通知消息写入数据库。

优选的，通知途径具体为日志文件途径，

相应的，将通知消息通过通知途径进行反馈，具体为：

将通知消息写入日志文件以进行反馈。

优选的，状态事件具体为：

应用服务器出现性能故障。

此外，本发明还提供一种应用服务器的消息通知装置，包括：

设置模块，用于设置进行消息通知的通知途径；

事件判断模块，用于判断应用服务器运行时是否有状态事件发生，如果是则执行事件转化模块；

事件转化模块，用于根据状态事件的内容对状态事件进行相应的转化，以得到通知消息；

反馈模块，用于将通知消息通过通知途径进行反馈。

优选的，该装置进一步包括：

功能启停模块，用于设置用于开启或关闭消息通知功能的配置参数。

优选的，该装置进一步包括：

途径列表获取模块，用于获取包括所有可选择的通知途径在内的配置列表。

优选的，该装置进一步包括：

数据库写入模块，用于将通知消息写入数据库。

本发明所提供的应用服务器的消息通知方法，判断应用服务器是否在运行过程中产生了状态事件，如果有，则根据应用服务器的状态事件的内容转换成可以进行反馈通知的通知消息，进而将通知消息按照所设定的通知途径向用户进行通知。因此，本发明所提供的方法中，应用服务器能及时的将通知信息反馈给用户，使用户能够更加具体清楚的了解应用服务器的状态的情况或是功能执行的情况。可见，本方法在现有应用服务器技术的基础上进一步提高了应用服务器整体的实用性及用户的体验性。此外，本发明还提供一种应用服务器的消息通知装置，有益效果如上所述。

附图说明

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

图1为本发明实施例提供的一种应用服务器的消息通知方法的流程图；

图2为本发明实施例提供的另一种应用服务器的消息通知方法的流程图；

图3为本发明实施例提供的一种应用服务器的消息通知装置结构图。

具体实施方式

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

本发明的核心是提供一种应用服务器的消息通知方法，提高了应用服务器整体的实用性及用户的体验性。

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。

实施例一

图1为本发明实施例提供的一种应用服务器的消息通知方法的流程图。请参考图1，应用服务器的消息通知方法的具体步骤包括：

步骤s10：设置进行消息通知的通知途径。

可以理解的是，将消息通知给用户的方式可以有多种选择，因此需要在本步骤中设置将消息进行通知的具体途径，以便在后续步骤中当应用服务器有通知消息时能够采取用户所期望的恰当方式向用户进行通知服务。其中，通知途径可以为email、jms、snmp、eventbus、hipchat、slack、xmpp、datadog等，并且可以根据具体需要采用多种途径进行通知服务的实现，在此不做限定。

步骤s11：判断应用服务器运行时是否有状态事件发生，如果是，只执行步骤s12。

本步骤中，状态事件主要是在应用服务器运行时或是在执行某些功能时所产生的状态信息。状态信息可以是应用服务器资源被过量占用而出现死锁状况、应用服务器执行sql语句追踪功能或请求跟踪功能获得了相应的结果等。应用服务器判断是否有上述情况的发生，如果有，则启动后续相应的应对策略。

步骤s12：根据状态事件的内容对状态事件进行相应的转化，以得到通知消息。

可以理解的是，由于不同的状态事件的内容不同并且可能存在可读性较低的缺点，会增加用户对于状态事件详细了解的难度。因此，需要根据状态事件的具体内容将状态事件进行相应的转化，以得到用户能够清晰直观的了解其内容的通知消息。

步骤s13：将通知消息通过通知途径进行反馈。

由于在之前步骤中对于通知途径进行了设定，因此在本步骤中按照所设置的通知途径进行通知，以到达通知消息能顺利被用户接收到的目的，便于用户对应用服务器状态的详细了解或根据通知消息所记录的应用服务器的问题进行相应的后续处理。

本发明所提供的应用服务器的消息通知方法，判断应用服务器是否在运行过程中产生了状态事件，如果有，则根据应用服务器的状态事件的内容转换成可以进行反馈通知的通知消息，进而将通知消息按照所设定的通知途径向用户进行通知。因此，本发明所提供的方法中，应用服务器能及时的将通知信息反馈给用户，使用户能够更加具体清楚的了解应用服务器的状态的情况或是功能执行的情况。可见，本方法在现有应用服务器技术的基础上进一步提高了应用服务器整体的实用性及用户的体验性。

实施例二

图2为本发明实施例提供的另一种应用服务器的消息通知方法的流程图。图2中步骤s10-s13与图1相同，在此不再赘述。

如图2所示，作为一种优选的实施例，在设置进行消息通知的通知途径之前，该方法进一步包括：

步骤s20：设置用于开启或关闭消息通知功能的配置参数。

其中，配置参数表征开启消息通知功能。在本步骤中，对于消息通知功能设置了开启和关闭的配置参数，目的是能够选择性的将消息通知功能进行开启和关闭。这样的好处在于，当用户暂时不需要消息通知功能时可以将其关闭，能够相对节省应用服务器的可用资源，以提高应用服务器性能。在实际的操作中，可以通过修改配置文件参数的方式实现消息通知服务的开启和关闭。例如在配置文件中设置控制消息通知功能开启和停止的notification-service-configurationenable参数标签，相应的如果该参数标签的值为true，则开启消息通知功能；相反的，若该参数标签的值为false，则关闭消息通知功能。

如图2所示，作为一种优选的实施例，在设置进行消息通知的通知途径之前，该方法进一步包括：

步骤s21：获取包括所有可选择的通知途径在内的配置列表。

相应的，设置进行消息通知的通知途径，具体为在配置列表中设置进行消息通知的通知途径。

需要说明的是，通知途径往往有很多种，并且用户经常需要根据不同种类的消息通知选择与之相应的通知途径。在本实施例中，将用户普遍使用的通知途径在配置文件中整合成为配置列表，每一种通知途径都有相对应参数标签。因此，用户能够直接的在配置列表中设置所使用的通知途径，这进一步方便了用户的使用。当然，用户也可以同时选择多种通知途径进行消息通知，在此不做限定。需要说明的是，本步骤与步骤s20之间的执行顺序并不固定，也可以同时进行。

如图2所示，作为一种优选的实施例，在将通知消息通过通知途径进行反馈后，该方法进一步包括：

步骤s22：将通知消息写入数据库。

可以理解的是，将通知消息存储到数据库的目的在于，当用户再次或是反复读取通知消息进行后续的操作时，保证了通知消息不会出现丢失或损坏的情况，保证了通知消息的安全性和可用性。

另外，在上述实施例的基础上，作为一种优选的实施方式，通知途径具体为日志文件途径。

相应的，将通知消息通过通知途径进行反馈，具体为，将通知消息写入日志文件以进行反馈。

可以理解的是，将消息通知写入日志文件的好处在于，用户可以通过日志文件查找到应用服务器在任意时刻的通知消息，以及与通知消息有关的一系列信息。在应用服务器执行自身功能时，能够通过日志文件得知应用服务器的功能执行情况，另外，当应用服务器出现故障状态时，可以通过日志文件分析故障的原因，根据故障原因对应用服务器进行相应的故障处理或优化，进而能够进一步提高应用服务器的整体性能。

另外，在上述实施例的基础上，作为一种优选的实施方式，状态事件具体为：

应用服务器出现性能故障。

由于应用服务器的性能是用户所关注的重点，因此当应用服务器发生性能故障时，是否有消息通知以及消息通知是否快捷准确就成为了用户比较看重的方面。因此应用服务器的消息通知可以重点用于反馈应用服务器的性能状态信息。

实施例三

在上文中对于一种应用服务器的消息通知方法的实施例进行了详细的描述，本发明还提供一种应用服务器的消息通知装置，由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

图3为本发明实施例提供的一种应用服务器的消息通知装置结构图。如图3所示，本发明实施例提供的一种应用服务器的消息通知装置，包括：

设置模块10，用于设置进行消息通知的通知途径。

事件判断模块11，用于判断应用服务器运行时是否有状态事件发生，如果是则执行事件转化模块。

事件转化模块12，用于根据状态事件的内容对状态事件进行相应的转化，以得到通知消息。

反馈模块13，用于将通知消息通过通知途径进行反馈。

本发明所提供的应用服务器的消息通知装置，判断应用服务器是否在运行过程中产生了状态事件，如果有，则根据应用服务器的状态事件的内容转换成可以进行反馈通知的通知消息，进而将通知消息按照所设定的通知途径向用户进行通知。因此，本发明所提供的装置中，应用服务器能及时的将通知信息反馈给用户，使用户能够更加具体清楚的了解应用服务器的状态的情况或是功能执行的情况。可见，本装置在现有应用服务器技术的基础上进一步提高了应用服务器整体的实用性及用户的体验性。

在实施例三的基础上，作为一种优选的实施方式，该装置进一步包括：

功能启停模块，用于设置用于开启或关闭消息通知功能的配置参数。

在实施例三的基础上，作为一种优选的实施方式，该装置进一步包括：

途径列表获取模块，用于获取包括所有可选择的通知途径在内的配置列表。

在实施例三的基础上，作为一种优选的实施方式，该装置进一步包括：

数据库写入模块，用于将通知消息写入数据库。

以上对本发明所提供的一种应用服务器的消息通知方法及装置进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。