親ポンポンとmicroservices

Question

• 我々はmicroservicesているいくつかのプロジェクトを持って、すべてのプロジェクトは、独立して（別のDBスキーマを使用して、残りのサービスを公開する、独立したスプリングブートサーバー上で実行されている...）
• 我々が管理するためにMavenを使います依存関係。

モジュールとして各マイクロサービスを宣言する親のpomを持つことをお勧めしますか？そして、共通の依存関係を管理するのに役立ちます（lib servlet-apiのようなものは、すべてのプロジェクトで使用され、すべてのプロジェクトを削除して親のpomのみで宣言します）

Answer 1

「問題」は、モジュールの親pomは、複雑なプロファイルがなくても同じリリースサイクルでモジュールをロックすることです（Release Pluginを使用していると仮定します）。 （APIは、JUnitの、などをロギング）

• 共通の依存関係：
  は

  私はMavenのと仕事の進め方は宣言する親ポンポンを持っていることです。

• 共通のプラグイン。
• dependencyManagementセクションのすべての依存関係。
• pluginManagementセクションのすべてのプラグイン。

各モジュールは、親のpomをその親としてdelcaresするが、親はモジュールについて何も知らない。

上記の最後の2つの箇条書きの「管理」セクションのメリットがあります。特定の依存関係やプラグインを使用するモジュールで、「管理」セクションに含まれるものはすべて再宣言する必要があります。

<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> 

、モジュールは次のようになります：

<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> 

モジュールは、でしょう：親は次のようになります。例えば

• はorg.slf4j:slf4j-api:1.7.7:compileに依存しています、 junit:junit:4.11:testおよびcommons-lang:commons-lang:2.6:compile。
• 私は親のポンポンに依存を避けるだろうプラグインorg.apache.maven.plugins:maven-assembly-plugin:2.4

Answer 2

を持っています。あなたの（独立した）マイクロサービスの1つが他のものを欲しがるのは厄介です。親が各マイクロサービスについて知っていることは変です。

dependencyManagementに固執することで、必要に応じてデフォルトのバージョン/スコープを提案することができます。親のpomは、プラグインやリポジトリなどを定義するのに非常に便利ではありません。

代わりに、共通の依存関係のセットを、特定のアーティファクトにグループ化します。これは、依存関係を持つ単一のpomである可能性があります。次に、 "com.example/common-db-dependencies/1.2"に依存して、hibernate、apache derby、およびJPA specのようなデータベース依存関係の標準セットを含めることができます。 （またはあなたが使っているものは何でも）。サービスはJPA/SQLを使用せず、その依存関係をすべて回避することができます。

あなた自身を絡ませないでください。それぞれのケースをカバーしようとすると、依存関係の構造がうまくいくのは簡単です。したがって、サービスの大半が実際に使用するものを標準化しようとするだけです。

Answer 3

ここでは、依存関係と依存関係管理に1つの問題があります。あなたのマイクロサービスの1つが、何らかの理由で新しいバージョンのコモンにアップグレードしたいとします。あなたは親を持っているので、そうすることはできません。私は、プラグイン設定のような重複したものの重複を減らすという誘惑を理解しています。マイクロサービスでは、各サービスの独立性についてもっと考える必要があります。

リポジトリやリリースの設定などの設定に共通するものがあります。