构建弹性架构的 5 个技巧

如何构建弹性架构和系统?提供五个建议:

1、后备措施
您需要考虑为您使用的任何外部服务提供后备方案。例如,这可以是支付网关或简单的 URL 缩短器。为什么?如果您依赖这些外部服务并且它们变得不可用,这可能会对您的应用程序/服务的可用性产生负面影响,特别是当它对您至关重要时。

如果您希望您的应用程序/服务具有弹性,则不能假设或期望第三方服务始终可用。您需要有一个后备方案来实现相同的结果。例如,如果您依赖于 URL Shortener,那么您必须定义一些抽象来使用您的主要工具,并在需要时回退到辅助工具。

不要假设第三方服务将始终可用。即使是暂时性错误的回退也会使您的应用程序/服务具有弹性。

这也适用于断路器模式,这是另一种弹性架构模式,在该模式中,如果主服务器不可用,您可以使用断路器将所有后续请求发送到后备服务器一段时间。超过该期限后,您再次尝试主数据库。

2、超时
与回退密切相关的是任何网络调用的超时。通常,这是一个相当快的超时(相对于服务的正常延迟)。在与第 3 方服务通信的示例中,假设通过 HTTP 平均请求需要 500 毫秒。然后,突然间,第三方服务的性能下降,并且突然开始需要 30 秒;这将如何影响您的应用程序/服务?您现在的性能将会下降。

为网络调用添加超时使您能够灵活地使用回退,不仅是在服务不可用时,而且是在其延迟高于您预期或可以容忍的情况下。

3、队列
将工作改为异步完成可能会对系统的弹性产生重大影响。它为您提供了许多关于如何处理故障的选项。

当您收到来自客户端的请求,并且不需要完成该工作来向他们提供响应时,您可以将该工作移至异步完成。您可能没有意识到系统中存在许多非常适合异步的用例。举一个简单的通用示例,就是下订单时处理付款。如果您有电子商务系统,那么在下订单时,您需要处理他们的信用卡。这不需要在将订单保存到数据库的同一过程中进行。这可以在事后异步处理,甚至可以由另一个进程处理。

将消息放入队列后,您可以让同一个实例或另一个实例完全消耗队列中的该消息,然后尝试通过向支付网关发出请求来处理信用卡。为什么这是比将订单保存到数据库时更好的策略?如果您将订单保存到数据库但支付网关不可用,会发生什么情况?假设您在这种情况下没有后备措施。

队列是完美的,因为您不会失去需要完成的工作的意图。如果没有成功处理该消息,该消息不会神奇地消失。许多不同的策略都是围绕队列构建的,例如重试、指数退避和死信队列DLQ。这意味着,如果支付网关不可用,我们可以将消息移至死信队列,表示失败且未正确处理的消息。

一旦进入 DLQ,我们就可以手动尝试重新处理这些消息。另一个用例是处理大量涌入的流量。您的系统可能能够处理处理,但您的支付网关可能无法处理,并且可能会限制您。在这种情况下,队列是避免丢失任何待完成工作的好方法。这很好地适应了容量。

4、容量
了解系统的容量限制以及如何扩展。如果您使用队列,则可以使用和处理的消息数量将受到限制。随着时间的推移,如果您开始生成的消息多于您可以消耗的消息,那么您的队列中就会出现积压,并且永远无法赶上。

答案是横向扩展、添加更多消费者并使用竞争消费者模式。添加更多消费者进程,这些进程将全部消费队列中的消息。这使我们能够处理更多的消息并发并提高吞吐量。

然而,我们也必须意识到你可能会移动瓶颈。通常,在处理消息时,您可能会使用其他下游服务。

在前面的示例中,我提到了支付网关。它的容量可能与您自己的不同。在这种情况下,如上所述,您可能希望根据其容量来限制同时处理或在滑动窗口中处理的消息数量。

另一个例子是您自己的数据库。如果您处理的消息与数据库交互,您可能不仅能够扩展您的使用者,还可能会移动瓶颈并使数据库过载。

异步移动工作固然很棒,但您必须了解整个系统各个点的容量,包括您使用的外部系统。对队列和队列的不同优先级使用各种负载均衡技术是不压垮任何下游服务的好方法。

但这不仅仅是排队;它是您系统的任何部分。您的 HTTP API 可以处理多少个请求,以及多少个数据库调用?所有这些都根据正在执行的工作负载和数量而变化。并非所有工作都是平等的。

5、监控
弹性架构意味着您需要关于系统在正常情况下如何运行的良好指标,并能够在情况开始偏离时向这些指标发出警报。换句话说,您希望主动保持系统正常运行而不发生任何中断。您希望在没有问题时收到通知,以便您可以在出现问题之前调整系统。

以队列为例,您可能想知道流入和流出速率。换句话说,您每秒生成多少条消息,每秒消耗并完全处理多少条消息?

您会遇到高峰和低谷,但在滑动的时间窗口中,您将拥有可以处理的消息数量的上限。在一段时间内拥有有关队列深度的指标是一个很好的警报指标,这样您就可以提前处理任何积压的事情。

您是否正在对第三方服务进行 HTTP 调用?这些通常需要多长时间?开始获取有关这些呼叫的指标,以便在呼叫超出阈值时发出警报。

总结
构建弹性架构意味着积极主动,并为自己提供如何处理故障并在需要时扩展系统的选项。希望这 5 个技巧能够为您提供一些想法,让您可以从哪里开始审视您的系统,使其更具弹性。