容器时代的网络

在过去的几年中，随着虚拟化和现在的容器化增加了任何给定硬件上的应用程序密度，我们开始痴迷于管理东西流量而不是南北流量的挑战。

对于那些仍然不太了解数据中心流量模式的人来说，让我们回顾一下： 南北是用户到应用程序或客户端到服务器或数据中心内外。 东西向是服务器到服务器、应用程序到应用程序、服务到服务，或者仅仅是在数据中心内。

南北流量模式受到不断增加的用户、应用程序和事物的影响。 所需的用户应用连接越多，您将看到的南北流量就越多。 东西向流量受到应用程序架构和基础设施技术的影响。 当将虚拟化和容器等技术与微服务等新兴架构相结合时，必须跨数据中心相互通信的“应用程序”或“服务”的数量将呈指数级增长。

基本上，应用架构及其基础设施越分散，你会看到的东西向流量就越多。

推动这一增长的是应用程序“合适规模”的趋势。 容量规划不是基于增长预测，而是基于当前需要加上一点额外的东西。 由于自动扩展等技术的成熟，我们能够更有效地利用资源，减少闲置的计算和网络资源；消耗预算却不产生相应的价值。 顺便说一句，这是私有云的好处之一；通过提供面向服务的配置和管理来实现资源的实时使用，能够更好地利用原本会闲置的资源。

但我离题了。 重点是，由于架构和技术的发展，东西向流量正在增加，其速度可能超过南北向流量的增长速度。

现在，过去二十年来应用架构和技术的每一次重大转变都会引起“网络”的同等反应。 这是因为无论流量朝哪个方向流动，网络都负责管理流量。 东西南北，无所谓。 无论是虚拟的还是物理的，都需要网络来确保流量从当前位置到达需要的位置。

现在的问题是，由于微服务导致applications分解，东西向流量出现更大增长，网络应该如何响应？ 更准确地说，网络中的服务应该如何响应以提供向用户或越来越多的其他应用程序提供应用程序所需的关键功能（可用性、安全性、优化）？

影响一： 转到应用程序 

很显然，这个问题的第一个答案是，与应用程序相关的服务必须更靠近应用程序。它们不能停留在南北模式的边缘，而主要为以东西模式使用它们的应用程序提供服务。 这是网络资源的低效使用以及路由模式的影响，会导致应用通信延迟。 这时，我们开始听到诸如“tromboning”和“hairpinning”之类的流量模式术语，这些模式描述了通过网络的一条路线，需要离开一台机器，向北穿过网络，然后返回同一台机器。 这种延迟会转化为实际的业务成本，表现为生产力下降（“请耐心等待，我的‘电脑’今天很慢”），以及消费者更多地放弃购物车和网络应用。 这正是我们想要避免的；如果流量是东西向的，那么服务应该位于该数据路径中。

影响二： 操作兼容性 

第二个答案是，这些服务（如负载平衡和 Web 应用程序安全）必须能够以操作兼容的格式部署。 换句话说，我们不会在每个出现的应用程序（或微服务）前面放置网络硬件。 因此，提供这些服务的平台必须虚拟化或容器化，以便在操作上与新兴架构和技术兼容。 它们还必须是可编程的，提供支持 DevOps 导向的配置和管理方法的 API 和模板。 服务（无论是应用还是网络）都需要可协调。 如果 SDN 可以与主导基础设施和应用操作环境的工具和框架相结合，那么它也可以满足这一需求。 

影响三： 架构至关重要

第三个答案是，建筑变得比以往任何时候都更加重要。 仅仅因为可以在与其应用相同的主机上部署网络服务并不一定意味着它应该部署在那里。 根据它是什么以及它与其他服务（和服务实例）的交互，放置成为一个需要考虑的重要问题。 例如，架构不良的负载平衡可能会导致可怕的流量模式，从而产生不必要的延迟；这种延迟会直接转化为企业利润或损失。 在这种情况下，部署服务的主机上的任何故障（硬件、软件、网络、存储）都会导致停机（而且是严重的停机），因为负责确保应用程序可用的服务也处于停机状态。 在高度分解的应用架构（微服务）中，如果这些应用程序的依赖性很高，那么这可能是灾难性的。

需要仔细考虑（架构）以确保不会因最明显（和最简单）的答案而忽视有关性能和可用性的最佳实践。

网络仍然是建筑中的一项练习

网络现在是、并且将继续是一项架构上的努力。 这不仅仅与形式因素有关，这只是一种更快、更有效地将网络资源获取到所需位置的方法。 它涉及这些资源的放置以及它如何影响堆栈中上游的一切：网络服务、应用服务、应用性能以及最终的业务成功或失败。

容器、虚拟化和云时代的网络不仅涉及架构，还涉及运营。