Я был в той же лодке, когда начал использовать микро-сервисы на работе.
Мы определили следующие "общие" места.Этот список, конечно, не полный, но просто для того, чтобы дать представление:
- Инфраструктура обмена сообщениями (производитель / потребитель, pub-sub), как в вашем случае
- Измерительная инфраструктура (некоторые расширения)мы использовали для микрометра)
- Регистрация конфигураций (одни и те же приложения, шаблоны, немного другое поведение для машин Windows / Linux / Mac OS и т. д.)
- Расширения исполнительных механизмов пружины (дополнительные конечные точки)
- Обработка ошибок
- Расширения конфигурации реляционной базы данных (проверки работоспособности привода, некоторые расширения драйверов и т. Д.)
Решение, с которым мы пришлиэто предоставить другой тип артефакта с точки зрения maven.Это будет упаковочная банка и вообще не будет зависеть от пружинной загрузки (кроме необходимых частей, таких как API привода, если требуется).
Мы создали модуль maven для каждого элемента из вышеупомянутого списка, который сам по себеимел @Configuration, что смог загрузить все необходимые бины.Если вы хотите, чтобы это было решено с "автоконфигурацией", рассмотрите использование "весенних фабрик".Мы использовали этот метод, и он отлично работал для нас.В качестве альтернативы, если вы хотите быть более явным, вы можете создать аннотацию, такую как @EnableXYZ, которая по существу импортирует конфигурацию модуля jar:
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import({CommonErrorHandlingConfiguration.class})
public @interface EnableErrorHandling {
}
...
@Configuration
public class CommonErrorHandlingConfiguration {
// beans relevant for error handling appear here
}
В этом примере есть модуль с именем common-error-handling и содержит оба вышеупомянутых класса.
Теперь ваши микро-сервисы имеют его как зависимость и могут использовать эту аннотацию @EnableErrorHandling для активации CommonErrorHandlingConfiguration
Мы такжевыяснили, что есть два вида общих библиотек, подобных этой.Что-то, что относится ко всем микросервисам (например, регистрация, измерение и т. Д.), И что-то, что может относиться к одному микросервису и совершенно не относится к другому.
Итак, в качестве решения мы сделали все наши банки типа микросервисов (с подпружиненным загрузочным плагином, интеграционным тестированием и т. д.) из одного «общего микросервиса» pom.xml, который фактически определил все эти общие зависимости.
Таким образом, не было необходимости переопределять зависимости для каждого микросервисаесли они актуальны для всех услуг.
Стоит также упомянуть, что этот подход может работать только до тех пор, пока все микросервисы используют одну и ту же технологию, в противном случае использование контейнеров-колясок может быть более подходящим для тех жеслучай.