“云规模”一词经常被随意使用。在营销中，这个词常用来暗示规模非常庞大，以区别于传统的规模没那么大但仍然可观的情况。
不过，正如神话和传说中也蕴含着些许真相一样，人们对“云规模”一词的惯常用法也并非毫无根据。
事实上，云以及如今的容器已经改变了可扩展性的底层基础。这一变化源于纵向扩展与横向扩展策略之间的根本差异。在本世纪的头十年，我们几乎完全认为，纵向扩展是实现所需吞吐量和处理速度的理想方式。这意味着更高的带宽、更强的计算能力和更大的内存，以及更多端口、更高密度和更快的处理速度。
但随着云时代的到来，关注重点转向了横向扩展。我们仍然需要更大的带宽、更多的计算资源和更强的处理能力，但已经学会如何分散这些需求。我们仍然需要更多硬件，只是不再依赖单一的整体式实体，而是将来自多个来源的硬件组合起来。
真正改变局面的是资源的组合方式。毫无疑问，容器已经改变了这一局面。
如今，扩展能力取决于控制平面。用于启动和停用资源的API速度，可能比负载均衡服务本身的速度更为重要。在资源几分钟内即可启动和停用的环境中，服务发现的速度对于将请求转发到可用实例至关重要。
根据《Sysdig Container Usage Report 2019》，超过半数（52%）的容器生命周期不足5分钟：
- 22% ≤ 10 秒
- 17% ≤ 1 分钟
- 15% <= 5 分钟
近一半（42%）的受访者运行着201至500个容器实例。为确保准确性，控制平面会频繁更新组件，其频率远高于云环境，更远超单体应用以往的更新频率。
因此，快速更新入口控制器（负载均衡机制），使其反映当前可用资源集合，便成为一项关键能力。如果更新有误，消费者请求可能会被定向到已不存在的资源，或正在托管完全不同服务的资源。无论哪种情况，请求都需要重新定向到可用资源，导致响应时间延长。消费者必须等待更长时间才能收到响应，也可能因此选择离开。
这一切都表明，控制平面的速度是制约容器化环境中所部署应用扩展能力的因素。
归根结底，这意味着控制平面的扩展能力存在问题。API的设计存在问题。对API请求和更新进行身份验证与授权的机制也存在问题。
如今谈到可扩展性，控制平面已成为关键所在。稳健且可扩展的控制平面不再是锦上添花，而是RFC中定义的“MUST”级要求。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。