ONOS太笨重：有90万行代码，扩展难，该分解了

软件定义网络（SDN）已经改变了网络界格局，但在这个过程中也带来了自身的问题。美国普渡大学的Doug Comer认为，对诸如开源网络操作系统（ONOS）之类的SDN控制器进行分解也许不失为一条出路。

Comer经历了激动人心的互联网早期阶段，是互联网架构委员会的成员，写过探讨网络的多本著作（数量之多堪称小型图书馆），还开发了Xinu嵌入式操作系统。

他担心，SDN可能会因变得过于笨重而无法扩展，这就是为什么他的大名出现在了预印本平台arXiv上的这篇论文（https://arxiv.org/pdf/1901.02585.pdf）上，论文合著者是他在普渡大学计算机科学系的博士生Adib Rastegarnia。

该论文题为《对软件定义网络中的数据包处理进行外部化》，提议正如当初SDN对专有网络界进行分解那样对SDN进行分解。

而在硬件领域，这意味着拿来曾经在专用的专有设备中共存的功能，转变成可以在通用计算机上运行的软件。

然而SDN中存在一个问题：控制器本身已经变成了拥有大批贡献者的庞大项目，这使控制器成为了要处理其环境中每路数据流的瓶颈。

Comer称，ONOS含有“远超100项”功能，太过繁琐而笨重。在问世后的四年多时间里，ONOS已吸引了近14000次代码提交，拥有近90万行代码，这不是你轻松就能实时重新编译的系统。

他和Rastegarnia提出的方案的基本思想是，其中一些功能应该从控制器分解出来。

架构

论文着重介绍的SDN架构特点包括：

整体式控制器不是模块化的，无法在不引起干扰的情况下进行更新，可能无法扩展以适应未来的兆兆位网络；

SDN中充分利用REST协议（RESTful）的北向API标准化程度很低，依赖单单一个控制器；

面对不同的控制器，软件模块不容易重复使用。

今天的控制器采用了一种主动式方法，程序员要在其创建的数据流规则中涵盖所有可能出现的情况。（论文认为，分解法将让程序员得以开发能够更好地响应变化的被动式管理应用程序。）

Comer称，想法很简单：不是把所有功能都放在ONOS中，让ONOS做它擅长的事情，但是将功能与控制器分离开来，“而不是将所有功能都放在里面、编译一个无比庞大的映像。”

Comer表示，分解软件时，“我们要做的就是将诸如创建路由或防火墙设置之类的服务移到控制器软件本身外面。”

为什么这么做？他解释道，因此这样一来，分解式方法让人们更容易将功能移到数据流所需的地方，而不是将数据包路由到某功能，处理数据包，然后将数据包发回到网络上。

不可否认，这种方法存在诸多风险，最主要的风险就是效率问题：与如今的SDN环境相比，处理和需要移动的消息数量方面都会带来额外的开销。

Comer 说：“每当你说分散式系统，有人会说‘效率低下’，确实如此。它需要多大的开销？有没有一项技术能做到这一点？”

借鉴Kafka

正如论文所述，Comer和Rastegarnia选定了Apache Kafka消息传递环境。

他们决定实施消息路由作为控制器中的一个组件：它接收所有消息，决定哪些消息需要转发、转发到哪些功能以及如何最有效地传递消息。

Comer/Rastegarnia分解架构

消息传递架构是Comer /Rastegarnia论文的核心。

在SDN控制器中，Kafka消息分发应用程序将入站数据包的副本提供给外部进程。它侦听入站数据包，并在集群上发布，外部管理应用程序和进程可以访问这些数据包；

应用程序和服务使用HTTP请求来订阅Kafka消息分发应用程序。

就目前而言，Comer表示，有必要记住arXiv上的这篇论文代表非常初步性的工作：它带来的问题比解答的问题还多，而消息传递是最重要的问题之一。

然而，他认为该论文展示了分解方法的一个核心特点：控制器的角色简化为处理诸如数据流设置、路由创建和转发规则之类的任务。他称：“如果你走那条路，我认为我们已经证明这条路是可行的。”

比如说，分解意味着，在10Gbps网络中，如果非核心网络功能转变成微服务，就不再需要推送每个数据包或每路数据流通过控制器来传输。

他说：“如果我愿意的话，可以将Docker容器放在任何地方并移动它。我可以将容器移到当前最合适的地方。”

“因此，不是将流量路由传输到网络功能在运行的物理服务器，而是将功能移到更靠近数据流的地方。”比如说，可以复制防火墙之类的系统，以便可以为网络中的每个网络点启动一个防火墙。

论文全文：