在初版POF Controller的基础上进行改进，对其架构进行了改进。

架构介绍

对于Netty接收到的消息通过消息分发机制派发到各个组件再进行处理，可以降低组件间的耦合。 # Netty线程池 Netty线程池负责跟底层交换机进行通信，其主要职责有：

Encode/Decode工作：首先编解码工作并不复杂，另外相对于另一种实现（增加编解码组件，专门负责编解码工作），直接集成在Channel中更加简单方便。
与交换机进行协议握手：对于每个交换机而言，仅与控制器完成一次握手，远小于后续业务处理的工作量，所以也可以放在Channel中。
响应EchoRequest消息：该消息是控制器与交换机之间的心跳机制，对于该消息无需进行计算，只需要简单发送EchoReply，所以也可由Channel承担。
生成Event，发送至Event Dispatcher，这也是Netty线程池最重要的作用。

关于生成的Event类型如下图所示：

Event Dispatcher

负责将收到的消息转发出去，对于不同的消息都有单独的DispatchLoop（线程）负责分发，分发方式为FIFO。

LinkEvent：发送给LinkDiscovery。
HostEvent：发送给HostDiscovery。
WorkEvent：发送给Worker。

Network

Network是一个非常核心的组件，它的可靠性是其他组件运行的前提。HostDiscovery和LinkDiscovery会修改Network，而Worker则需要Network的拓扑信息进行业务处理。由于该组件会受到多线程的读写，并且考虑到该场景读多写少，Worker业务处理速度较快（无I/O读写和数据库访问），所以使用StampedLock。StampedLock使用乐观锁+悲观锁，性能上较ReentrantReadWriteLock更高，但是编写业务逻辑时更加复杂（需要考虑到乐观锁失效的情况）。

HostDiscovery

处理HostEvent（对arp消息进行包装）。

arp请求：若Network中已有目标host，就下发arp响应；若没有，则洪泛该arp请求。
arp响应：在Network中添加发出响应的host。

LinkDiscovery

处理LinkEvent（对LLDP消息进行包装）。
对于收到的LinkEvent，检查该链路是否已经存在Network中，若不存在，则添加。并且该组件还会周期性地扫描链路，确保实时更新链路情况。

Worker

对于接收到的WorkEvent进行处理。但是这种处理过程主要分为4个部分：

对收到的消息进行过滤处理，防止收到多个相同的WorkEvent，进行多次处理。
使用乐观锁模式的Topo视图进行处理，并把相应结果转化为流表，但是暂存起来。暂存的目的主要是防止乐观锁模式失败。
检查乐观锁是否有效，有效则下发流表；若无效，则使用悲观读锁重新处理。
将WorkEvent中的数据包PacketOut，防止丢包。

另外的优化

由于控制器是以POF Message和交换机进行交互，但是不断创建POF Message显然会加重创造对象的开销和GC的频率，所以使用Netty的Recycler对象池对部分热点消息进行回收。