Один микросервис, выполняющий много преобразований, или много микросервисов, выполняющих одно преобразование?

Question

У меня есть служба, которая преобразует XML-документы. Он получает сообщения из N очередей и в зависимости от того, из какой очереди он получает сообщение, выполняет одно из преобразований.

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

Я делаю это в .NET Core 2.2. Я пока не знаю, будем ли мы использовать docker-swarm или kubernetes для производства.

1. Я мог бы просто оставить большую часть кода, как сейчас, и запустить его как один контейнер. AppSettings.config будет содержать настройки для каждой пары очередь-преобразование.

   Плюсы, которые я вижу: Требуется меньше изменений кода и упрощение docker-compose - один сервис вместо N. Только один файл конфигурации.

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

2. Я мог бы провести рефакторинг кода и создать N различных изображений контейнеров. Каждый из них прослушивал одну очередь и выполнял одно преобразование. Я могу сделать так, чтобы единственная разница в коде заключается в запуске при регистрации сервисов. На основании конфигурации я мог зарегистрировать один из IXmlTransformers.

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

   Минусы: В некоторых средах будет около 10 различных преобразований, поэтому Там будет много конфигурационных файлов - возможно, добавленных в каждый работающий контейнер с использованием тома? Составление докера будет очень долгим.

   Что может быть лучше для этого? Или, может быть, есть другие лучшие варианты?

Edit:

Мне кажется, я не совсем понял свой вопрос, поэтому я пытаюсь объяснить его лучше. В обоих вариантах у меня будет одно изображение контейнера. Разница будет во время выполнения. Только конфигурация будет другой. Допустим, я преобразую XML в CSV или XML в XML с помощью XSLT. Формат CSV и XSLT являются частью конфигурации. У меня может быть много форматов CSV (много конфигураций) и много разных XSLT (опять же много конфигураций) Итак, у меня есть две реализации ITransformer (CSV, XSLT), и они читают конфигурацию, чтобы выполнить свои преобразования. И у меня вопрос: лучше ли иметь один запущенный экземпляр контейнера для одной конфигурации или поместить все эти конфигурации в один контейнер, который отслеживает N очередей или одну очередь и читает какие-то метаданные, чтобы решить, какое преобразование запустить.

Answer 1

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

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

Answer 2

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

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

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

Альтернатива ручного масштабирования на основе очередей может превратиться в кошмар администратора.