Как отделить существующие сервисы?

Question

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

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

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

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

ESB: - Не обязательно просто отделить существующие сервисные вызовы, ESB - хороший способ?

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

Answer 1

Вы спрашиваете об удалении зависимости classpath, или вы должны выбрать ESB, микро-сервисы. Последнее звучит как что-то вроде обсуждения, которое вы должны вести в своем бизнесе, а не вопроса SO.

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

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