Маршрутизация Service Fabric (локальная) для многопользовательских контейнерных приложений

Question

Я пытаюсь получить подтверждение концепции мультитенантного контейнерного приложения ASP.NET MVC в Service Fabric.Идея состоит в том, что каждый клиент получит более 1 экземпляра приложения, распределенного по кластеру.Одна вещь, с которой у меня возникают проблемы при наложении карты - это маршрутизация.

Каждое приложение будет разделено, как этот SO-ответ .Пока что план заключается в том, чтобы внешний балансировщик нагрузки направлял каждый запрос в службу обратного прокси-сервера SF.

Так, например: tenant1.myapp.com будет перенаправлен на обратный прокси-сервер на <SF cluster node>:19081/myapp/tenant1 (19081 - порт по умолчанию для обратного прокси-сервера SF), tenant2.myapp.com -> <SF Cluster Node>:19081/myapp/tenant2 и т. Д., А затем на проксинаправит его на правильный node:port, где экземпляр приложения прослушивает.

Поскольку каждое приложение должно быть сопоставлено с другим портом, план для SF - динамически назначать порт при создании каждогоприложение.Это не кажется полностью масштабируемым, так как теоретически мы можем достичь предела порта (~ 65 КБ).

Мои вопросы, таким образом, является ли это правильным / предложенным подходом?Есть ли лучшие подходы?Есть вещи, которые я пропускаю / пропускаю?Я новичок в SF, поэтому любая помощь / понимание будут оценены!

Answer 1

Я не думаю, что ограничение эфемерного порта будет для вас проблемой, скорее всего, вы будете использовать все ресурсы сервера (ЦП + память) даже до того, как будете использовать половину этих портов.

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

Я бы не использовал встроенный обратный прокси-сервер,оно очень ограничено, и для того, что вы хотите, просто добавьте дополнительную конфигурацию без какой-либо выгоды.

В данный момент я вижу traefik как наиболее подходящее решение.Traefik позволяет вам направлять определенные домены к определенным службам, и это именно то, что вам нужно.

Поскольку вы будете использовать несколько доменов, потребуется динамическая конфигурация, которая не предоставляется "из коробки", поэтомуЯ предложил вам создать отдельное приложение для развертывания этих экземпляров.Шаги очень высокого уровня будут:

• Вы определяете свою службу с правилами по умолчанию traefik, как показано здесь
• Из вашего менеджера приложений вы развертываете новыйименованная служба этой службы для нового клиента
• После развертывания экземпляра вы настраиваете его на прослушивание в определенном домене, устанавливая для правила traefik.frontend.rule=Host:tenant1.myapp.com правильное имя клиента

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

Что касается кластерной архитектуры, вы можете сделать это разными способами, для начала, я бы порекомендовал вам сделать это простым,Тип узла FrontEnd, содержащий сервисы traefik, и другой тип узла BackEnd для ваших сервисов, оттуда вы можете решить, как правильно планировать кластер, уже есть много SO-ответов о том, как определить кластер.

См. Дополнительную информацию по следующим ссылкам:

https://blog.techfabric.io/using-traefik-reverse-proxy-for-securing-microservices-on-azure-service-fabric/

https://docs.traefik.io/configuration/backends/servicefabric/

Answer 2

Предполагая, что вам не нужен экземпляр на каждом узле, вы можете иметь до (nodecount * 65K) сервисов, что сделает его снова масштабируемым.

Посмотрите на Управление API Azure и Traefik , которые имеют некоторые опции интеграции SF.Это работает намного лучше, чем ограниченный встроенный обратный прокси.Например, они предлагают правила маршрутизации.