【问题标题】:WSO2 API Manager v1.8.0 - ClusteringWSO2 API Manager v1.8.0 - 集群
【发布时间】:2016-08-19 09:09:06
【问题描述】:

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

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

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

谢谢。

【问题讨论】:

    标签: wso2 wso2-am api-manager


    【解决方案1】:

    您的方法有以下缺点(可能还有更多我不知道的);

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

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

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

    【讨论】:

    • 1.关于可伸缩性的第 1 点,我总是可以添加更多 API 管理器本身的实例,以添加更多网关和密钥管理器以及发布者和存储的实例。我知道我无法独立扩展,但从 RUNTIME 的角度来看,我认为这不会造成任何问题。
    • 2.请详细解释分布式节流以及它如何导致不一致。如果我始终确保为每个 API 统一应用节流层。你还发现什么问题吗?
    • 3.缓存是指应用程序数据缓存吗?如果是这样,我不打算在 API Manager 层使用任何应用程序数据缓存。如果它与 WSO2 需要在您预见问题的地方维护的任何缓存相关,请提供更多信息。我已经在启用缓存的情况下进行了测试,并且确实看到该产品运行良好,即两个 WSO2 实例的缓存都根据生成的密钥进行更新,并且 API 调用工作正常。如果可能,请详细说明您在回答中指出的“几个问题”。
    • 如果您不理解高级答案,我已经用示例更新了我的答案。请再看一遍。
    • 感谢 Rajkumar 的详细解答。他们确实有帮助。我想我理解 1,如果我不进行隔离,我从运行时的角度看不出任何问题。关于节流和缓存,我理解您的解释。关于这个的一个问题 - 如果我直接在两个 API Manager 实例之间进行集群,而不通过将每个实例划分为 pulisher、store、gateway 和 key manager 进行分布式部署,它应该可以工作,对吧?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-04-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多