Несколько экземпляров службы kestrel без сохранения состояния, запущенных на разных портах в сервисной матрице

Question

Я создал службу без сохранения состояния в Visual Studio 2019, используя пример значений по умолчанию (Создать новый проект -> Сервис Fabri c Приложение -> назвать проект и решение -> Без сохранения состояния ASP. NET Базовая служба).

Запуск приложения прогноза погоды без изменений работает нормально, я вижу приложение, работающее в обозревателе Service Fabri c, и вижу мои 5 исправных узлов (локальная разработка) и 1 зеленое приложение.

Если я изменю Local.5Node.xml, чтобы изменить InstanceCount с 1 на -1

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/SampleApp" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="SampleApp_ASPNETCORE_ENVIRONMENT" Value="Development" />
    <Parameter Name="SampleApp_InstanceCount" Value="-1" />
  </Parameters>
</Application>

Я вижу под одним разделом пять созданных экземпляров, но четыре из них застряли в InBuild:

И в моем работающем приложении в VS2019 окно Диагностика показывает процессы, которые постоянно не запускаются:

При дальнейшей проверке я вижу, что новые экземпляры пытаются развернуться на том же порту.

Как работает назначение портов в Service Fabri c с несколькими экземплярами веб-служб без сохранения состояния? Требуется ли шлюз с обратным прокси для обнаружения каждого экземпляра? Возможно ли автоматическое масштабирование веб-службы без сохранения состояния в Service Fabri c без специальных решений?

Answer 1

Kestrel не поддерживает совместное использование портов, поэтому, как только одна служба запрашивает порт, другие, работающие на той же машине (здесь: ваша машина разработки), не могут.

Самый простой способ - создать 1 экземпляр вашей службы при работе в вашем кластере dev. Другой способ обойти это, это использовать (случайные) назначенные SF порты локально:

Полностью пропустить конфигурацию конечной точки в ServiceManifest.xml и не передавать имя конечной точки в KestrelCommunicationListener Конструктор

Далее, используйте (например, встроенный ) обратный прокси-сервер для связи с вашими услугами.

Подробнее здесь