Architecture 您将如何扩展api网关服务？

我目前正在设计一项服务，使我的客户能够创建和部署他们的Api，这与AWSAPI网关没有什么不同。它将被用作API入口点并路由到多个后端。这种网关的逻辑对我来说很清楚，但是总体架构仍然不清楚

根据现代SaaS技术和规则，我需要创建一个抗故障的可伸缩解决方案，该解决方案通常在服务请求时采用某种形式的并行性（至少对于一般的API）

该网关能够创建和部署客户端API（端点集），这些API注入到应用程序的主路由树中。例如，user1创建了包含3个端点的API，我将它们作为/user1/stage/xx[1,2,3]注入到树中。然后另一个也会这样做。网关控制其端点的部署和服务，并将其所有数据存储在内存中以实现快速路由

可伸缩性来了。我需要以这样的方式构建网关，即解决方案不会失败，支持根据其需要进行放大和缩小，但是我不知道如何将这样的单个应用程序逻辑分发到多个实例

想到两种方法，它们都有各自的弱点：

基于许多API it流程的独立服务。i、 instance1正在为100个API提供服务，所以是时候创建一个新的API了。这将需要一些路由，主平衡器将知道在哪里发送远程请求-哪个实例正在处理什么。其中一个实例的失败将导致100个API停机

仅在一个位置分离与所有逻辑和数据相关的实例。根据需要调出尽可能多的实例，向它们加载相同的数据，并使用任务平衡器根据平衡逻辑路由远程请求。这将需要所有实例带来所有API和某种控制点，以便在所有实例上部署和关闭客户端API，但这实现了负载可伸缩性。但是，如果有很多API，每个实例都必须在其内存（处理程序、路由表等）中部署它们

---

我错过什么了吗？你将如何处理这个问题？构建这样的可伸缩且故障安全的api网关的最佳方法是什么？

好吧，虽然已经晚了，但我使用容器化实现了，我已经为api网关编写了一个定制服务，然后将其部署为Kubernetes集群中的一个容器。K8s通过复制豆荚来处理之后的缩放