我对WSO2 API Manager群集有疑问 . 我详细介绍了部署文档，并了解了分布式部署概念，其中一个可以分离发布者，存储，密钥管理器和网关 . 但根据我的评估，这使得部署架构的维护非常复杂 . 所以我希望有一个更简单的部署 .
我测试的是简单地让两个不同的WSO2 API Manager实例在两个不同的框中运行，这两个框指向MySQL中的相同底层数据源 . 我所看到的是，API调用工作正常，从一个WSO2实例获取的标记可用于其他API Manager实例上的API调用 . 此模型的唯一问题是我们需要为正在运行的WSO2 API Manager实例部署各个发布者组件的API . 我这样做很好，因为出版将由一个小团队完成 . 我们将在前面有一个硬件负载 balancer 器，其中包含API endpoints URL和令牌 endpoints URL，两个API管理器和harware LB都将进行负载 balancer .
所以我的问题是 - 从RUNTIME的角度来看这个简单的方法有什么问题吗？群集是否为WSO2 API Manager的RUNTIME透视图添加了任何好处？
谢谢 .
1 回答
你的方法有以下缺点（可能有更多，我不知道）;
它不可扩展 . 含义 - 您无法独立扩展（添加更多实例）商店或发布者或网关或密钥管理器 .
分布式限制不起作用 . 它会导致限制不一致，因为如果不启用群集，则不会发生限制复制 . 假设您为API定义“黄金”层 . 无论您使用多少个网关实例，都应限制用户访问此API的访问速度不超过20req / min . 这应该是基于分布式计数器实现的（不确定具体的实现细节） . 因此，如果您不启用群集，则一个网关节点不知道其他网关节点所服务的请求数 . 因此每个网关节点都有自己的节流计数器 . 含义 - 用户可能能够以超过20req / min的速度访问您的API . 所以这是限制性不一致之一 . 此外，假设一个网关节点被用户限制，而另一个网关节点则没有 . 现在，如果您的LB将请求路由到第一个网关节点，则用户将无法访问API . 如果您的LB将请求路由到第二个网关节点，则用户将能够访问API . 这是限制不一致的另一个例子 . 要克服所有这些问题，您只需要通过启用群集来复制所有网关节点上的限制 .
分布式缓存赢得't work. For example, API Key validation information are cached. If you revoke a token in one API Manager node, cache will be cleared in that node. So a user can' t通过该API Manager节点使用撤销令牌，但他能够通过其他API Manager节点使用令牌，直到缓存失效（我猜默认为15分钟） . 如果您没有对API Manager实例进行群集，这只是一个可能出错的实例 . 要解决这些问题，您只需启用群集，然后缓存将在群集中同步 . 有关WSO2 API Manager中可用的各种缓存的更多详细信息，请阅读this doc .
如果您没有上述功能，您将遇到几个问题 . WSO2强烈建议在 生产环境 中进行分布式部署 .