要扩展容器，不能只是在服务前面加个代理就不管了。扩展也不只是分发。在快速发展的容器领域，要确保可扩展性，需要具备五项不同的能力：重试、熔断、服务发现、流量分发和监控。
在这篇探讨容器扩展之道的文章中，我们将深入了解重试机制。
重试
小时候玩游戏时，很多游戏里都有“重试”的概念。失败后，孩子们常会喊“再来一次！”，希望其他玩家能让自己重试。有时大家会同意，有时不会。但我发现，这很少能阻止孩子继续尝试。
在扩展应用（也可以称为服务）时，重试的概念大致相同。代理选择一项服务并尝试处理请求时，收到错误。在基本的负载均衡场景中，通常通过检查HTTP响应代码来判断是否出错。“200 OK”以外的任何响应都视为错误，其中包括网络和TCP层超时。负载均衡器可以直接将失败响应返回给
请求方；或者，如果它足够智能，也可以重试请求，希望后续请求能够获得成功响应。
这听起来很基础，但在规模化发展初期，并没有重试机制。失败了就是失败了，只能设法处理，通常是在浏览器中手动重新加载。后来，代理终于变得足够智能，可以自行重试，也让许多键盘免于因频繁按下“CTRL”和“R”键而磨损。
表面上看，这堪称“疯狂”的典型写照。毕竟，如果请求第一次失败了，凭什么认为第二次（甚至第三次）就会成功？
答案在于故障的原因。扩展应用时，务必要了解连接容量对故障的影响。任何给定资源在任意时刻的负载都不是固定的。连接会不断建立和关闭。底层Web应用平台，无论是Apache或IIS、node.js引擎还是其他技术栈，都有明确的容量限制。它只能维持X个并发连接。达到此限制后，尝试建立新连接时将会挂起或失败。
如果故障由此引起，那么在代理收到失败响应所需的几微秒内，另一个连接可能已经关闭，从而使重试有机会成功。
在某些情况下，故障发生在平台内部，也就是令人头疼的“500 内部服务器错误”。服务器并未过载，但调用的另一个（外部）服务未能及时响应时，通常会出现此状态。有时，这是因为数据库连接池已达到自身上限。依赖外部服务可能引发级联错误。与连接过载类似，等您收到最初的错误时，问题通常已经解决。
您可能还会看到这个“非常有用”的“503 Service Unavailable”错误。它可能是由过载引起的，但与所有HTTP错误代码一样，并不总能准确反映实际问题。DNS故障可能会触发此错误；对于IIS和ASP，队列已满也可能导致此错误。实际原因多种多样。同样，等您收到错误时，问题可能已经解决，因此首先应尝试重试。
当然，不能无休止地重试。TCP重传可能产生意外后果，例如导致网络过载和接收端不堪重负；同样，重试最终也会失去意义。对于放弃前应重试多少次，并没有硬性规定，但通常为3至5次。
此时，应向请求方返回失败信息，并启动断路器。我们将在下一篇文章中深入探讨这一功能。
关于作者
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服务。