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

Использование своего parent pom

В большинстве случаев, готовые сборки зависимостей (например, spring-boot-starter-parent или напрямую spring-boot-dependencies) используются в pom файлах как parent. Но что, если в нескольких микросервисах нужно переопределить версию одной из зависимостей или добавить ту, которой в сборке нет?

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

Делается своя сборка довольно просто с помощью менеджмента зависимостей. Также можно импортировать уже готовые сборки зависимостей. Удобнее всего выносить версии библиотек в переменные. Это поможет проще переопределять версию зависимости в конкретном микросервисе в случае крайней необходимости.

<properties>
  <java.version>17</java.version>
  <json.version>20231013</json.version>
  <spring-parent.version>3.1.5</spring-parent.version>
</properties>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>{json.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>

В случае с плагинами вы также можете контролировать их версии:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.jsonschema2pojo</groupId>
        <artifactId>jsonschema2pojo-maven-plugin</artifactId>
        <version>${jsonschema2pojo.version}</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

Для того, чтобы использовать ваш parent pom в микросервисе, необходимо опубликовать его в локальном репозитории командой mvn install (или же в другом хранилище, например, nexus). Далее нужно указать parent в вашем микросервисе и подключить нужные зависимости без указания версий:

<parent>
  <groupId>com.example</groupId>
  <artifactId>base-pom</artifactId>
  <version>0.0.1-SNAPSHOT</version>
</parent>
<dependencies>
  <dependency>
    <groupId>org.json</groupId>
    <artifactId>json</artifactId>
  </dependency>
</dependencies>

Полезные ссылки

Комментарии (6)


  1. LeshaRB
    23.10.2023 18:40
    +1

    Я даже подсказку дам
    Если в наследника добавить

    <properties>
      <spring-parent.version>3.1.X</spring-parent.version>
    </properties>
    

    Он переопределит версию parent
    Но все равно не понятен смысл данной статьи


    1. gromspys Автор
      23.10.2023 18:40

      Не очень понятно что вы имеете ввиду под подсказкой. В статье упомянуто:

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

      Вы описали пример того, как это сделать или у вас вопрос по тому, что в наследнике можно переопределять версии парента?


  1. Neuronix
    23.10.2023 18:40
    +2

    Делайте хорошо, а плохо не делайте. Для кого статья? Для джунов? Так они не решают архитектурный вид микросервисов


    1. gromspys Автор
      23.10.2023 18:40

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


  1. Nialpe
    23.10.2023 18:40

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


    1. gromspys Автор
      23.10.2023 18:40

      Конечно приходилось. Поэтому автор указал тэги java и maven. Естественно, если в системе микросервисы на JavaScript, PHP и тд, то какой тут maven?