WSO2 API Manager v1.8.0 - 集群
WSO2 API Manager v1.8.0 - Clustering
我有一个关于 WSO2 API 管理器集群的问题。我已经详细阅读了部署文档并了解分布式部署概念，其中一个可以隔离发布者、存储、密钥管理器和网关。但根据我的评估，这使得部署架构的维护非常复杂。所以我想有一个更简单的部署。
我测试的是简单地将 WSO2 API 管理器的两个不同实例 运行 放在两个不同的框中，指向 MySQL 中相同的基础数据源。我所看到的是，API 调用可以完美地工作，并且从一个 WSO2 实例获得的令牌可以用于另一个 API Manager 实例上的 API 调用。这个模型的唯一问题是我们需要为 运行ning 中尽可能多的 WSO2 API 管理器实例部署来自各个发布者组件的 APIs。我很乐意这样做，因为发布将由一个小团队完成。我们将在前面有一个硬件负载均衡器，它具有 API 端点 URL 和令牌端点 URL，用于 API 管理器和硬件 LB 将进行负载均衡。
所以我的问题是 - 从运行时的角度来看，遵循这种简单的方法有什么问题吗？从运行时的角度来看，集群是否为 WSO2 API 管理器增加了任何好处？
谢谢。
你的方法有以下缺点（可能还有更多我不知道的）；
- 不可扩展。意思是 - 您不能独立扩展（添加更多实例）商店或发布者或网关或密钥管理器。
分布式节流将不起作用。这将导致限制不一致，因为如果不启用集群，则不会发生限制复制。假设您为 API 定义了 'Gold' 层。无论您使用多少个网关实例，都应限制用户对此 API 的访问不超过 20req/min。这应该是基于分布式计数器实现的（不确定具体的实现细节）。因此，如果您不启用集群，一个网关节点将不知道其他网关节点所服务的请求数。所以每个网关节点都会有自己的节流计数器。意思是 - 用户可能能够以超过 20req/min 的速度访问您的 API。所以这是节流的不一致之一。此外，假设一个网关节点限制了用户，但另一个网关节点没有。现在，如果您的 LB 将请求路由到第一个网关节点，用户将无法访问 API。如果您的 LB 将请求路由到第二个网关节点，用户将能够访问 API。这是节流不一致的另一个例子。要克服所有这些问题，您只需要通过启用集群在所有网关节点之间复制限制。
分布式缓存将不起作用。例如，API 密钥验证信息被缓存。如果您在一个 API 管理器节点中撤销令牌，则该节点中的缓存将被清除。因此，用户不能通过那个 API 管理器节点使用已撤销的令牌，但他可以通过另一个 API 管理器节点使用该令牌，直到缓存失效（我猜默认为 15 分钟） .如果您不对 API Manager 实例进行集群，这只是一个可能出错的实例。要解决这些问题，您只需要启用集群，然后缓存将在整个集群中同步。阅读 this doc 以获取有关 WSO2 API 管理器中可用的各种缓存的更多详细信息。
如果您没有上述功能，您将遇到几个问题。 WSO2 强烈建议在生产中进行分布式部署。
我有一个关于 WSO2 API 管理器集群的问题。我已经详细阅读了部署文档并了解分布式部署概念，其中一个可以隔离发布者、存储、密钥管理器和网关。但根据我的评估，这使得部署架构的维护非常复杂。所以我想有一个更简单的部署。
我测试的是简单地将 WSO2 API 管理器的两个不同实例 运行 放在两个不同的框中，指向 MySQL 中相同的基础数据源。我所看到的是，API 调用可以完美地工作，并且从一个 WSO2 实例获得的令牌可以用于另一个 API Manager 实例上的 API 调用。这个模型的唯一问题是我们需要为 运行ning 中尽可能多的 WSO2 API 管理器实例部署来自各个发布者组件的 APIs。我很乐意这样做，因为发布将由一个小团队完成。我们将在前面有一个硬件负载均衡器，它具有 API 端点 URL 和令牌端点 URL，用于 API 管理器和硬件 LB 将进行负载均衡。
所以我的问题是 - 从运行时的角度来看，遵循这种简单的方法有什么问题吗？从运行时的角度来看，集群是否为 WSO2 API 管理器增加了任何好处？
谢谢。
你的方法有以下缺点（可能还有更多我不知道的）；
- 不可扩展。意思是 - 您不能独立扩展（添加更多实例）商店或发布者或网关或密钥管理器。
分布式节流将不起作用。这将导致限制不一致，因为如果不启用集群，则不会发生限制复制。假设您为 API 定义了 'Gold' 层。无论您使用多少个网关实例，都应限制用户对此 API 的访问不超过 20req/min。这应该是基于分布式计数器实现的（不确定具体的实现细节）。因此，如果您不启用集群，一个网关节点将不知道其他网关节点所服务的请求数。所以每个网关节点都会有自己的节流计数器。意思是 - 用户可能能够以超过 20req/min 的速度访问您的 API。所以这是节流的不一致之一。此外，假设一个网关节点限制了用户，但另一个网关节点没有。现在，如果您的 LB 将请求路由到第一个网关节点，用户将无法访问 API。如果您的 LB 将请求路由到第二个网关节点，用户将能够访问 API。这是节流不一致的另一个例子。要克服所有这些问题，您只需要通过启用集群在所有网关节点之间复制限制。
分布式缓存将不起作用。例如，API 密钥验证信息被缓存。如果您在一个 API 管理器节点中撤销令牌，则该节点中的缓存将被清除。因此，用户不能通过那个 API 管理器节点使用已撤销的令牌，但他可以通过另一个 API 管理器节点使用该令牌，直到缓存失效（我猜默认为 15 分钟） .如果您不对 API Manager 实例进行集群，这只是一个可能出错的实例。要解决这些问题，您只需要启用集群，然后缓存将在整个集群中同步。阅读 this doc 以获取有关 WSO2 API 管理器中可用的各种缓存的更多详细信息。
如果您没有上述功能，您将遇到几个问题。 WSO2 强烈建议在生产中进行分布式部署。