网络拓扑发现系统在初次完成扫描后，通常会得到一张包含交换机、路由器、主机以及它们之间物理链路连接关系的拓扑图。但真实网络不是静态的：设备上线或下线、端口状态变化、链路割接、VLAN调整都会让之前生成的图与实际网络产生偏差。如果每次都用全量扫描重新构建拓扑，不仅浪费计算资源，还会因为扫描周期过长而丢失中间状态。比较合理的做法是保存上一次的拓扑快照，在新一轮采集结束后进行差异对比，只对变化的节点和边做增量更新。下面介绍用Ruby实现这一过程的关键步骤。
增量更新的核心在于建立合适的数据模型和更新入口。Ruby的哈希表天然适合表示节点和边的集合，配合Set可以快速判断端口是否存在。接下来从数据表示、差异计算、冲突处理和事件通知几个层面展开。
一、物理拓扑图的数据建模与更新需求
物理拓扑图通常用无向图或双向有向图来表示。节点对应网络设备，边的两个端点分别关联到设备上的物理端口。与纯数学图不同，拓扑发现中的边必须记录端口信息，因为同一对设备之间可能存在多条并行链路，如果只存储设备ID就会丢失关键细节。例如一台核心交换机通过两个不同端口分别连接同一台接入交换机，这在图结构上需要两条不同的边。
在Ruby中，可以用三个哈希表分别维护节点、边和端口索引。节点哈希的键是设备唯一标识，值包含端口集合和元数据；边哈希的键可以用数组表示，比如[src_id, src_port, dst_id, dst_port]，这样的键既唯一又能快速反查端口。Ruby的Set适合保存每个设备上的活跃端口，插入和删除的平均复杂度都是O(1)。下面给出一个基础拓扑类的实现。
require 'set'
class Topology
attr_reader :nodes, :edges
def initialize
@nodes = {}
@edges = {}
end
def add_node(id, metadata = {})
@nodes[id] ||= { id: id, ports: Set.new, metadata: metadata }
end
def add_edge(src_id, src_port, dst_id, dst_port)
add_node(src_id)
add_node(dst_id)
edge_key = [src_id, src_port, dst_id, dst_port]
@edges[edge_key] = {
src: src_id,
src_port: src_port,
dst: dst_id,
dst_port: dst_port
}
@nodes[src_id][:ports] << src_port
@nodes[dst_id][:ports] << dst_port
edge_key
end
end
上面的结构可以直接满足基本存储需求，但更新算法更关心的是如何高效地让旧拓扑迁移到新拓扑。这里需要一个明确的概念：快照。一次完整的拓扑采集会生成一份快照，它包含当前发现到的所有节点和所有边。更新算法的任务就是比较旧快照和新快照，找出新增、删除和修改的集合。
需要注意的是，物理拓扑图中的边通常没有方向，但为了保留端口对应关系，存储时可以采用有序数组。当判断两条边是否相同时，必须同时比较源端口和目的端口。如果只比较设备而忽略端口，就可能在多链路场景下错误地合并连接。
二、增量更新算法：快照对比与差异合并
全量更新会清空旧图再重新填充，增量更新则只处理差异。差异计算的第一步是对节点ID集合做差集运算。Ruby数组的差集操作old_nodes.keys - new_nodes.keys可以直接得到被删除的节点，反向差集则得到新增节点。边的情况稍微复杂一些，因为边键是一个数组，需要确保哈希键的等价性。Ruby中数组作为哈希键时，只要元素内容和顺序一致，就会视为同一个键，这很适合我们的四元组表示。
在实现更新方法时，删除操作要先于添加操作执行。这样做的原因是设备可能同时发生删除和新增，如果先添加新节点再删除旧节点，可能会导致临时状态中存在同名节点冲突。对于删除边，不仅要移除边记录，还要从对应节点的端口集合中移除端口；对于新增边，需要先确认节点存在，再添加边并更新端口集合。
def update_topology(new_snapshot)
new_nodes = new_snapshot[:nodes]
new_edges = new_snapshot[:edges]
added_nodes = new_nodes.keys - @nodes.keys
removed_nodes = @nodes.keys - new_nodes.keys
added_edges = new_edges.keys - @edges.keys
removed_edges = @edges.keys - new_edges.keys
removed_edges.each do |key|
src, src_port, dst, dst_port = key
@nodes[src][:ports].delete(src_port) if @nodes[src]
@nodes[dst][:ports].delete(dst_port) if @nodes[dst]
@edges.delete(key)
end
added_edges.each do |key|
src, src_port, dst, dst_port = key
add_node(src)
add_node(dst)
@edges[key] = new_edges[key]
@nodes[src][:ports] << src_port
@nodes[dst][:ports] << dst_port
end
removed_nodes.each { |id| @nodes.delete(id) }
added_nodes.each { |id| add_node(id, new_nodes[id][:metadata]) }
{
added_nodes: added_nodes,
removed_nodes: removed_nodes,
added_edges: added_edges,
removed_edges: removed_edges
}
end
这段代码的核心优势在于时间复杂度。假设旧拓扑中有N个节点和M条边，新快照中节点数接近N，边数接近M，那么差集操作和遍历删除、添加操作的总复杂度约为O(N+M)，远低于全量重建的O(N+M)加上重新扫描所有设备的开销。在实际网络中，节点和边的变更比例通常很低，因此增量更新的实际耗时非常小。
不过，这种简单差集只能处理新增和删除，无法自动处理边属性变化。比如同一条链路两端的端口没有变，但链路状态从转发变为阻塞，或者端口速率发生了改变。对于这类情况，需要额外比较边属性。可以先找出同时存在于新旧边键集合中的边，再逐条比较属性是否一致，若不一致则执行更新操作。
三、端口匹配与链路冲突处理
物理拓扑发现通常依赖LLDP或CDP等邻居发现协议，这些协议在设备上会报告对端设备的标识和端口。由于不同厂商对协议实现有差异，有时会出现同一物理链路两端报告不一致的情况。例如交换机A的端口Gi0/1报告对端是交换机B的Gi0/2，而交换机B的端口Gi0/2报告对端是交换机A的Gi0/5。这种端口信息不匹配会造成拓扑中出现两条单向链路，而不是一条双向链路。
更新算法必须识别并纠正这类冲突。一个有效的策略是维护链路索引，按设备对和端口对进行归一化。把一条边的两个端点按照设备ID排序，端口则跟随各自设备排序，这样无论采集顺序如何，同一条物理链路都能映射到同一个键。比如把[B, 'Gi0/2', A, 'Gi0/5']归一化为[A, 'Gi0/5', B, 'Gi0/2']。归一化后，新增边时先检查反向边是否已经存在，如果存在则合并为一条双向链路，并补充缺失的端口信息。
def normalize_edge(src_id, src_port, dst_id, dst_port)
if src_id > dst_id
[dst_id, dst_port, src_id, src_port]
else
[src_id, src_port, dst_id, dst_port]
end
end
def detect_conflict(new_edge)
src, src_port, dst, dst_port = new_edge
reverse_key = normalize_edge(dst, dst_port, src, src_port)
if @edges.key?(reverse_key)
old_edge = @edges[reverse_key]
old_edge[:updated_at] = Time.now
old_edge
else
nil
end
end
这里的normalize_edge只按设备ID排序，实际生产环境还需要考虑设备名称大小写、数字排序规则等。冲突处理时还可以引入时间戳字段，当两条来源不同的更新针对同一条边时，时间戳较新的数据覆盖较旧的数据。时间戳可以由采集器写入，也可以使用拓扑服务器本地时间。需要注意的是，分布式环境下各采集器的时钟可能不同步，用Ruby生成统一时间戳会更可靠。
另一个常见冲突是同一端口同时出现在两条边中。这通常意味着采集数据有误或网络中存在非法的端口镜像。更新算法可以在添加边之前检查端口占用情况，如果端口已经被其他边使用且不是反向边，就触发告警或进入人工确认流程。这种检查可以在add_edge方法中加入，避免污染拓扑图。
四、事件驱动更新与性能优化
增量更新算法落地后，往往需要通知上层应用拓扑发生了变化。直接用轮询方式让上层定时读取整个拓扑数据不够优雅，比较好的做法是在Topology类中嵌入回调机制。Ruby标准库没有内建的事件监听器，但实现一个简单的观察者模式并不复杂。可以维护一个监听器数组，在更新方法执行完差异合并后，依次调用每个监听器的回调，并把新增、删除、修改的集合作为参数传递。
def add_listener(listener)
@listeners ||= []
@listeners << listener
end
def notify_listeners(changes)
(@listeners || []).each do |listener|
listener.call(changes)
end
end
def update_topology_with_events(new_snapshot)
changes = update_topology(new_snapshot)
notify_listeners(changes)
changes
end
这种设计让拓扑更新过程和上层响应解耦。上层可以订阅拓扑变化事件，自动刷新可视化界面、更新告警系统或触发路径重新计算。回调方法要保证幂等，因为网络抖动可能导致短时间内多次触发同一变化。可以在回调内部做去重处理，比如根据边键和事件类型判断最近是否已经处理过。
性能方面，除了前面提到的差集优化，还可以在快照生成阶段就做数据清洗。例如采集器可以把接口索引转换为统一命名，过滤掉只出现在管理VLAN中的端口，减少拓扑图里的噪声节点。Ruby的Set在判断端口是否存在时比数组包含检查快很多，因此节点中的ports字段应该坚持使用Set。对于节点数超过一万的大规模网络，内存占用会成为瓶颈，此时可以考虑把部分元数据外置到数据库，只在内存中保留节点ID、端口和边的关键信息。
另外，更新算法的原子性也很重要。如果更新过程中发生异常，拓扑对象可能处于半新半旧的状态。可以在update_topology开头复制一份当前哈希，或者把所有变更记录到临时结构，等全部计算完成后再一次性替换。Ruby的dup只能做浅拷贝，对于嵌套结构需要手动处理。更好的方式是用不可变快照对象，每次更新生成新对象，旧对象保持不变，这样天然支持回滚和并发读取。
综合来看，用Ruby实现物理拓扑图更新算法并不需要复杂框架，核心在于合理利用哈希、集合和数组差集，配合清晰的差异合并顺序。把端口信息纳入边键设计、归一化处理反向冲突、事件回调通知上层，这些细节决定了拓扑发现系统在动态网络环境中的稳定性和可维护性。