0

我有一个关于 WSO2 API Manager Clustering 的问题。我已经详细阅读了部署文档并理解了分布式部署概念，其中一个可以隔离发布者、存储、密钥管理器和网关。但根据我的评估，这使得部署架构的维护非常复杂。所以我想要一个更简单的部署。

我测试的是简单地让 WSO2 API 管理器的两个不同实例在两个不同的盒子中运行，指向 MySQL 中相同的底层数据源。我所看到的是，API 调用工作完美，从一个 WSO2 实例获得的令牌将适用于另一个 API Manager 实例上的 API 调用。此模型的唯一问题是我们需要从各个发布者组件中为尽可能多的正在运行的 WSO2 API Manager 实例部署 API。我可以这样做，因为发布将由一个小团队完成。我们将在前面有一个硬件负载均衡器，其中包含 API 端点 URL 和令牌端点 URL，用于 API 管理器和硬件 LB 将执行负载均衡。

所以我的问题是 - 从 RUNTIME 的角度来看，遵循这种简单的方法有什么问题吗？集群是否从 WSO2 API Manager 的 RUNTIME 角度增加了任何好处？

谢谢你。

4

1 回答 1

0

您的方法有以下缺点（可能还有更多我不知道的缺点）；

  • 它不可扩展。含义 - 您不能独立扩展（添加更多实例）存储或发布者或网关或密钥管理器。

  • 分布式节流不起作用。这将导致限制不一致，因为如果您不启用集群，将不会发生限制复制。假设您为 API 定义了“黄金”层。无论您使用多少网关实例，都应限制用户访问此 API 的速度不超过 20req/min。这应该基于分布式计数器实现（不确定确切的实现细节）。所以如果你不启用集群，一个网关节点不知道其他网关节点服务的请求数量。所以每个网关节点都会有自己的节流计数器。含义 - 用户可能能够以超过 20req/min 的速度访问您的 API。所以这是节流的不一致之一。更远，假设一个网关节点被限制了用户，但另一个网关节点没有。现在，如果您的 LB 将请求路由到第一个网关节点，用户将无法访问 API。如果您的 LB 将请求路由到第二个网关节点，用户将能够访问 API。这是另一个节流不一致的例子。要克服所有这些问题，您只需要通过启用集群在所有网关节点之间复制限制。

  • 分布式缓存不起作用。例如，API Key 验证信息被缓存。如果您撤销某个 API Manager 节点中的令牌，则该节点中的缓存将被清除。因此，用户无法通过该 API Manager 节点使用已撤销的令牌，但他可以通过其他 API Manager 节点使用该令牌，直到缓存失效（我猜默认为 15 分钟）。如果您不对 API Manager 实例进行集群，这只是可能出现问题的一个实例。要解决这些问题，您只需要启用集群，然后缓存将在集群中同步。阅读此文档以获取有关 WSO2 API Manager 中可用的各种缓存的更多详细信息。

如果您没有上述功能，您将遇到几个问题。WSO2强烈建议在生产中进行分布式部署。

于 2015-08-06T05:45:54.420 回答