【发布时间】：2019-11-07 19:51:17
【问题描述】：
我目前正在设计一项服务，使我的客户能够创建和部署他们的 API，这与 AWS Api 网关不同。它将用作 API 入口点并路由到多个后端。这种网关的逻辑我很清楚，但整体架构仍然不清楚。
根据现代 SaaS 技术和规则，我需要创建一个抗故障的可扩展解决方案，该解决方案通常在服务请求时采用某种形式的并行性（至少对于一般的 API 而言）。
此网关能够创建和部署客户端 API（一组端点），这些 API 被注入到应用程序的主路由树中。例如 user1 创建 3 个端点的 API，我将它们作为 /user1/stage/xx[1,2,3] 注入到树中。然后另一个做同样的事情。网关控制其端点的部署和服务，并将所有数据存储在内存中以实现快速路由。
这就是可扩展性。我需要以解决方案不会失败的方式构建网关，并支持根据其需求进行扩展和缩减，但是我真的不知道如何将这样的单个应用程序逻辑分配给许多实例。
想到了两种方法，它们都有自己的弱点：
根据它处理的许多 api 分离服务。即 instance1 正在为 100 个 API 提供服务，所以是时候创建一个新的了。这将需要一些路由，主平衡器会知道将远程请求发送到哪里——哪个实例正在处理什么。其中一个实例的故障会导致 100 个 API 停机
仅将与所有逻辑和数据相关的实例分隔在一个位置。根据需要启动尽可能多的实例，向它们加载相同的数据，并使用任务平衡器根据平衡逻辑路由远程请求。这将需要所有实例带来所有 API 和某种控制点来部署和关闭所有实例上的客户端 API，但这实现了负载可伸缩性。但是，如果有很多 API，每个实例都必须将它们全部部署在其内存中（处理程序、路由表等）。
我错过了什么吗？你会如何解决这个问题？构建此类可扩展且故障安全的 API 网关的最佳方法是什么？
【问题讨论】：
标签： architecture devops