ncclient 项目结构

CC在最近的项目中需要通过netconf操作网络设备。由于这个项目主要使用go进行开发,而网络上go的netconf库只有Juniper的一个简单的项目,对于CC要访问的华为的设备支持不是很好,因此CC借鉴了

ncclient [1]

这个Python的库进行参考,写了一个go的netconf库。

这篇文章主要用于记录一下ncclient的项目结构。

目录结构

整个项目的目录结构比较传统,具体结构如下:

目录结构
目录结构

整体架构

主要对象间关系图:

主要对象间关系图
主要对象间关系图

CC个人觉得这里的整体架构有些问题,注意这里CC用红色标记的部分。RPC会负责生成具体命令的netconf报文,然后基于session进行命令的下发,因此RPC依赖于Session。部分品牌的设备有特定的netconf命令,因此会有特定的RPC子类负责生成相关报文,因此DeviceHandler会感知到RPC层的存在。Session层根据设备的不同,会需要不同的连接参数,因此Session需要感知到DeviceHandler的存在,由后者提供不同设备的连接参数。因此RPC、Session、DeviceHandler在这里三者的依赖成环了,并不是很明确的层级关系。当然如果认为这三者属于同一层的话并没啥问题。

这里之所以层环了,主要的原因是对于不同的设备,其通信时的参数存在不同,同时支持的netconf命令也不同。如果要把环断掉的话,一种方式是对RPC和Session参数等不同的地方,都分别建一个设备的XXXHandler,例如HuaWeiSessionHandler和HuaWeiRPCHandler等,这样环状的依赖关系是消失了,不过对于一个设备来说代码如果组织的不好就会分散在多个文件中增加维护的复杂度。

下面CC就来试试有哪些方法可以处理这个问题。

分散的Handler

分散的Handler就是上面CC提到的,对每一个不同的地方提供独立的XXXHandler。对象关系如下:

分散的Handler
分散的Handler

DeviceHandler的多重继承

由于不同厂商的设备其实会意识到Session和RPC的存在,因此可以以设备为主,由其负责协调Session、RPC之类的操作。DeviceHandler可以通过多重继承继承Session与RPC,并在其基础上提供设备特定的信息。对象关系如下:

多重继承
多重继承

其它

ncclient的代码中有一部分是关于协议版本的,有1.0和1.1两个版本,在参照着写其它语言的版本的时候这块代码需要注意一下,否则可能设备对请求的响应会存在问题。

[1] https://github.com/ncclient/ncclient
本文微信分享二维码


本文由60 X 60整理编写。
如需转载请注明出处并保留文章所有引用的资料来源。
欢迎关注 本心小晴 微博[微博搜索 本心小晴 或扫描下方二维码]。