Design patterns 在我的web应用程序中，一个组件比其他组件慢，如何处理？

假设我有一个基于微服务的体系结构。一些微服务的负载比其他的更重。我如何决定对每个组件进行多少扩展？我的理解是，我会进行负载测试，找出每个服务可以承受多少负载&基于我对一些服务的衡量，比如说3倍，一些是5倍等等。现在假设我有一个服务-支付服务-它依赖于第三方支付网关，速度慢，不在我的控制范围内-如何处理？我可以自由地将应用程序和用户docker/kubernetes打包。

第三方支付处理程序速度慢，处理请求可能需要几秒钟。这将以各种方式影响您的体系结构

首先，您的支付服务不应公开可能需要几秒钟才能响应的入口点

服务消耗的内存和其他资源的数量与同时请求的数量成正比，而同时请求的数量与响应时间成正比。如果您的慢速服务可以将所有上游服务的响应时间乘以10或100倍，那么它可以将这些资源的消耗乘以相同的系数，这是不可接受的。让每个人等待几秒钟而没有状态反馈也是不可接受的

因此，您需要的不是“processPayment”入口点，而是：

• “startPayment”入口点，可快速启动支付并返回交易ID
• 一个“checkStatus”入口点，可以检查给定ID的事务的状态；及
• 也许是订阅事务状态更新的一种方式

所有这些入口点都应该是快速的

此外，支付处理在几秒钟内跨越多个请求，这意味着你不可能真正依赖于所有的东西在整个时间内都不睡觉。因此，进行中的事务及其状态更新必须持久保存在持久性存储（某种数据库）中。无论如何，您可能都希望这样做，因为“开始付款”和“检查状态”请求不必在同一个服务实例上结束，而DB是将状态从一个实例传递到另一个实例的工具

与第三方处理器的通信通常应由“工作”进程/线程来处理，因为请求处理线程并没有针对这些类型的响应时间进行配置。如果通过向第三方处理器发出一个请求来处理付款，那么使用异步客户端调用该服务将非常重要，这样您就不必同时保持数千个线程的活动。客户端计算机上的网络堆栈可能还需要仔细配置，以支持该数量的同时连接

最后，由于资金正在被处理，因此确保交易不会被遗忘、确保您可以随时检查其状态以及防止重试导致多次付款（一直到用户界面）至关重要。支付处理程序将提供足够的API，允许您在任何情况下都这样做，但可能需要您仔细设计

---

为了支持所需的用户界面，您还需要一个入口点，该入口点可以检查事务是否已出于任何特定目的进行。

如果是外部依赖，我怀疑我们是否能对此做很多工作。您可能需要异步处理它？“我们在这里谈得有多慢？”伊姆兰·阿尔沙德，谢谢你的回答。事实上，这是一个面试问题，我得到了这个假想的场景，我回答说，我们唯一能处理的方法就是异步处理回答。面试官表现得不服气。也许这个答案是正确的-我不知道面试官的想法。我知道的唯一处理方法是向用户显示进度条。在现实生活中，我也控制着支付网关，所以我要求相关团队提供更多的入口点。我明白了。实际上，这取决于具体情况。另一种方法是将消息放入队列中，并提供客户端消息ID，客户端可以每X秒轮询一次，以查看消息是否正在进行，并且您不会阻止客户端。或者，您只需将消息放入队列中，稍后通过电子邮件确认用户，而不会阻止用户。由于这是一个面试问题，一个快速的一行解决方案是事件驱动架构。SEDA是我脑海中浮现的东西。