java - 微服务和maven结构

Question

我真的很困惑有人如何使用 Maven 构建一些微服务。我见过很多使用多模块策略的项目

1. 这是一个有效的策略吗？这不会将整个项目结合起来吗？因为我需要从根目录(父 pom.xml)构建项目？一切都与我所想的一切相关

2. 我应该自己构建一切吗？

   • 第一个应用程序

   • 第二次申请

   • 第三个应用程序

非常感谢任何帮助。

我真的不知道这是如何工作的

[ parentpom.xml ]
|
|___first-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |   
|   |__ services
|   |   |__ [[ USES message-queue:producer ]]
|   |   |
|   |   |__ pom.xml
|   |   
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|   
|___second-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |
|   |__ services
|   |   |__ pom.xml
|   |
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|___third-application
|   |
|   |__ data-layer
|   |   |__ pom.xml
|   |
|   |__ services
|   |   |__ [[ USES message-queue:consumer ]]
|   |   |
|   |   |__ pom.xml
|   |
|   |__ domain
|   |   |__ pom.xml
|   |
|   |__ application (REST)
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|
|___message-queue (as wrapper of kafka/rabbit/etc)
|   |
|   |__ configuration_of_message_queue
|   |   |__ pom.xml
|   |
|   |__ consumer
|   |   |
|   |   |__ [[ USES message:queue:configuration ]]
|   |   |
|   |   |
|   |   |__ pom.xml
|   |
|   |__ producer
|   |   |
|   |   |__ [[ USES message:queue:configuration ]]
|   |   |
|   |   |
|   |   |__ pom.xml
|   |
|   |__ pom.xml
|
|
|___ commonlibrary (some projects use this, some others dont)
    |__ pom.xml

<parentpom>
  <modules>
    <module>first</module>
    <module>second</module>
    <module>third</module>
    <module>message-queue</module>
    <module>commonlibrary</module>
  </modules>
</parentpom>

Answer 1

您发出的信号是单一存储库是一个好的策略还是多存储库(每个服务/库的存储库)。

注意:

Each independent repo or same repo can be itself multimodule project itself.

关于单 repo 与多 repo 的争论已经存在。

两者都非常适合微服务。

很多事情都会成为这个决定的影响因素。

1. 您将如何编写 DevOps 管道。
2. 您希望如何构建构建。
3. 团队要求 - 多个团队/成员可以针对每个微服务/团队结构在同一个存储库中进行提交吗？

如果您要使用 monorepo(单个存储库所有微服务+库)

1. 您可以在一处看到所有代码。
2. 由于代码库相同，因此易于协作。
3. 作为单一代码库，易于构建和修复任何问题
4. 易于控制构建生命周期 - 即，将首先按顺序构建库，然后构建微服务。
5. 如果多个团队在同一代码库中进行提交，有时您会遇到冲突和问题。
6. 但是，当许多人处理同一个代码库时，所有团队成员都必须遵循一些标准、实践和指南。制定适当的提交、构建和发布程序非常重要。

如果您要使用多个存储库(每毫秒和库存储库)

1. 您需要确保按照您想要的顺序构建具有依赖项的单独项目。
2. 构建管道将单独配置，并且存在交叉依赖项。
3. 您将需要额外的开销来维护单独的项目。
4. 调试有时会有点困难。
5. 团队/成员将协作并负责维护自己的存储库。如果该存储库损坏，该存储库及其构建也会损坏。
6. 您需要确保首先发布依赖项并构建它们，然后再处理您的微服务。
7. 如果您有足够的带宽来维护多个存储库，那就太好了。

本质上来说，这两种方法都是不错的方法，具体取决于您的团队结构、成熟度和您觉得舒服的模型。

我正在关注 monorepo 来获取我们的服务，以下是结构。

├── README.md
├── db
│   └── create-dbs.sh
├── docker-compose.yaml
├── docs
│   ├── 1. Prerequisites.md
│   ├── 2. Documentation.md
│   ├── 3. Running services.md
├── pom.xml
├── services
│   ├── books-service
│   └── products-service
├── shared
│   ├── archunit-tests
│   ├── auditing-utils
│   ├── project-bom
│   ├── event-publisher
│   ├── logging-utils
│   ├── rest-clients
│   └── utils
└── templates
    └── azure-template

给您的一些建议:

1. 您可以拥有图书馆中所有服务 (bom) 的 Material list 。
2. 您可以为服务、库、文档等创建单独的文件夹。
3. 父 pom 可以先使用库构建整个项目，然后构建服务。
4. 所有文件夹不必是maven项目，可以只是简单的文件夹。