Шаблон шлюза / прокси API для микросервисов, развернутых с помощью Azure Service Fabric

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

Теперь вам нужно заполнить «шлюз», с которым взаимодействуют пользователи. Это не обязательно должно быть с отслеживанием состояния, потому что служба именования управляет частью с отслеживанием состояния. Но вам нужно будет придумать схему адресации, которая будет работать для вас, а затем она будет просто перенаправлять запросы в нужное место. В основном примерно так:

1. Получите запрос.
2. Используйте NS, чтобы найти службу, которая может принять запрос.
3. Отправьте ему запрос, а ответ - пользователю.
4. Если служба больше не существует, 404.

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

Для этой цели мы также реализовали сервис HTTP-шлюза. Чтобы убедиться, что у нас может быть один HTTP-шлюз для любого внутреннего протокола, мы реализовали шлюз для внутренних служб на основе HTTP (таких как ASP.NET WebAPI) с помощью промежуточного программного обеспечения ASP.NET 5. Он направляет запросы, например, из / service на внутренний адрес Service Fabric, например fabric: / myapp / myservice, используя ServicePartitionClient и некоторую логику повторных попыток из CommunicationClientFactoryBase.

Мы открыли исходный код этого промежуточного программного обеспечения, и вы можете найти его здесь: https://github.com/c3-ls/ServiceFabric-HttpServiceGateway

В вики проекта также есть дополнительная документация.

Эта функция встроена для конечных точек http, начиная с версии 5.0 Service Fabric. Документация доступна по адресу https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/

Мы использовали проект с открытым исходным кодом под названием Traefik с поразительным успехом. Вокруг него есть оболочка Azure Service Fabri c - по сути, это GoLang exe. который развертывается в кластере как управляемый исполняемый файл.

Он поддерживает автоматические выключатели, взвешенный круговой алгоритм LB, маршрутизацию путей и версий заголовков (это замечательно для размещения нескольких версий API), список можно продолжить. И у него есть удобный портал для просмотра статистики и статистики здоровья.

Реальная сила в этом заключается в том, как вы его настраиваете. Это делается через сам сервис в ServiceManifest.xml. Это позволяет вам развертывать новые сервисы и иметь возможность немедленно перенаправить их - нет необходимости обновлять таблицу маршрутизации и т. Д.

Пример

<StatelessServiceType ServiceTypeName="WebServiceType">
  <Extensions>
      <Extension Name="Traefik">
        <Labels xmlns="http://schemas.microsoft.com/2015/03/fabact-no-schema">
          <Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
          <Label Key="traefik.enable">true</Label>
          <Label Key="traefik.frontend.passHostHeader">true</Label>
        </Labels>
      </Extension>
  </Extensions>
</StatelessServiceType>

Настоятельно рекомендуется!

Azure Service Fabric упрощает реализацию стандартной архитектуры для этого сценария: служба шлюза в качестве внешнего интерфейса для клиентов, к которым они могут подключаться, и все N серверных служб, взаимодействующих с интерфейсным шлюзом. В составе Service Fabric доступно несколько стеков API связи, которые упрощают обмен данными между клиентами и службами и внутри самих служб. Стеки API связи, предоставляемые Service Fabric, скрывают подробности обнаружения, подключения и повторных попыток подключения, чтобы вы могли сосредоточиться на фактическом обмене информацией. При использовании API связи Service Fabric службы не должны реализовывать механизм регистрации своих имен и конечных точек в конкретной службе маршрутизации, за исключением обычных шагов в рамках создания самой службы. Коммуникационные API принимают URI службы и ключ раздела, автоматически разрешают и подключаются к нужному экземпляру службы. Эта статья обеспечивает хорошую отправную точку для принятия решения относительно того, какие коммуникационные API-интерфейсы лучше всего подходят для вашего конкретного случая, в зависимости от того, используете ли вы Reliable Actors или Reliable Services, или такие протоколы, как HTTP или WCF, или от выбора языка программирования. в которых написаны службы. В конце статьи вы найдете ссылки на более подробные статьи и руководства по различным коммуникационным API. Учебное пособие по обмену данными в службах веб-API см. На странице это.

Мы используем SF с шаблоном шлюза и около 13 сервисов за шлюзом. Мы используем встроенную службу DNS, которую предоставляет SF, см. https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-dnsservice, это позволяет внутренней службе обслуживать вызовы с известными (внутренними для SF) DNS-именами, включая шлюз к внутренним службам. Есть несколько хорошо известных основных шлюзов asp.net (Ocelot, ProxyKit), но мы сделали собственные. У нас есть внешний балансировщик нагрузки для маршрутизации к нескольким экземплярам шлюза в SF.

Когда служба запускается, она регистрирует свою конечную точку в службе именования фабрики. Затем с помощью клиентских API Fabric вы можете запросить у Fabric зарегистрированные конечные точки, связанные с зарегистрированным именем службы.

Итак, да, как вы описали свой случай, у вас будет шлюз, который будет принимать входящий URI для подключения, а затем использовать эту информацию о пути в качестве поиска имени службы, чтобы затем создать прокси-соединение между входящим запросом и фактическим внутренним расположение конечной точки.

Похоже, команда опубликовала один из примеров, в котором показано, как это сделать: https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount

Мне интересно, вместо того, чтобы открывать Rest at N + services, используйте стек связи по умолчанию везде внутри служебной фабрики (или, насколько это возможно, чтобы все было просто внутренне). Выставляйте REST только в краевых точках входа в ткань. Используйте стандартный API-интерфейс web 2.x без сохранения состояния, который обертывает прокси-серверы структуры ваших служб и субъектов, и / или используйте службу фабрики, предоставляющую остальное таким же образом. Агрегируйте свои API по мере необходимости в обращенных вперед сервисах Rest. Не уверен, что я еще видел необходимость в дополнительных накладных расходах агрегатора для перенаправления имен (возможно, я упускаю эту мысль). Тогда это могло бы показаться просто упражнением в организации (и обеспечении) конечных точек покоя с желаемым пространством имен (то есть шаблоном фасада).