Дифференцировать логику микросервиса по конфигурации или новому сервису

Question

У нас есть конвейер обработки данных, куда мы получаем данные из разных источников. Весь конвейер реализован с использованием Event Driven Architecture и микросервисов. Одна из служб имеет три отдельные задачи. Два из них полностью распространены в разных источниках данных, но объем третьей задачи может немного измениться в зависимости от того, что является нашим источником данных. Например, для одного источника уникальная подпись может быть рассчитана на основе filed1 и filed2, а для другого источника она может быть рассчитана на основе field2 и field3. Как наилучшим образом внедрить этот сервис в соответствии с принципами гранулярности микросервисов?

Мне на ум пришло три подхода:

1) Создайте один сервис и используйте разные реализации для каждого источника (например, шаблон проектирования фабрики) В зависимости от источника, одна из реализаций будет использоваться во время выполнения.

Плюсы: меньшее количество услуг. Меньше сложности

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

2) Разбейте эту службу на две службы, используйте одну для всех источников и переопределите извлеченную службу для каждого источника данных.

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

Минусы: больше сервисов, и поскольку сервисы будут слишком маленькими, в будущем мы можем столкнуться с проблемой наносервиса.

3) Не изменяйте гранулярность служб, но создавайте разные экземпляры службы во время выполнения. Каждый со своим конфигом для указания набора полей для каждого источника. В этом случае код является общим, но экземпляры времени выполнения различаются в зависимости от того, к какому источнику он принадлежит.

Плюсы: меньшее количество услуг и отсутствие операционной зависимости

Минусы: перенесите сложную логику во время выполнения, что может усложнить развертывание и операции

Answer 1

Я согласен с Адрианом, это зависит от вашей ситуации.

Я думаю, что наиболее важным является сложность системы - она ​​играет важную роль в тестировании, поддержке и развитии системы.(KISS)

Так что я думаю, что лучшим вариантом будет 2.

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

Answer 2

Я думаю, что больше всего беспокоюсь о типе результата, который приносят услуги. Если (для всех 3 опций) результатом процесса будет тот же тип (или объект домена), я, безусловно, предпочту Вариант 1 .

Это соответствовало бы принципу «слабой связи, связного поведения», о котором Сэм Ньюман писал в своей книге .

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

Связанное поведение, поскольку один сервис применяет бизнес-логику к событиям и, следовательно, создает надежно связанные события с согласованной типой / семантикой.

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

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

Эта Услуга действительно будет зависеть от производителя, поскольку она нуждается в нем в качестве источника. Нет способа обойти это. То же самое будет справедливо для всех других вариантов в некоторой степени. Но зависимость , потребитель зависит от производителя , а не наоборот!

Answer 3

Это зависит. К вашему сведению, я знаю Кафку, но не имею опыта в этом.

Для варианта 3 : насколько зрела ваша способность управлять различными экземплярами решения с различной конфигурацией? Сколько будет таких случаев? Как бы вы могли наблюдать за состоянием здоровья, поведением и работоспособностью всех инстанций?

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

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

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

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

Обновление - опция 2

Это означает наличие нескольких служб для обработки некоторых запросов (но не других), поэтому теперь вам необходимо управлять как потоком между службами (во время выполнения), так и взаимозависимостями между ними (при разработке, во время развертывания); сложнее проверить.

Микросервисы - это частично независимые сервисы - второй вариант на самом деле не соответствует этому этосу - это нормально, просто осознайте, что это не просто микросервис, в зависимости от того, насколько конкретно вы относитесь к таким вещам.