[0024] 为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。基于本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。
[0025] 请参阅图1，本申请实施方式提供一种基于事件驱动的云AC告警处理系统，所述系统包括根角色1、告警事件接收角色2、告警事件推送角色3、告警事件处理角色4以及告警信息通知角色5。
[0026] 在本实施方式中，所述根角色1可以用于创建所述告警事件接收角色2、告警事件推送角色3、告警事件处理角色4以及告警信息通知角色5，并监测创建的各个角色的运行状态。
[0027] 所述告警事件接收角色2可以用于从云AC设备模块中获取告警事件，并按照获取时间将告警事件排列于预设队列中。
[0028] 所述告警事件推送角色3可以用于将所述预设队列中的目标告警事件推送至关注所述目标告警事件的告警事件处理角色处。
[0029] 所述告警事件处理角色4可以用于接收并处理所述告警事件推送角色推送来的目标告警事件，并在处理完毕之后生成告警信息。
[0030] 所述告警信息通知角色5可以用于接收所述告警事件处理角色发来的告警信息，并将所述告警信息发送至运维人员处。
[0031] 在本实施方式中，可以采用Akka分布式应用框架来实现告警处理的事件驱动模型。Akka是一个用Scala编写的库，可以用于简化编写容错的、高可伸缩性的Java和Scala角色模型应用。Akka的主要目的是编写应用程序，使应用程序能更简单地部署在云上或运行在分布式环境中，并能有效的利用全部计算机资源进行业务处理。
[0032] 具体地，在事件驱动模式下，一个告警处理可以由一系列独立的业务组件组成，这些业务组件可以称为角色(Actor)。这些角色通过事件来驱动自身的动作。在一个角色接收一个事件后，该角色便可以对该事件开始进行处理。在处理时，这个事件完全的属于这个角色，其它角色无法对这个事件进行修改，从而解决了并发编程中数据共享和加锁的问题，进而降低了系统的复杂性。处理完成之后，角色不需要返回结果，而是继续触发另一个事件。在本实施方式中，事件可以被编码成信息存放在预设队列里，预设队列可以由关注事件的多个角色监听。在本实施方式中，各个角色不需要通过轮询的方式获取事件，事件会自动推送给相应的角色。减少了轮询的过程，从而可以进一步减少系统的资源消耗，并实现各个角色之间的松耦合。
[0033] 在本实施方式中，角色在处理事件时，可以通过单线程的方式处理，也可以通过并发多线程的方式进行处理。例如在处理告警信息时，可以通过两个线程在同一时间分别执行获取AP设备所属网络的信息以及判断告警信息是否造成故障这两个流程。这样便可以加快系统的响应速度。
[0034] 在本实施方式中，只要事件可以在分布式的计算机间进行消息传递，角色就可以部署在任意一台计算机中。实现相同功能的角色也可以同时在多台计算机上部署，通过负载均衡策略，可以把事件发送到满足预设资源条件的计算机中进行处理。由于是基于事件驱动的，分布式环境下各个角色的增加和删除不会增加系统的复杂性。例如可以把告警信息通知角色5放在另一台计算机上，它的数量的增加和删除均不影响其它角色的处理过程。
[0035] 在申请一个实施方式中，各个角色中均可以包括状态模块、行为模块、信箱、子角色模块以及监管策略，其中，各个角色之间可以通过各自的信箱进行消息的收发。具体地，状态模块、行为模块、信箱、子角色模块以及监管策略都可以封装在一个角色引用中，重启一个角色时可以不需要更新角色引用。各个角色的任务是处理来自其他角色(或者角色系统之外的设备)发来的消息。连通消息发送者和接收者之间的就是各个角色的信箱。由于角色是相互独立的，因此通过消息进行数据交换就可以非常容易地实现并行处理。通常，角色也是非常小的模块，1G的内存可以部署250万个角色。
[0036] 在本实施方式中，各个角色在处理事件时，可以使用内存中的信息状态。具体地，各个角色中的信息状态均可被写入系统日志中，当系统重启时，各个角色可以读取系统日志，从而恢复至系统重启之前的状态。
[0037] 在本实施方式中，事件可以被异步地发送，如果事件在一个角色处理中发生异常，并不会对其它的角色的稳定性产生影响。
[0038] 在本实施方式中，请参阅图1，所述系统还可以包括AP设备查询角色6，所述AP设备查询角色6可以用于根据各个告警事件中的设备标识，从数据库中查询与所述设备标识相适配的AP设备详细信息，并将查询的AP设备详细信息添加至对应的告警事件中。具体地，AP设备详细信息可以包括AP设备启停时间、工作时长、当前工作状态等信息。在本实施方式中，每个AP设备都有一个独立的对象角色，所有属于这个AP设备的告警消息都可以发送到这个对象角色中，从而可以保证告警处理的顺序性。
[0039] 在本实施方式中，所述告警信息处理角色中可以包括故障判断子角色和所属网络判断子角色，这两个子角色可以通过并发的线程同时处理告警信息。具体地，所述故障判断子角色可以根据告警事件的类型、AP设备的工作时间以及告警事件是否屏蔽，判断当前的告警事件是否造成故障。所述所属网络判断子角色可以从Future接口处获取AP设备所属的网络信息。
[0040] 在本实施方式中，所述告警事件推送角色中还可以包括负载均衡子角色，所述负载均衡子角色用于在关注所述目标告警事件的告警事件处理角色的数量为至少两个时，根据各个告警事件处理角色对应的计算机资源，确定出计算机资源符合预设条件的目标告警事件处理角色，并将所述目标告警事件推送至所述目标告警事件处理角色处。
[0041] 具体地，所述计算机资源符合预设条件可以包括以下至少一种：计算机的剩余CPU资源大于或者等于预设CPU资源阈值；计算机的剩余内存资源大于或者等于预设内存资源阈值；或者计算机的剩余磁盘资源大于或者等于预设磁盘资源阈值。
[0042] 请参阅图2，本申请实施方式还提供一种基于事件驱动的云AC告警处理方法，所述方法包括：
[0043] S1：通过根角色预先创建告警事件接收角色、告警事件推送角色、告警事件处理角色以及告警信息通知角色，并通过所述根角色监测创建的各个角色的运行状态；
[0044] S2：所述告警事件接收角色从云AC设备模块中获取告警事件，并按照获取时间将告警事件排列于预设队列中；
[0045] S3：所述告警事件推送角色将所述预设队列中的目标告警事件推送至关注所述目标告警事件的告警事件处理角色处；
[0046] S4：所述告警事件处理角色接收并处理所述告警事件推送角色推送来的目标告警事件，并在处理完毕之后生成告警信息；
[0047] S5：所述告警信息通知角色接收所述告警事件处理角色发来的告警信息，并将所述告警信息发送至运维人员处。
[0048] 在本申请一个实施方式中，所述方法还包括：
[0049] 所述根角色预先创建AP设备查询角色；
[0050] 所述AP设备查询角色根据各个告警事件中的设备标识，从数据库中查询与所述设备标识相适配的AP设备详细信息，并将查询的AP设备详细信息添加至对应的告警事件中。
[0051] 在本申请一个实施方式中，所述告警事件推送角色将所述预设队列中的目标告警事件推送至关注所述目标告警事件的告警事件处理角色处包括：
[0052] 当关注所述目标告警事件的告警事件处理角色的数量为至少两个时，所述告警事件推送角色根据各个告警事件处理角色对应的计算机资源，确定出计算机资源符合预设条件的目标告警事件处理角色，并将所述目标告警事件推送至所述目标告警事件处理角色处。
[0053] 由上可见，本申请与现有技术相比，至少具备以下有益效果：
[0054] 1、通过把告警处理的过程拆分成多个角色，角色之间通过消息而不是共享数据进行告警信息处理，从而避免了数据共享和加锁的过程，进而减少了系统在分布式环境下使用的复杂度。
[0055] 2、通过事件触发机制，实现系统中各个角色之间的松耦合，提高了系统的稳定性和可维护性。
[0056] 3、告警处理时可以通过多个子角色并发处理多个子任务，从而可以提高系统的响应速度。
[0057] 本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。
[0058] 最后应说明的是：上面对本发明的各种实施方式的描述以描述的目的提供给本领域技术人员。其不旨在是穷举的、或者不旨在将本发明限制于单个公开的实施方式。如上所述，本发明的各种替代和变化对于上述技术所属领域技术人员而言将是显而易见的。因此，虽然已经具体讨论了一些另选的实施方式，但是其它实施方式将是显而易见的，或者本领域技术人员相对容易得出。本发明旨在包括在此已经讨论过的本发明的所有替代、修改、和变化，以及落在上述申请的精神和范围内的其它实施方式。
