扩展容器并非只是在服务前面加个代理就万事大吉。扩展不只是分发。在快速发展的容器领域，要确保顺利扩展，需要具备五项不同的能力：重试、熔断、服务发现、分发和监控。
本文将探讨容器扩展之道，深入解析流量分配。
分发
任何系统要实现扩展，关键始终部分取决于如何将请求分配到有限的资源集合中。即使云看似能提供无限的计算资源，也无法改变这一点。在收到请求的那一刻，能够接收并处理该请求的资源必然是有限的。事实就是如此。
因此，决定将请求定向到哪个资源就显得相当重要。如果将请求发送到错误的资源，性能可能会受到影响；如果发送到合适的资源，消费者或员工将会对结果感到满意。
在早期扩展阶段，这些决策完全基于算法，例如轮询、最少连接和最快响应。这些久经考验的机制沿用至今，但已逐渐从唯一的决策依据转变为决策过程中的一个因素。
这是因为，我们不再仅依赖基于连接的决策流程（也就是“传统负载均衡”）。当负载均衡主要用于管理TCP连接时，采用基于连接的分配方案合情合理。但如今，扩展能力既取决于算法，也取决于架构；请求分配可能涉及复杂计算，需要考虑第4层协议之上（字面意义上）及其范围之外的诸多变量。
如今，架构本身也日益分布式，不仅跨云，还跨容器，这使请求分发更加复杂。同一应用（或API）的多个版本可能同时提供服务。负责分发请求的系统必须能够感知并区分这些版本，确保将请求发送到正确的端点。
如今，决策不仅基于连接容量，还越来越多地依据第7层（HTTP）参数，包括主机名、API方法（即URI）、API密钥、嵌入版本号的自定义HTTP标头、位置、设备和用户。系统会结合请求发起时的上下文进行评估，并在微秒内作出决策。
如今，流量分配需要采用分层架构方法。越深入应用架构，决策粒度就越粗。当代理在同一微服务的X个副本之间做出负载均衡决策时，很可能只使用传统算法驱动的计算公式。与此同时，在环境的最外层，入口控制器有时会根据HTTP层变量做出复杂决策。
在外层，分发由架构驱动；在内层，则由算法驱动。
两者都是扩展容器的关键组成部分，甚至可能是其中最为关键的部分。
两者都依赖准确的实时信息，以了解可能接收其所分发请求的资源状态（运行状况）。本系列接下来的几篇文章将介绍监控。
关于作者
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服务。