Оцелот - Динамическая конфигурация агрегата в реальном времени

Содержание

Вопрос или проблема
Ответ или решение
1. Расширение регистрации сервисов через API Ocelot Gateway Administration
2. Интеграция логики в пользовательский Middleware
3. Ручная реализация контроллера для агрегации
4. Предоставление пользовательской реализации IServiceDiscovery
5. Фоновый рабочий процесс для обновления конфигурации
Рекомендации

Вопрос или проблема

Я использую Ocelot вместе с Consul для выполнения динамической маршрутизации, что отлично работает. Кроме того, я настраиваю агрегации, такие как:

{
  "Aggregates": [
    {
      "UpstreamPathTemplate": "/modules/dashboard/options",
      "RouteKeys": [
        "ServiceADashboardOptions",
        "ServiceBDashboardOptions"
      ],
      "Aggregator": "ArrayAggregator"
    }
}

Это отлично работает. Тем не менее, я хотел бы динамически определять маршруты, которые будут использоваться для агрегации, основываясь на тегах, которые имеет сервис, когда он используется в Consul.

В приведённом выше примере сервис с тегом “dashboard” должен быть автоматически учтён для агрегации. Я не знаю, какие сервисы существуют и как они называются на момент конфигурации, но если они реализуют функцию, то шаблон маршрута определён.

Я вижу следующие возможности для достижения этого поведения:

Расширение регистрации сервиса с использованием Ocelot Gateway Administration API для обновления конфигурации во время регистрации сервиса
Внедрение логики в пользовательский Middleware в конвейер запросов Ocelot
Введение контроллера вручную в проект Ocelot и выполнение агрегации “вручную” после запроса реестра сервисов
Попытка предоставить пользовательскую реализацию IServiceDiscovery и переопределить реализацию PollConsul с добавлением конфигурации Aggregate
Добавление фонового рабочего сервиса, который запрашивает реестр сервисов и обновляет файлы агрегации на диске
…

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

Ответ или решение

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

1. Расширение регистрации сервисов через API Ocelot Gateway Administration

Этот метод подразумевает использование API Ocelot для динамического обновления конфигурации маршрутов во время регистрации сервисов. С одной стороны, это удобно, так как вы сможете моментально информировать Ocelot о новых сервисах. Однако, этот подход может усложнить архитектуру, так как потребуется обеспечить правильное взаимодействие между системой регистрации и Ocelot. Вам потребуется обработка событий регистрации сервисов, что может усложнить код.

2. Интеграция логики в пользовательский Middleware

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

3. Ручная реализация контроллера для агрегации

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

4. Предоставление пользовательской реализации IServiceDiscovery

Пользовательская реализация интерфейса IServiceDiscovery, с переопределением метода PollConsul, может быть подходящим решением. Это позволит вам встроить логику агрегации прямо в процесс получения информации о сервисах. Этот подход может быть очень мощным, но требует глубокого понимания внутренней работы Ocelot и Consul.

5. Фоновый рабочий процесс для обновления конфигурации

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

Оцелот – Динамическая конфигурация агрегата в реальном времени