2015-01-09 16 views
12
  • Chúng ta có nhiều dự án được microservices, mỗi dự án được độc lập (chạy trên máy chủ khởi động mùa xuân riêng biệt, phơi bày các dịch vụ nghỉ ngơi, sử dụng giản đồ DB riêng biệt ...)
  • Chúng tôi sử dụng maven để quản lý phụ thuộc.

Có ý tưởng tốt để có một pom mẹ khai báo mỗi microservices là mô-đun? Và do đó giúp quản lý các phụ thuộc chung (như lib servlet-api phù thủy được sử dụng trong mọi dự án, để loại bỏ nó của tất cả chúng và tuyên bố nó trong chỉ cha mẹ pom)pom mẹ và microservices

+0

Bạn có thể vui lòng chia sẻ liên kết về cách thiết lập dự án với Maven và liên quan đến các dịch vụ nhỏ. Tôi có một máy chủ nguyên khối lò xo dựa trên maven mà tôi định di chuyển từ đó. – technazi

+0

không thực sự là một cách cụ thể để tạo dự án maven với các dịch vụ vi mô. Cuối cùng những gì chúng ta có là dự án maven nhỏ, dự án cần: Đưa ra một API (với REST chẳng hạn), có các dịch vụ riêng của mình (được sử dụng như một lớp giữa các bộ điều khiển và các entitite), có lược đồ DB của riêng mình và không chia sẻ nó. Pom không có pom cha mẹ và không tạo dự án pom chia sẻ mà bạn sẽ sử dụng trong các dịch vụ vi mô khác nhau của bạn bởi vì giả sử nhóm A làm việc trên dịch vụ vi A và nhóm B làm việc trên MS B, nếu MS A và MS B sử dụng một dự án được chia sẻ, nếu đội A thay đổi nó, đội B sẽ không biết nó –

Trả lời

9

'vấn đề' với một đa pom cha mẹ mô-đun là, mà không có hồ sơ phức tạp, nó khóa các mô-đun trong chu kỳ phát hành tương tự (giả sử bạn đang sử dụng Release Plugin, mà bạn nên có).

Cách tôi làm việc với Maven là phải có một pom mẹ rằng tuyên bố:

  • phụ thuộc chung (đăng nhập API, JUnit, vv).
  • các plugin phổ biến.
  • tất cả các phụ thuộc trong phần dependencyManagement.
  • tất cả các plugin trong phần pluginManagement.

Mỗi mô-đun sẽ xóa cha mẹ làm cha mẹ nhưng cha mẹ không biết gì về mô-đun.

Lợi ích của việc này xuất phát từ lần cuối hai dấu đầu dòng ở trên, phần 'quản lý'. Bất cứ điều gì có trong phần 'quản lý' cần được redeclared trong một mô-đun muốn sử dụng một phụ thuộc cụ thể hoặc plugin.

Ví dụ phụ huynh có thể trông như thế này:

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

Và các mô-đun có thể trông như thế này:

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

Các module sẽ:

  • có phụ thuộc vào org.slf4j:slf4j-api:1.7.7:compile, junit:junit:4.11:testcommons-lang:commons-lang:2.6:compile.
  • có plugin org.apache.maven.plugins:maven-assembly-plugin:2.4
+2

Làm thế nào để bạn giải quyết các lib khách hàng đối với các dịch vụ nhỏ đó? – bobK

4

tôi sẽ tránh phụ thuộc vào pom mẹ. Thật khó xử nếu một trong các dịch vụ nhỏ (độc lập) của bạn sẽ muốn một số thứ khác. Thật kỳ lạ khi có cha mẹ biết về từng dịch vụ microservice.

Bạn có thể gắn bó với sự phụ thuộcQuản lý mặc dù đề xuất các phiên bản/phạm vi mặc định nếu bạn muốn. Một pom cha mẹ là, không ít, rất thuận tiện để xác định bổ sung, kho và các loại tương tự.

Thay vào đó, tôi sẽ nhóm một nhóm phụ thuộc chung vào một tạo phẩm cụ thể, có thể chỉ là một pom đơn với phụ thuộc. Sau đó, bạn có thể phụ thuộc vào, nói "com.example/common-db-dependencies/1.2" để bao gồm một bộ tiêu chuẩn cơ sở dữ liệu phụ thuộc, như hibernate, apache derby và thông số kỹ thuật JPA. (hoặc bất cứ điều gì bạn đang sử dụng). Một dịch vụ không sử dụng JPA/SQL có thể tránh được sự phụ thuộc đó cùng nhau.

Đừng vướng víu. Thật dễ dàng để làm việc quá mức cấu trúc phụ thuộc nếu bạn đang cố gắng để trang trải mỗi trường hợp. Vì vậy, chỉ cố gắng chuẩn hóa những thứ thực sự được sử dụng bởi phần lớn các dịch vụ.

+6

cuối cùng chúng tôi đã loại bỏ hoàn toàn pom cha mẹ để có một repo git bằng dịch vụ vi mô. Vì vậy, bây giờ mỗi dịch vụ vi mô có vòng đời của riêng mình và nó khá tuyệt vời :) chúng tôi không có một dự án chung để quản lý các phụ thuộc phổ biến, bởi vì nó có thể có nghĩa là chỉ một trong các dịch vụ vi mô cần lên phiên bản của một lib một lib được sử dụng trong các dịch vụ vi mô khác) mà không ảnh hưởng đến các dịch vụ khác .... –

1

Ở đây có một vấn đề với sự phụ thuộc và quản lý phụ thuộc. Giả sử một trong các dịch vụ vi mô của bạn muốn nâng cấp lên phiên bản phổ biến mới hơn vì một số lý do ... bạn không thể làm điều đó khi bạn có cha mẹ. Tôi hiểu sự cám dỗ của việc giảm sự trùng lặp của những thứ thừa như cấu hình plugin. Trong dịch vụ vi mô, chúng tôi cần suy nghĩ thêm về tính độc lập của từng dịch vụ.

Một số cấu hình như nói kho lưu trữ hoặc cấu hình phát hành của bạn vv có thể là phổ biến.

Các vấn đề liên quan