nadrzędna pom i microservices

Question

• Mamy kilka projektów, które są microservices, każdy projekt jest niezależny (działa na osobnym serwerze bagażnika sprężyna, wystawiając usługi odpoczynek przy użyciu oddzielnego schematu DB ...)
• Używamy maven do zarządzania zależności.

Czy dobrze jest mieć nadrzędną pompę pom deklarującą każde mikroserwisy jako moduły? A zatem pomoc w zarządzaniu wspólnymi zależnościami (jak w przypadku apletu lib servlet-api jest używana w każdym projekcie, w celu usunięcia wszystkich z nich i zadeklarowania go tylko w nadrzędnej pom)

Answer 1

"Problem" z wieloma Moduł parent parent jest taki, że bez skomplikowanych profili blokuje moduły w tym samym cyklu wydawania (zakładając, że używasz Release Plugin, którą powinieneś być).

Sposób pracuję z Maven jest mieć pom nadrzędnego, który oznajmia:

• wspólnych zależności (logowanie API, JUnit, etc).
• wspólne wtyczki.
• wszystkie zależności w sekcji dependencyManagement.
• wszystkie wtyczki w sekcji pluginManagement.

Każdy moduł niszczy rodzica pom jako jego rodzica, ale rodzic nie wie nic o modułach.

Korzyść z tego wynika z ostatnich dwóch punków powyżej, sekcji "zarządzanie". Wszystko, co znajduje się w sekcji "zarządzanie", musi zostać ponownie zadeklarowane w module, który chce użyć określonej zależności lub wtyczki.

Na przykład rodzic może wyglądać następująco:

<project> 

    <groupId>com.example</groupId> 
    <artifactId>parent</artifactId> 
    <version>1.0.00-SNAPSHOT</version> 

    ... 

    <dependencies> 

    <dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     <version>1.7.7</version> 
    </dependency> 

    <dependency> 
     <groupId>junit</groupId> 
     <artifactId>junit</artifactId> 
     <version>4.11</version> 
     <scope>test</scope> 
    </dependency>    

    </dependencies> 

    <dependencyManagement> 

    <dependency> 
     <groupId>commons-lang</groupId> 
     <artifactId>commons-lang</artifactId> 
     <version>2.6</version> 
    </dependency>   

    <dependency> 
     <groupId>commons-collections</groupId> 
     <artifactId>commons-collections</artifactId> 
     <version>2.1</version> 
    </dependency> 

    </dependencyManagement> 

    <plugins> 

    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-compiler-plugin</artifactId> 
     <version>3.1</version> 
     <configuration> 
     <source>1.8</source> 
     <target>1.8</target> 
     </configuration> 
    </plugin> 

    <plugins> 

    <pluginManagement> 

    <plugins> 

     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-assembly-plugin</artifactId> 
     <version>2.4</version> 
     <configuration> 
      <appendAssemblyId>false</appendAssemblyId> 
      <descriptors> 
      <descriptor>src/main/assembly/assembly.xml</descriptor> 
      </descriptors> 
     </configuration> 
     <executions> 
      <execution> 
      <id>make-assembly</id> 
      <phase>package</phase> 
      <goals> 
       <goal>single</goal> 
      </goals> 
      </execution> 
     </executions> 
     </plugin> 

    </plugins> 

    </pluginManagement> 

</project> 

I moduł może wyglądać następująco:

<project> 

    <parent> 
    <groupId>com.example</groupId> 
    <artifactId>parent</artifactId> 
    <version>1.0.00-SNAPSHOT</version> 
    </parent> 

    <groupId>com.example</groupId> 
    <artifactId>module</artifactId> 
    <version>1.0.00-SNAPSHOT</version> 

    <dependencies> 

    <dependency> 
     <groupId>commons-lang</groupId> 
     <artifactId>commons-lang</artifactId>   
    </dependency>   

    </dependencies> 

    <plugins> 

    <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-assembly-plugin</artifactId> 
    </plugin> 

    </plugins> 

</project> 

Moduł będzie:

• mieć współzależności na org.slf4j:slf4j-api:1.7.7:compile, junit:junit:4.11:test i commons-lang:commons-lang:2.6:compile.
• ma wtyczki org.apache.maven.plugins:maven-assembly-plugin:2.4

Answer 2

Wolałbym uniknąć zależności w pom nadrzędnej. To niezręczne, jeśli jedno z twoich (niezależnych) mikroserwisów chciałoby innych rzeczy. To dziwne, że rodzic wie o każdej mikroserwisie.

Możesz trzymać się za pomocą narzędzia dependencyManagement, aby sugerować domyślne wersje/zakresy, jeśli chcesz. Nadrzędny pom jest, nie mniej jednak, bardzo wygodny do definiowania wtyczek, repozytoriów i tym podobnych.

Zamiast tego zgrupowałbym wspólny zestaw zależności w konkretny artefakt (s), który może być tylko pojedynczym pom z zależnościami. Następnie możesz polegać na, powiedz "com.example/common-db-dependencies/1.2", aby dołączyć standardowy zestaw zależności baz danych, takich jak hibernacja, apache derby i specyfikacje JPA. (lub cokolwiek, czego używasz). Usługa nie używa formatu JPA/SQL, aby uniknąć tej zależności.

Nie splącz się jednak. Łatwo przepracować strukturę zależności, jeśli próbujesz objąć każdy przypadek. Tak więc, spróbuj tylko ujednolicić rzeczy, które naprawdę są używane przez większość usług.

Answer 3

Oto jeden problem z zarządzaniem zależnościami i zależnościami. Powiedzmy, że jedna z twoich mikro serwisów chce z jakiegoś powodu uaktualnić się do nowszej wersji popularnej ... nie możesz tego zrobić, ponieważ masz rodzica. Rozumiem pokusę ograniczenia duplikowania zbędnych elementów, takich jak konfiguracja wtyczki. W przypadku usługi mikro musimy zastanowić się nad niezależnością każdej usługi.

Niektóre konfiguracje mówią, że konfiguracja twojego repozytorium lub wydania itp. Może być powszechna.