在过去的 50 年里，我们在互联网的发展方面取得了很大的进步，从少量计算机相互连接的微小网络，发展成为拥有数十亿节点的全球网络。在这个过程中，我们学到了很多关于如何构建网络以及连接它们的路由器相关知识，同时所犯的每一个错误也都为后来学习它们的人提供了重要的经验教训。
起初，路由器就像一台带有多个网卡(NIC)的简单计算机。
这在一定程度上是可行的。在这种架构中，数据包进入网卡，并由 CPU 从网卡传输到内存中。 CPU做出转发决定，然后将数据包推送到出站网卡。CPU和内存是集中的资源，受它们所能支持的内容约束。总线则有一个额外的限制：总线的带宽必须能够同时支持所有网卡的带宽。
一旦想扩大规模，问题很快就会显现出来。我们可以购买更快的 CPU，但总线如何扩展呢?如果把总线速度加倍，那么你必须把每个网卡和CPU卡上的总线接口速度加倍。这样单个网卡的性能可能并没有提高多少，但是价格却变得十分昂贵。
1)：路由器的成本应该与容量呈线性增长。
想要扩大规模，权宜之计只有添加另外的总线和处理器:
算术逻辑单元 (ALU) 是一个数字信号处理 (DSP) 芯片，选择它是因为其卓越的性价比。附加的总线增加了带宽，但架构仍然无法扩展。换句话说，想要通过继续添加更多 ALU 和更多总线来获得更高的性能是行不通的。
由于ALU仍然是一个重大限制，下一步是在架构中添加一个FPGA来卸载最长前缀匹配(LPM)查找的工作量。
图 3 — 下一步是添加FPGA
这样做虽然能够起到一些作用，但是作用十分有限，ALU仍然饱和。LPM占工作负载的很一大部分，但是如果去掉这部分问题，集中式架构仍然无法扩展。
2)：LPM 可以在定制芯片中实现，并且不会成为性能障碍。
下一步是走向另一个方向：用通用处理器替换 ALU 和 FPGA。尝试通过添加更多 CPU 和更多总线来扩展。这需要大量的投入，且只能获得十分微小的增量增益，并且仍然受到集中总线带宽的限制。
在互联网发展的这个阶段，更大的力量开始发挥作用。随着网络的普及，互联网的巨大潜力愈发凸显。电信公司收购了NSFnet区域网络并开始部署商业骨干网。专用集成电路 (ASIC) 成为可靠的技术，允许更多的功能直接在芯片上实现。对路由器需求的飙升，对可扩展性大幅改进的需求最终压倒了原本的保守主义。为了满足这一需求，许多初创公司涌现出来，提供了各种潜在的解决方案。
首先出场的是crossbar：
图 4 — 随着对路由器的需求猛增，一种替代方案是crossbar
在这种架构中，每个网卡都是一个输入和一个输出。网卡上的处理器做出转发决定，选择输出网卡并向crossbar发送调度请求。调度器接收来自网卡的所有请求，尝试找出最佳解决方案，对crossbar进行编程，并提示输入进行传输。
这样做的问题是每个输出一次只能侦听一个输入，并且互联网流量是突发的。如果两个数据包需要去同一个输出，其中一个必须等待。如果必须等待的数据包导致同一输入上的其他数据包也在等待，那么系统将遭受线路阻塞 (HOLB)，从而导致路由器性能变得非常差。
3)：即使在压力条件下，路由器的内部结构也需要无阻塞。
另一种方法是将网卡排列在一个环面上:
这样，每个网卡都与四个相邻网卡相连，输入网卡必须计算出穿过架构的路径才能到达输出线卡。这里存在一个问题——带宽不统一。南北方向的带宽大于东西方向的带宽。如果输入流量模式需要东西向，就会出现阻塞。
4)：路由器的内部结构必须具有统一的带宽分布，因为我们无法预测流量的分布。
一种方法是创建网卡到网卡链接的全网状网络。
尽管吸取了以前的教训，但新的问题还是暴露了出来。在这种架构中，一切看起来都运行得很好，直到有人需要更换卡进行维修。由于每个网卡都保存了系统中所有数据包单元，当一张卡被拔出时，所有数据包都无法被重建，从而会导致中断。
5)：路由器不能有单点故障。
所有数据包都流入中央存储器，然后到输出网卡。这种方式很好，但扩展内存是一个挑战。用户可以添加多个内存控制器和内存条，但在某些时候，聚合带宽实在是太大了，无法进行物理设计。碰到实际的物理极限迫使我们往其他方向思考。
电话网络提供了灵感。Charles Clos很久以前就意识到可以通过构建较小交换机的网络来构建可扩展的交换机。事实证明，我们需要的就是Clos网络：
Clos 网络：
- 可以很好地扩展容量。
- 没有单点故障。
- 支持足够的冗余，具有抵御故障的能力。
- 通过在整个架构上分配负载来处理突发拥塞。
同时实现输入和输出促进了折叠式 Clos 网络的诞生，这就是我们今天在集群路由器中使用的网络。
不过这种架构也不是没有问题的。随之而来的芯片锁定问题使得硬件升级更具挑战性，新的cell交换机必须同时支持传统链路和格式以实现互操作以及链路升级。
每个cell必须有一个地址，表明它应该流向的输出网卡。这种寻址必然是有限的，从而导致可扩展性的上限。到目前为止，集群的控制和管理完全是私有的，为软件堆栈带来了另一个供应商锁定的问题。
不过我们可以通过改变架构来解决这些问题。在过去的 50 年里，我们一直在努力纵向扩展路由器的规模。我们从构建大型云的经验中学到的是，横向扩展的理念往往更成功。
在横向扩展架构中，与其尝试构建一个巨大的、速度极快的单个服务器，分而治之可能更为合适。装满小型服务器的机架可以完成同样的工作，同时也更具弹性、灵活性和经济性。
当应用到路由器时，思路是相似的。我们是否可以使用一些较小的路由器，并将它们安排在Clos拓扑中，这样我们就有了类似的架构优势，但又避免了上述问题?事实证明确实是这样:
通过使用分组交换机(例如路由器)替换单元交换机并保留 Clos 拓扑，就可以确保其可扩展性。
我们可以在两个维度上进行扩展：通过添加更多的入口路由器和分组交换机与现有层并行，或者增加额外的交换机层。由于现在各个路由器都相对通用，因此避免了供应商锁定。链路都是标准以太网，互操作性上也没有问题。
如果一个交换机需要更多链路，那么就换个更大的交换机。如果一个给定的链路需要升级并且链路的两端都有扩展能力，那么只需升级光学器件即可。在结构内运行异构链路速度不是问题，因为每个路由器都可以充当速度匹配设备。
这种架构在数据中心领域中已经很常见了，根据交换机的层数，被称为 leaf-spine或super-spine架构。事实也证明，它非常健壮、稳定和灵活的。
从转发平面的角度来看，这是一个可行的替代架构，剩下的问题在于控制平面和管理平面。扩展控制平面需要在控制协议规模上有一个数量级的改进。另外，我们正在开发管理平面抽象，它使我们能够将整个 Clos 结构作为单个路由器进行控制。这项工作是作为开放标准进行的，因此所涉及的技术都不是专有的。
在过去的 50 年里，随着技术的不断权衡，路由器架构在断断续续的发展中也出现了许多失误。显然，进化尚未完成。在每次迭代中，都需要解决上一代的问题，同时又会发现一些新问题。
希望可以通过仔细总结过去和已有的经验，以更灵活和健壮的架构前进！
