如何构建能够持续正常运行的弹性架构和系统？这里给出五个你可以考虑实施的建议，确保你的系统稳定且可靠。
备用方案
在设计时，要考虑到依赖外部服务时可能出现的备用选项。比如，可能是支付网关，或者简单的 URL 缩短服务。为什么？如果你的应用或服务严重依赖这些外部服务，一旦它们不可用，可能会影响到应用的可用性，特别是对于关键业务来说。
为了使你的应用/服务具有弹性，不能假设第三方服务总是可用的。你需要设置一个备用方案来达到相同的目标。例如，如果依赖 URL 缩短服务，就需要定义一种抽象机制，以便在需要时切换到备用服务。
不要期待第三方服务始终可用。即使面对短暂的错误，备选方案也能提升系统的弹性。
这与电路断路器模式（circuit breaker pattern）也有关联。在这种模式中，如果主服务不可用，电路断路器会在一段时间内将所有后续请求转发到备用服务。超时过后，再尝试恢复使用主服务。
超时限制
对于网络调用设置超时是非常相关的。通常，这个时间比服务的平均延迟要短。以与第三方服务通过 HTTP 通信为例，如果平均请求耗时 500 毫秒，但如果突然间该服务性能下降，响应时间变为 30 秒，这对你的应用/服务会有什么影响？现在你的性能也会下降。
为网络调用设置超时可以让你在服务响应时间超出预期或可容忍范围时，能够利用备用方案，而不仅仅是服务不可用时。
异步队列
将工作异步处理对提高系统弹性有很大影响。它为你处理失败提供了多种策略选择。
当收到客户端请求时，如果工作不是立即提供响应所必需的，可以将其异步处理。许多你可能未意识到的场景非常适合异步处理。例如，在电商系统中，当订单创建时处理信用卡支付就是一个例子。下单后并不一定要立即保存订单到数据库，这可以事后异步处理，甚至由另一个进程负责。
一旦消息放入队列，可以由同一实例或完全不同的实例从队列中消费该消息，然后尝试通过向支付网关发送请求来处理信用卡支付。相较于直接在保存订单到数据库时处理，这种策略有何优点？如果在保存订单时支付网关不可用，会发生什么？假设在这种情况下没有备用方案？
队列非常理想，因为它们不会丢失需要执行的工作意图。如果消息处理不成功，它不会凭空消失。队列周围有许多策略，如重试、指数退避和死信队列。这意味着如果支付网关不可用，我们可以将消息移到死信队列，表示那些未能正确处理的消息。
一旦进入死信队列，我们可以手动尝试重新处理这些消息。另一个应用场景是处理突发流量。你的系统可能能处理处理任务，但支付网关可能无法应对并进行限流。这时，队列是一个很好的方法，避免丢弃任何待处理的工作。这自然而然过渡到了“容量”。
容量管理
了解系统的容量限制以及如何扩展。如果你使用队列，会有一个消息消费和处理的上限。随着时间推移，如果你产生的消息超过处理能力，队列就会出现积压，永远追不上。
答案是水平扩展，增加更多的消费者，并使用竞争消费者模式。添加更多处理消息的进程，从而提高并发处理能力和吞吐量。
但我们也必须意识到可能会移动瓶颈。通常，在处理消息时，可能会使用下游服务。
在我之前举的例子中，我提到了支付网关。其容量可能与你的不同。在这种情况下，如前所述，你可能想要根据它的容量限制同时处理消息的数量，或者使用滑动窗口的方式。
另一个例子是你的数据库。如果你处理的消息与数据库交互，你可能不能只通过增加消费者来扩展，因为可能会移动瓶颈并过载数据库。
异步工作很出色，但你需要了解系统各个部分的容量，包括使用的外部系统。通过队列和优先级不同的队列使用负载均衡技术，是避免过度负荷下游服务的好方法。
但这不仅仅局限于队列；系统中的任何部分都适用。你的 HTTP API 能处理多少请求？数据库调用呢？这些都是根据执行的工作负载和流量变化的。并非所有工作都同等重要。
那么，如何确定你的容量呢？很高兴你问到了这个问题。
监控
一个弹性的架构意味着你需要关于系统正常运行情况的良好指标，并能在出现问题时报警。换句话说，你要积极主动，防止系统无预警地停止运行。在问题发生前得到通知，以便及时调整系统。
例如，对于队列，你想要知道每秒产生的消息数量和每秒完全处理的消息数量。会有高峰和低谷，但在一段时间内，你会有一个可以处理的最大消息数量。在一段时间窗口内监测队列深度是很好的报警指标，这样可以提前应对任何积压。
你是否向第三方服务发送 HTTP 请求？这些请求通常需要多长时间？开始收集这些请求的指标，在它们超过阈值时发出报警。
构建弹性的架构就是要有预见性，并在需要时为你处理失败和系统扩展提供选项。希望这五个技巧能给你一些启发，帮你从哪些方面开始审视你的系统，使其更具弹性。
Comments