《云数据中心网络与SDN：技术架构与实现》——2.5.2　模块间通信

2.5.2　模块间通信

有了动态管理模块的框架，SDN控制器接下来面临的一个问题就是如何在模块间进行通信。这里所说的模块间通信，是指发生在控制器内部的模块间通信，该机制设计的优劣会直接影响控制器的可扩展性，甚至影响到控制器核心部分的稳定性。实际上，OSGi的大部分实现中已经提供了模块间的通信机制，不过很多控制器也会自己重写通信机制来优化模块间的通信。

模块间的通信是一个非常复杂的话题，涉及控制器代码实现的方方面面，从通信模式的角度来看，可以分为点对点模式和发布订阅模式。在点对点模式中，源想要和目的通信直接调用模块的目标接口，这种方式实现起来最为简单，代价是增加了模块间的耦合度，一来出了问题容易导致连锁反应，二来模块多了之后接口后期维护的成本也越来越高。在发布订阅模式中，模块间的通信不再直接发生源和目的之间，而是在中间加了一个组件，由这个组件作为中继来协调各个模块间的通信，这样可以获得模块解耦带来的各种好处，而且通信方式更为丰富，中间的组件通过应用级别的路由可以实现点对多点的通信。

点对点虽然听起来没有发布订阅高级，但是从工程的角度来看点对点不受中间组件的约束，它的实现可以更灵活一些。发布订阅虽然提供了解耦合，但是中间组件的引入必然会带来通信效率上的开销，而且这个中间组件本身要足够稳定、强劲，否则它出了问题整个控制器就彻底崩溃了。因此，对于一个好的控制器的设计，两种通信模式都是需要提供出来的，供开发者自己来选择。

回头再来看发布订阅模式下那个中间的组件。它的实现通常是一个消息队列，发布消息的称为生产者，订阅消息的称为消费者。生产者产生了消息后直接把消息投放到消息队列，然后消息队列根据该消息的类型将其推送给相应的消费者，或者由消费者从特定的队列中轮询获得消息。消息队列可以看作一个投递信件的邮差，它对通信的内容实际上是没有任何感知的。除了消息队列以外，中间组件的另一种实现是以数据库为中心的，生产者把它所产生的数据写到数据库中，对这个数据感兴趣的消费者就可以从数据库中读到变化后的数据，或者由数据库将变化后的数据推送给订阅了该数据的消费者。数据库可以看作一个传话的信使，它对通信的内容是可以感知的。

基于消息队列来做发布订阅好，还是基于数据库还做发布订阅好？不同的业务有不同的考虑，而后一种通常来说会更好一些。假设控制器上现在有两个模块，一个是设备的驱动，一个是探测网络拓扑变化的，后一个的工作是要依赖于前一个的。有一个极端点的例子，是一个破坏者反复地插拔着设备上的网线，这个端口的状态就会不断地在通和断两个状态间发生变化。设备的驱动把这个破坏者的行为如实地记录了下来，然后它要通过一种把这些行为发布给拓扑模块。如果是基于消息队列的，那么拓扑模块有可能在收到大量消息的冲击后就挂掉了，但是这个破坏者仍然在不停地插拔网线，那么消息队列只能如实地把消息缓存下来，等拓扑模块恢复后再把消息一起推送给出去，于是拓扑模块就再次挂掉了。如果是基于数据库的，那么拓扑模块恢复后数据库只把当前端口的状态发给拓扑模块即可，防止对拓扑模块的二次冲击。如果状态变化实在过于频繁，还可以将其识别为安全隐患，从而无论实际端口状态如何变化，对于订阅者可以直接将其置位为Down，防止拓扑频繁变化对路由稳定性的影响。本质上，数据库带来的好处是由于它维护了通信上层内容的状态，而消息队列对于通信上层的内容是无状态的。不过，维护状态所带来的开销可能是非常巨大的，对于一个好的控制器的设计，发布订阅的方式也都是需要提供出来的，供开发者自己来选择。

观点听起来比较中庸。其实这主要取决于对控制器的定位，如果是要作为一个通用的平台，就需要给开发者最大的灵活性，那么把底层各种机制都提供出来是要更好一些的。如果是要做一个产品，解决特定的问题，那么就选一个最合适的吧。