WSO2 API Manager v1.8.0 - Кластеризация

Question

У меня вопрос о кластеризации диспетчера WSO2 API. Я подробно рассмотрел документацию по развертыванию и понимаю концепцию распределенного развертывания, в которой можно разделить издателя, хранилища, диспетчера ключей и шлюза. Но согласно моей оценке, это делает архитектуру развертывания довольно сложной в обслуживании. Поэтому я хотел бы иметь более простое развертывание.

Что я тестировал, так это просто иметь два разных экземпляра диспетчера API WSO2 для запуска в двух разных блоках, указывающих на одни и те же базовые источники данных в MySQL. Я видел, что API-вызовы работают отлично, а токены, полученные из одного экземпляра WSO2, будут работать для вызова API на другом экземпляре API Manager. Единственная проблема с этой моделью заключается в том, что нам нужно развернуть API-интерфейсы от отдельных компонентов издателя для количества запущенных экземпляров WSO2 API Manager. Я в порядке, потому что публикация будет сделана одной небольшой командой. У нас будет аппаратный балансировщик нагрузки, у которого есть URL-адреса конечной точки API и URL-адреса конечных точек токена как для менеджеров API, так и для гарнитуры LB будет выполнять балансировку нагрузки.

Итак, мой вопрос: есть ли какие-либо проблемы при выполнении этого простого подхода с точки зрения RUNTIME? Кластеризация добавляет какую-либо выгоду из перспективы RUNTIME для WSO2 API Manager?

спасибо.

Answer 1

Ваш подход имеет следующие недостатки (может быть больше, чего я не знаю);

• Он не является масштабируемым. Значение - вы не можете самостоятельно масштабировать (добавляя больше экземпляров) хранилище или издателя или шлюза или ключевого менеджера.

• Распределенное дросселирование не будет работать. Это приведет к несогласованности дросселирования, поскольку репликация дросселирования не произойдет, если вы не включите кластеризацию. Допустим, вы определяете уровень «Gold» для API. Неважно, сколько экземпляров шлюза вы используете, пользователю следует ограничить доступ к этому API не более чем 20руб/мин. Это должно было быть реализовано на основе распределенного счетчика (не уверены в точных деталях реализации). Поэтому, если вы не включили кластеризацию, один узел шлюза не знает количества запросов, обслуживаемых другими узлами шлюза. Поэтому каждый узел шлюза будет иметь свой собственный счетчик дроссельной заслонки. Значение - пользователь может получить доступ к вашему API более чем 20req/min. Так что это одно из дроссельных несоответствий. Кроме того, скажем, один шлюзовый узел отключен от пользователя, а другой узел шлюза - нет. Теперь, если ваш LB направляет запрос на узел 1-го шлюза, пользователь не сможет получить доступ к API. Если ваш LB направляет запрос на узел 2-го шлюза, пользователь сможет получить доступ к API. Это еще один пример дросселирования несогласованности. Чтобы преодолеть все эти проблемы, вам просто нужно реплицировать дросселирование по всем узлам шлюза, включив кластеризацию.

• Распределенное кэширование не будет работать. Например, информация о проверке ключа API кэшируется. Если вы отмените токен в одном узле API-менеджера, кэш будет очищен в этом узле. Таким образом, пользователь не может использовать отозванный токен через этот узел API-менеджера, но он может использовать токен через другой узел API-менеджера до тех пор, пока кеш не будет признан недействительным (я думаю, по умолчанию 15 минут). Это всего лишь один случай, когда все может пойти не так, если вы не кластеры экземпляров API-менеджера. Чтобы решить эти проблемы, вам просто нужно включить кластеризацию, тогда кеш будет синхронизироваться по кластеру. Прочтите this doc для получения дополнительной информации о различном кэшировании, доступном в WSO2 API Manager.

У вас будет несколько проблем, если у вас нет вышеуказанных функций. WSO2 настоятельно рекомендует распределенное развертывание в производстве.