假设我有一个基于微服务的体系结构。有些微服务比其他微服务负载更重。我如何决定对每个组件进行多少扩展？我的理解是我进行负载测试，并找出每个服务可以承受的负载，并基于我将某些服务缩放为3倍，将某些服务缩放为5倍，等等。现在假设我有一项服务-支付服务-取决于缓慢且不受我控制的第三方支付网关-如何处理？我可以随意将应用程序和用户docker / kubernetes容器化。
答案 0 :(得分：0)
缓慢的第三方付款处理器可能需要几秒钟来处理请求。这将以多种方式影响您的架构。
首先，您的付款服务不应公开可能需要几秒钟才能响应的入口点。
服务消耗的内存量和某些其他类型的资源与并发请求数成正比，与响应时间成正比。如果您的慢速服务可以将 all 上游服务的响应时间乘以10或100倍，则可以将这些资源的消耗乘以相同的因子，这是不可接受的。让每个人都等待几秒钟而没有状态反馈也是不可接受的。
因此，您需要：
而不是“ processPayment”入口点。所有这些入口点都应该很快。
此外，支付处理在几秒钟内分散在多个请求中，这意味着您不能真正依赖于整个时间内保持一切正常。因此，正在进行的事务及其状态更新将必须持久保存在持久性存储（某种数据库）中。无论如何，您可能都想这样做，因为“开始付款”和“检查状态”请求不必最终在同一服务实例上结束，而数据库则是将状态从一个实例传递到另一个实例的方式。
与第三方处理器的通信通常应由“工人”进程/线程处理，因为没有为那些类型的响应时间设置请求处理线程。如果通过向第三方处理器的单个请求处理付款，那么使用异步客户端调用该服务就很重要，这样您就不必同时保持数千个线程处于活动状态。客户端计算机上的网络堆栈可能还需要仔细配置，以支持同时发出的连接数量。
最后，由于正在处理资金，因此至关重要的一点是，确保不要忘记交易，确保您始终可以检查交易状态，并防止从重试一直到用户的多次付款接口。支付处理器将提供足够的API以使您无论如何都可以执行此操作，但这可能需要您进行仔细的设计。
要支持所需的用户界面，您还将需要一个入口点，该入口点可以检查是否已出于任何特定目的进行了交易。