SNMP多业务线数据接收模型的架构演化

 

最初网管服务器（NMS）只接收来自固定的一个SNMP Agent的设备数据包，方式为Trap定时上送。

 

一、初始架构

 

架构如下：

 

 

此时，单一业务，独享数据接收队列，解析器订阅接收队列，收到新数据包后会通知解析器处理（推模式）。

 

二、业务线增加

 

随着时间推移，需求有变，业务线增加，业务一变多，本着能利旧则利旧的原则，继续沿用初始架构，如下：

 

 

此时新增的业务线与最初的业务共用数据接收队列，问题开始出现：

1、各业务线数据量不同，有的数据上送频繁，如机器CPU使用率，有的数据上送频率低，如设备告警。多业务线共用一个队列会导致数据耦合。

2、某个业务线SNMP Agent产生故障，导致写入数据接收队列线程卡死，影响了其他业务线正常的SNMP Agent的写入。

3、后续继续增加业务线，单一队列逐渐成为瓶颈。

 

三、按业务垂直切分

 

针对以上问题，既有架构已不能满足实际业务运行及扩展需要，为此需及时调整架构，数据处理按业务垂直切分，解决以上问题，新架构如下：

 

 

架构调整后各个业务独占一个接收队列，业务线之间的数据接收及处理互不干扰。

 

 四、架构调优：推改拉+限流

 

实际运行中发现，有的业务线数据量瞬时过大，Trap短时间推送数据过快，导致NMS处理出现瓶颈，甚至压垮NMS，此时该如何解决？

1、解析器从订阅接收队列的推模式改为拉模式。

2、限制接收队列处理速度，从原来一条条处理改为批量处理，处理完一批再继续从队列取下一批处理，如此保证程序按照自身处理能力处理数据。

 

架构调整如下：

 

 

 

五、架构演化

 

最终架构演化如下：

 

 

六、总结

 

架构演化是为了适应业务变化，解决当下存在的问题及未来的扩展性问题，本文针对业务线不断增加，数据量增大采取了如下措施：

 

1、多业务数据耦合调整为按业务垂直切分解耦。

2、数据推模式改为拉模式限流。