API Manager. Мультиарендность¶

Мультиарендность - это подход, который позволяет нескольким пользователям (арендаторам) входить в систему и использовать один сервер/кластер изолированно от других пользователей. То есть каждый пользователь получает возможность использовать изолированную среду на общем с другими арендаторами сервере. Такой подход помогает эффективно использовать системные ресурсы, такие как память и аппаратное обеспечение, а также защищает личные данные каждого арендатора.

Вы можете зарегистрировать домены арендаторов с помощью консоли управления NEOMSA APIM .

Примечание: Когда включена мультиарендность и арендатор становится неактивным в течение длительного периода времени (по умолчанию 30 минут), арендатор выгружается из памяти сервера. После этого он должен снова войти в систему, прежде чем отправлять запросы на сервер.

Вы можете изменить период времени бездействия, заданный по умолчанию, добавьте свойство java -Dtenant.idle.time=<time_in_minutes> в скрипт запуска продукта (./api-manager.sh файл для Linux и api-manager.bat для Windows), как показано ниже:

JAVA_OPTS \

-Dtenant.idle.time=30 \

Архитектура

Многопользовательская архитектура продуктов NEOMSA APIM позволяет разворачивать веб-приложения, веб-сервисы, медиаторы ESB, мэшапы и другие компоненты в среде, которая поддерживает следующие возможности:

Изоляция арендатора: у каждого арендатора есть свой собственный домен, недоступный для других арендаторов.
Изоляция данных: каждый арендатор может безопасно управлять своими данными в изолированном режиме.

Арендатор — это изолированный домен. Пользователи внутри этого домена могут управлять своими данными и выполнять свои транзакции, не будучи затронутыми действиями, происходящими в других доменах.

Этим доменам выделяется серверное пространство из общего серверного пространства продукта NEOMSA APIM , который называется суперарендатором.

Суперарендатор, как и каждый отдельный арендатор, имеет свой собственный модуль конфигурации и контекста.

Каждый арендатор имеет свой собственный домен безопасности, он включает пользователей и их разрешения на доступ к ресурсам. Таким образом, арендатор ограничен пользователями и разрешениями домена, назначенными ему. Репозитории артефактов арендаторов отделены друг от друга.

Отдельный арендатор может выполнять следующие действия в рамках своего модуля конфигурации и контекста:

Развертывание артефактов
Применение мер безопасности
Управление пользователями
Управление данными
Ограничение количества запросов
Кэширование ответов

NEOMSA Carbon предоставляет ряд служб администратора, с привилегиями для управления сервером. Эти службы развернуты в суперарендаторе, и другие арендаторы могут использовать их для управления своими ресурсами. Административные сервисы работают с учётом арендатора, поэтому при использовании любого административного сервиса учитываются привилегии и ограничения, применяемые к клиенту.

Совместное использование ресурсов.

NEOMSA Carbon поддерживает следующий метод распределения ресурсов между арендаторами:

Собственная многопользовательская среда: этот метод позволяет всем арендаторам совместно использовать один экземпляр JVM. Этот метод минимизирует накладные расходы.

Политика загрузки арендатора

Lazy loading — это шаблон проектирования, который используется в облачных системах для отсрочки инициализации объекта или артефакта до тех пор, пока он не будет запрошен арендатором или внутренним процессом. В продуктах NEOMSA на основе Carbon 4.6.0 или более поздних версий уже есть возможность задать требуемую политику загрузки арендатора: включив либо Lazy Loading, либо Eager Loading арендаторов. Вы также можете отдельно настраивать политику загрузки для веб-приложений и служб axis2, развернутых в ваших арендаторах, используя настройку GhostDeployment.

Ограничения

Следующие ограничения вводятся для того, чтобы обеспечить, необходимый уровень изоляции и детальный контроль безопасности своих собственных служб, для каждого отдельного арендатора, не влияя на других арендаторов.

Только суперарендатор может изменять свою конфигурацию, а также добавлять, просматривать и удалять арендаторов.
Когда арендатор входит в систему, он может получить доступ только к артефактам, развернутым в его собственной конфигурации. Один арендатор не может изменять код другого арендатора.
Суперадминистратор или администратор арендатора может добавлять хранилища пользователей в свой собственный домен. Динамические конфигурации возможны только для вторичных хранилищ пользователей, а основное хранилище не изменяется во время выполнения. Это связано с тем, что основные хранилища пользователей доступны для всех арендаторов, и разрешение изменений конфигурации во время выполнения может привести к нестабильности системы. Поэтому основное хранилище пользователей является статическим и должно быть настроено до начала работы.
Код арендатора не может вызывать чувствительные функции на стороне сервера, благодаря механизмам безопасности Java.
Арендаторы используют транспортные механизмы, предоставленный системой, и не имеют возможности создавать собственные.

Диспетчеризация запросов

В этом разделе описывается, как работает многоарендная архитектура при диспетчеризации запросов.

Когда сервер Carbon получает запрос, сообщение сначала принимается обработчиками и диспетчерами, определенными для конфигурации сервера (суперарендатором). Конфигурация сервера может включать обработчики, реализующие межарендные политики и управление соглашениями об уровне обслуживания (SLA). Например, на этом этапе может применяться диспетчер с приоритетной очередью, обеспечивающий разный уровень качества обслуживания для различных клиентов. После применения соответствующих обработчиков и диспетчеров запрос отправляется арендатору, которому он адресован. Затем применяются диспетчеры и обработчики сообщений, специфичные для этого арендатора.

Следующий пример показывает, как осуществляется отправка сообщений на многопользовательском сервере.

Например, два арендатора с именами foo.com и bar.com могут развернуть службу с именем MyService. Когда эта служба размещена на двух арендаторах, они будут иметь следующие URL-адреса.

http://example.com/t/foo.com/services/MyService http://example.com/t/bar.com/services/MyService

Имя арендатора в URL позволяет определить арендатора, когда сервер Carbon получает сообщение, адресованное определенному клиенту. Также можно настроить запись CNAME в DNS (система доменных имен) в качестве псевдонима для этой информации.

Если запрос адресован службе MyService размещенной на foo.com, сначала применяются обработчики сообщений и диспетчеры суперарендатора, а затем идентифицируется арендатор foo.com по имени в URL. После этого запрос направляется на foo.com, где он будет обработан.

Масштабирование

Архитектура многопользовательской аренды, описанная выше, в основном относится к сценарию, в котором один экземпляр сервера Carbon действует как один многопользовательский узел. Однако, когда количество запросов становится очень высоким, может возникнуть необходимость в нескольких узлах для обработки нагрузки. Для работы с несколькими многопользовательскими узлами требуется балансировка нагрузки. При этом балансировщик нагрузки также должен быть осведомлен о арендаторах.