WSO2 API Manager v1.8.0-群集

Question

我對WSO2 API管理器群集有疑問。 我已經詳細閱讀了部署文檔，並了解了分布式部署概念，在其中可以隔離發布者，商店，密鑰管理者和網關。 但是根據我的評估，這使得部署架構的維護相當復雜。 所以我想有一個更簡單的部署。

我測試過的是簡單地讓WSO2 API Manager的兩個不同實例在兩個不同的框中運行，指向MySQL中相同的基礎數據源。 我所看到的是，API調用可以正常工作，並且從一個WSO2實例獲取的令牌可以在另一個API Manager實例上進行API調用。 此模型的唯一問題是，我們需要為運行的WSO2 API Manager實例從各個發布者組件中部署API。 我這樣做很好，因為發布將由一個小團隊完成。 我們將在前面有一個硬件負載平衡器，其中API管理器的API端點URL和令牌端點URL均由API管理器和harware LB進行負載平衡。

所以我的問題是-從RUNTIME角度來看，采用這種簡單方法是否存在任何問題？ 從RUNTIME角度來看，群集是否為WSO2 API Manager帶來了任何好處？

謝謝。

Answer 1

您的方法具有以下缺點（可能還有更多我不知道的缺點）；

• 它不可擴展。 含義-您無法獨立擴展（添加更多實例）商店或發布者，網關或密鑰管理器。

• 分布式節流將不起作用。 這將導致限制不一致，因為如果不啟用群集，則限制復制將不會發生。 假設您為API定義了“黃金”層。 不管您使用多少個網關實例，都應限制用戶對該API的訪問速度不得超過20req / min。 這應該已經基於分布式計數器實現了（不確定確切的實現細節）。 因此，如果您未啟用群集，則一個網關節點將不知道其他網關節點服務的請求數。 因此，每個網關節點將有自己的油門計數器。 含義-用戶可能能夠以超過20req / min的速度訪問您的API。 因此，這是限制的矛盾之一。 此外，可以說一個網關節點被限制了一個用戶，而另一網關節點則沒有。 現在，如果您的LB將請求路由到第一個網關節點，則用戶將無法訪問API。 如果您的LB將請求路由到第二個網關節點，則用戶將能夠訪問API。 這是限制不一致的另一個實例。 為了克服所有這些問題，您只需要通過啟用群集就可以在所有網關節點之間復制限制。

• 分布式緩存不起作用。 例如，API密鑰驗證信息被緩存。 如果您在一個API Manager節點中吊銷令牌，則將在該節點中清除緩存。 因此，用戶無法通過該API Manager節點使用已撤消的令牌，但是他可以通過另一個API Manager節點使用令牌，直到緩存無效（我猜默認為15分鍾）。 這只是一個實例，如果您不對API Manager實例進行群集，則會出錯。 要解決這些問題，您只需啟用集群，然后緩存將在集群中同步。 閱讀此文檔以獲取有關WSO2 API管理器中可用的各種緩存的更多詳細信息。

如果沒有上述功能，您將遇到幾個問題。 WSO2強烈建議在生產中進行分布式部署。