容器如何改变可扩展性

“云尺度”这一术语经常被人们随意使用。 我认为，这个词在营销中被广泛使用，用来表示非常大的规模，而不是传统的不那么大但仍然很重要的规模。

但就像神话和传说中隐藏着真相一样，“云尺度”这个术语的出现也有一定的道理。

事实是，云（现在是容器）已经改变了可扩展性的底层基础。 这种变化根源于垂直和水平扩展策略之间的根本差异。 在本世纪的第一个十年，我们几乎完全秉持这样的理念：垂直扩展是实现我们所需的速度和进给的最佳方式。 这意味着更多的带宽、更多的计算能力和更多的内存。 更多端口。 密度更大。 处理速度更快。

但随着云时代的到来，焦点转向了水平规模。 我们仍然需要更多的带宽和计算处理能力，但我们已经学会了如何分配这种需求。 我们仍然需要更多的硬件，我们只是从多个来源而不是单一的整体实体来组装它。

资源的组合方式改变了游戏规则。 毫无疑问，由于容器的存在，游戏已经发生了改变。

今天的规模取决于控制平面。 用于启动和停用资源的 API 的速度可能比负载平衡服务本身的速度更重要。 在几分钟内启动和退出资源的环境中，服务发现的速度对于将请求传递到可用实例至关重要。

根据Sysdig 2019 年容器使用情况报告，超过一半（52％）的容器寿命少于五分钟： 

• 22% <= 10 秒 
• 17% <= 1 分钟
• 15% <= 5 分钟

近一半（42％）的容器实例数量在 201 到 500 个之间。 为了保持准确性，控制平面正在频繁更新组件。 比云的频率还要高得多，当然也比单片applications的频率要高得多。

因此，入口控制器（负载平衡机制）的更新速度以反映当前可用资源集成为一项关键能力。 因为如果错误的话，消费者请求可能会被定向到不再存在的资源，或者托管完全不同的服务。 无论哪种方式，由于请求被重定向到可用的资源，因此结果都是更长的响应。 消费者必须等待更长时间才能得到答复，并且可能会选择离开。

所有这些都表明，控制平面的速度是容器化环境中部署的applications可扩展性的阻碍因素。

最终，这意味着控制平面的规模是一个问题。 API 的设计是一个问题。 对 API 请求和更新的验证和授权机制是一个问题。

如今，谈到可扩展性，控制平面处于中心位置。 拥有一个强大且可扩展的控制平面并不是一件好事。 这是今天的 RFC 必须做的。