重试和超时
自动重试 是 service mesh 用于优雅地处理部分或瞬时应用程序故障的最强大和最有用的机制之一。如果实施不当，重试可能会将小错误放大为系统范围的中断。出于这个原因，我们确保它们的实施方式可以提高系统的可靠性，同时限制风险。
超时与重试密切相关。一旦请求被重试一定次数，限制客户端在完全放弃之前等待的总时间就变得很重要。想象多次重试迫使客户端等待 10 秒。
service profile 可以将某些路由定义为可重试或指定路由超时。这将导致 Linkerd 代理在调用该服务时执行适当的重试或超时。
重试和超时总是在 outbound (client) 端执行。
如果使用
headless services，则无法检索服务配置文件。Linkerd根据目标IP地址读取服务发现信息，如果这恰好是pod IP地址，则它无法判断pod属于哪个服务。
这些可以按照指南进行设置：
重试如何出错
传统上，在执行重试时，您必须在放弃之前指定最大重试次数。不幸的是，以这种方式配置重试有两个主要问题。
选择最大重试次数是一个猜谜游戏
你需要选择一个足够高的数字来产生影响；允许多次重试通常是谨慎的，如果您的服务不太可靠，您可能希望允许多次重试。另一方面，允许过多的重试尝试会在系统上产生大量额外的请求和额外的负载。执行大量重试也会严重增加需要重试的请求的延迟。在实践中，您通常从一顶帽子中选择一个最大重试次数（3？），然后通过反复试验调整它，直到系统大致按照您希望的方式运行。
以这种方式配置的系统容易受到 Retry Storm 的影响
当一项服务启动（出于任何原因）遇到比正常故障率更高的故障率时，retry storm就开始了。这会导致其客户端重试那些失败的请求。重试带来的额外负载会导致服务进一步减慢速度并导致更多请求失败，从而触发更多重试。如果将每个客户端配置为最多重试 3 次，则发送的请求数量可能会增加四倍！更糟糕的是，如果任何客户端的客户端配置了重试，重试次数就会成倍增加，并且可以将少量错误变成自我造成的拒绝服务攻击。
Retry Budgets 拯救
为了避免重试风暴和任意重试次数的问题，使用重试预算配置重试。Linkerd 不是为每个请求指定固定的最大重试次数，而是跟踪常规请求和重试之间的比率，并将此数量保持在可配置的限制以下。例如，您可以指定您希望重试最多增加 20% 的请求。Linkerd 将在保持该比率的同时尽可能多地重试。
配置重试总是在提高成功率和不给系统增加太多额外负载之间的权衡。重试预算(Retry Budgets) 通过让您准确指定系统愿意从重试中接受多少额外负载来明确权衡。