我目前正在设计一项服务，该服务将使我的客户能够创建和部署其API，与AWS Api网关不同。它将用作API入口点，并路由到多个后端。这种网关的逻辑对我来说很清楚，但是总体架构仍然不明确。
根据现代SaaS技术和规则，我需要创建一个可抗故障的可伸缩解决方案，该解决方案通常在服务请求时采用某种形式的并行性（至少对于API而言如此）。
此网关能够创建和部署注入到应用程序主路由树中的客户端API（端点集）。例如，user1创建了3个端点的API，我将它们作为/ user1 / stage / xx [1,2,3]注入到树中。然后另一个做同样的事情。网关控制其端点的部署和服务，并将其所有数据存储在内存中以便快速路由。
可扩展性到了。我需要以这样的方式来构建网关，即该解决方案不会失败，将支持根据其需求进行向上和向下缩放，但是我真的看不到如何将这样的单个应用程序逻辑分配给许多实例。
想到了两种方法，它们都有缺点：
-
基于它处理的许多api的单独服务。即instance1正在为100个API提供服务，因此是时候创建一个新的API了。这将需要主平衡器知道将远程请求发送到哪里的路由-哪个实例正在处理什么。而其中一个实例的失败将使100个API失效
-
仅将与所有逻辑和数据相关的实例放在一个位置。调出所需的实例数，将相同的数据加载到它们，然后任务平衡器根据平衡逻辑路由远程请求。这将要求所有实例都带上所有API，并需要某种控制点才能在所有实例上部署和降低客户端API，但这可以实现负载可伸缩性。但是，如果有很多API，则每个实例都必须将它们全部部署在其内存中（处理程序，路由表等）。
我想念什么吗？您将如何解决这个问题？像这样构建可扩展且故障安全的api网关的最佳方法是什么？