干货｜微服务架构下的告警管理之高并发告警同步实现方案

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文


▍作者简介

作者李晓春是虚拟化、集群技术和开源软件爱好者。致力于将虚拟化和集群技术在通信领域上的应用，同时将敏捷软件开发技术和流程的落地。
这篇文章主要讲述了在微服务软件架构中是如何实现高并发网元告警同步的总体思路，供设计开发人员参考。

▍告警同步流程

告警同步是指告警同步流程下发，可以是同步定时器触发，也可以是用户从界面触发。告警同步关键逻辑在于告警比较，需要按“多删少补”的原则进行处理，另外在多实例水平扩展场景下，需要确保单个网元告警同步操作互斥，避免告警乱序的问题。

▍告警同步微服务

专业网在实现告警同步相关功能时，可单独开发告警同步微服务，也可和告警适配处理微服务合并。无论哪种实现方式，其告警同步逻辑不变，基本上都是按照“多删少补”的原则进行处理。本文以独立微服务为例，介绍告警同步的基本流程。

[b]1.1 用例图[/b]



[b]1.2 流程图[/b]



1.3 技术点

[b]1.3.1 多退少补[/b]
告警同步是指告警同步流程下发，可以是同步定时器触发，也可以是用户从界面触发。告警同步关键逻辑在于告警比较，需要按“多删少补”的原则进行处理，主要流程描述如下。首先，获取待同步目标网元在Zenap上的全部活动告警对应的alarmkey（告警流水号、告警码、告警位置），构造LocalKeySet；其次，通过查询同步目标网元中所有活动告警的alarmkey，构造RemoteKeySet；再次，比较LocalKeySet和RemoteKeySet，对于LocalKeySet中多出的key条目，从EM系统删除对应的告警；对于LocalKeySet中缺少的key条目，暂时记录到待上载告警列表NewKeyList中；最后，针对待上载告警列表NewKeyList中的alarmkey条目，分批从目标系统同步对应的告警信息。具体实现时，需要结合接入代理系统提供的接口方法对上述流程做适当调整。



1.3.2 分布式锁

考虑到告警同步微服务设计为多实例部署，需要借助分布式锁来实现单体网元告警同步互斥操作。所谓的“分布式锁”，也就是一种能让各个节点先检查后执行的限制条件。如果我们有高效而单子操作的目录服务，那么这个锁状态实际上就是一种“单步事务”的状态记录，而回滚操作则默认是“暂停操作，稍后再试”。这种“锁”的方式，比事务的处理更简单，因此可靠性更高，所以现在越来越多的开发人员，愿意使用这种“锁”服务，而不是去实现一个“事务系统”。
告警同步事务下分布式锁，要求同一时刻，对于特定的网元，仅允许一个告警同步微服务实例，来执行告警同步操作。接下来结合项目实际情况，介绍下分布式锁应该具备的特性以及分布式锁中间件选型。
注：初期可以将告警同步微服务设计为单实例部署，这样可以简化功能实现。



1.3.2.1 分布式锁特征

结合项目实际需要，要求分布式锁具备如下特性：
1、要求每个网元都有各自一把锁。
2、锁互斥，不管任何时候，只有一个客户端能持有同一个锁。
3、锁具有自动释放特征（超时后会自动释放），确保不会死锁，最终客户端一定会得到锁，就算一个持有锁的客户端宕掉。
4、锁的时效设置。避免单点故障造成死锁，影响其他客户端获取锁。但是也要保证一旦一个客户端持锁，在客户端可用时不会被其他客户端解锁。
5、加锁的事务或者操作尽量粒度小，减少其他客户端申请锁的等待时间，提高处理效率和并发性。
6、客户端在不再需要锁或者任务执行完成之后需要主动释放锁，这样其他客户端就不用等到超时时间再去获取这个锁。
7、当一个客户端尝试获取锁时，如果这个锁被其他客户端占用，则立即返回，不做任何业务处理，此目的在于确保同一时刻只有一个客户端在执行特定网元告警同步操作即可。
8、提供分布式锁的中间件，需要具有高可靠、容灾等特性，确保分布式锁稳定性。
1.3.2.2 分布式锁选型

在很多微服务架构产品应用中，有些场景需要加锁处理，比如：全局ID递增、告警同步互斥等等。大部分的解决方案是基于数据库来实现的，这种方式业务实现比较复杂，比如需要开发人员自行实现锁超时释放机制，避免死锁问题。那么如何找到一款能够满足各种应用场景的分布式锁组件呢？

1.3.2.2.1 ZooKeeper分布式锁

ZooKeeper是一个分布式应用程序协调服务，为分布式应用提供一致性服务的组件。ZooKeeper节点结构是一个和文件系统类似的小型的树状的目录结构，同时Zookeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：在ZooKeeper的根目录下，由两个客户端同时创建一个名为/locks/ne_node，则只有一个客户端可以创建成功。因此，可以通过ZooKeeper节点为每个待告警同步的网元来创建一个锁，例如/locks/10.63.204.101就可以定义为一个锁。ZooKeeper分布式锁架构示意图如下：



另外，ZooKeeper有一种临时类型的节点，临时节点由某个客户端创建，当客户端因为宕机，与ZooKeeper集群断开连接时，则该临时节点会被自动删除，从而避免了死锁问题。
客户端在获取到锁之后，开始执行互斥业务逻辑，执行完成后，显示删除临时节点，即可释放锁。大致工作流程如下图：


1.3.2.2.2 Redis分布式锁

Redisson在基于NIO的Netty框架上，充分的利用了Redis键值数据库提供的一系列优势，在Java实用工具包中常用接口的基础上，为使用者提供了一系列具有分布式特性的常用工具类。Redisson提供了分布式锁特性，开发者可直接利用开发相关业务。
Redis分布式锁架构示意图如下：



大致工作流程如下图：



1.3.2.3 分布式锁比对

	可重入锁	持锁断开连接后释放锁	锁持久化	优缺点
ZK	支持	支持，临时节点当连接中断会删除锁	支持	安全性较高，支持锁持久化存储，但效率稍低
Redis	支持	支持，过期时间	不支持	安全性较低，不支持锁持久化存储，但效率较高

结合告警同步业务实际需要，计划采用ZK来实现分布式锁。

1.3.2.4 分布式锁总结

除了上面提到的ZooKeeper和Redis外，还有很多技术可以实现分布式锁。在思考是否采用分布式锁以及采用哪种实现方案的时候，还是要基于业务，技术方案一定是基于业务基础，服务于业务，并且衡量过投入产出比的。所以如果有成熟的解决方案，在业务可承受规模肯定是不要重复造轮子，当然还要经过严谨的选型和测试。开发者在实际开发中，可权衡利弊，选择一种最合适业务场景的分布式锁来实现相关业务。