对于网络领域的人来说，解耦已成为白盒交换机的代名词。 但是解耦的概念实际上比这更广泛并且可能对整个行业产生深远的影响。

在Juniper解耦既是许多计划背后的战略重点，又是每个架构决策的工程原理。 它既是开发路线图的明确组成部分，又是对Juniper工程团队的隐性指示。

作为开发以及如何开发的核心，解耦在 Juniper围绕云，多云，分布式和边缘云的更广泛的公司战略中起着关键作用。

什么是解耦(Disaggregation)?

尽管该术语并非特定于网络，但大多数人将解耦等同于白盒运动以及数据中心交换机的硬件软件分离。 虽然这是解耦的一个范例，但它是对范围更广战略的狭义定义，它忽略了网络中其他元素也进行解耦的真正价值。

从基本的角度看，解耦只是两个通常集成在一起的组件的分解，其目标是比整体集成的系统在更细的粒度和层次上创造选择性和灵活性. 如果用户可以集成和选择各种系统组件，那么他们就可以构建一个适合其特定目的的独特系统。

不止是成本

在今天的对话环境中，技术目的通常与成本有关系。 例如白盒推进运动主要由降低数据中心交换机成本的愿望所驱动。 但这不是解耦的唯一目标。

有些人采用解耦是为了优化性能，尤其是为了支持要求低延迟的业务. 比如高频交易领域就以试图从交易中节省每一个微秒而臭名昭著. 优化性能的另一个表现是尝试通过通用管理系统对不同硬件进行管理的运维一致性。

还有些人可能会利用解耦来优化控制. 对于提供 X即服务的公司，专门而独特的控制平面会提供独特的竞争优势，而其他也购买相同基础架构的人则无法复制。 在这种情况下，控制平面解耦后可以利用供应商系统之外的可编程接口以独特的方式精细调整自己的解决方案。

还有一些人认为解耦是为了安全性。 例如，使用私有加密算法会至关重要，特别是在军事和情报行动中. 解耦提供了不依赖于运行第三方代码的黑盒子来实施项目的安全途径。

尽管对于大多数人来说，成本无疑是重要的事情，但解耦实际上是为达成更广泛目标而采取适宜途径的一个有效方法。

不仅是软硬件

现实是耦合的任何两件事都可以解耦。 例如控制与转发的分离导致出现了专门为网络报文转发优化的芯片. 这种分离不仅仅是硬件和软件分离, 而且目标也不仅仅是降低成本.

在当今的网络设备中，软件和硬件数据平面之间有着紧密的联系。 也就是说包处理流水线与底层芯片设计紧密相关，这导致了芯片领域的垄断。 随着P4之类的标准逐渐深化，解耦可以有效地使芯片设计与包处理流程分离，从而推动ASIC芯片领域更多竞争，并在交换机和路由器的主要成本因素中创造经济杠杆。 这是Juniper与Google一起在P4上所做的工作的主要推动力。

解耦的另一个示例是将网络控制 (路由选路决策)与网络操作系统的其余部分分离。 今年早些时候， Juniper宣布支持Facebook的Open / R标准。 允许外部软件对JUNOS设备路由表进行编程，这样Juniper有效地分解了以前紧密耦合在网络操作系统内的子系统。

甚至还有人以非传统方式来利用解耦, 比如机框系统中线卡通常固定在机箱内。 Juniper在今年早些时候推出其通用机箱产品时从机箱中解耦了线卡。 因此在插入特定线卡之前，机箱不会成为MX系列或PTX系列平台。 这使管理员可以利用通用机箱来满足各种业务需求，且更换线卡即可更改其产品形态.

解耦的隐藏意义

解耦还可以对系统设计产生深远的影响。

在混合搭配不同组件以创建适合特定需求的解决方案时，通常会出现两个自然的要求：互操作性和互换性。

首先，在解耦解决方案中，各个组件必须有清晰的分工界面并可互操作才能协同工作。 为了让软件定义的转发路径从底层芯片中解耦，软件和芯片必须可互操作。 这就导致在这两个组件边界出现API。现在很火的P4转发平面编程语言就是担任该角色, 其他所有解耦实现也都需要一个类似的接口以实现互操作性。

其次，如果目标是允许用户混合搭配不同组件以针对业务目标进行优化，则各组件必须是可互换的. 也就是说管理员必须能够用组件B替换组件A. 在白盒交换机场景中，只有在网络操作系统和底层硬件都有多个选项的情况下，经济杠杆才存在。

组件的互换性还对组件分界提出了额外的要求： 它们必须是开放的。 如果API是封闭的(专有的或不可公开访问的), 则无法跨边界集成其他组件. 这将限制消费者的选择, 从而抵消了解耦带来的好处。

因此在每个组件边界处都应有一个开放的界面。 无论是管理平面和控制平面之间的NETCONF，交换机软件硬件之间的参考体系结构，还是软件和硬件数据平面之间的P4，网络将基于开放性继续发展。

分久必合

万事都是矛盾统一的, 分久必合合久必分.

IT部门不部署子系统. 他们部署必须组合在一起才能工作的诸多组件. 这意味着解耦会导致集成的需求. 集成并非是一件简单的事情, 即加载不同组件并期望它们能够正常工作.

例如在白盒系统中有象 BIOS这样的底层组件. 但即使使用功能上等效的不同BIOS组件, 系统也可能以完全不同的方式运行。在使用开放的界面, 用户自由混合搭配组件的情况下，想不执行诸如测试验证之类的基本集成任务就期望业务能够正常进行是不切实际的期.

有很多进行集成的方式。 有些企业可能愿意依靠合作伙伴来提供集成解决方案，而另一些则可能自己承担. 无论分工如何，希望利用解耦的公司都必须仔细考虑如何处理集成。

最后，尽管解耦将在多云时代改变网络世界，但关键组件的选择不太可能大量出现。 由于即使基于标准接口也会导致行为上的细微差别，更可能的结果是只有少量解决方案可能成功服务于市场。

好的工程设计

从根本上说，Juniper相信需要在每个层次上进行解耦 – 这只是好的工程. 设计具有良好定义接口的模块化系统，不仅可以在Juniper内部团队之 间，而且可以在行业内的不同创新圈子之间进行组件复用和分布式开发。

Juniper产品提供了很多例证：

• Junos OS系统的转发控制分离
• 通过 对JUNOS 的RPD 进程模块进行可编程实现网络控制
• 通过NETCONF实现网络管理
• 支持OCP硬件标准的白盒交换机
• 通过 Juniper 硬件和ONIE 标准支持第三方软件系统
• 机框和线卡分离的通用机箱设计
• 通过转发平面抽象层(AFT)支持
• 通过JET APIs实现系统层面控制(比如Open/R)
• 支持P4
• 支持Sonic

显然Juniper 对网络产品进行解耦有远大的计划并在生产环境中进行了广泛的实现. 重要的是 Juniper从一开始就坚信要创建基于解耦架构的产品。 随着商业需求的增加，与之匹配的商业模式也将随之而来. 这就是为什么Juniper在所有产品线都引入解耦，并继续将解耦视为多云时代的基石。