java - 微服务项目中的 Maven 传递依赖

Question

我目前正在做一个关于微服务架构的项目。它有大约 100 多个模块，这些模块是 git 上不同存储库中的单个项目。其中很少是可运行的引导应用程序，而其他的是 API 和实现，它们作为 jar 包含在可运行项目中，并且在需要时也相互包含。

模块之间的依赖关系图是一团糟，我们在 test 中指定了所有依赖关系范围内，许多模块都使用其依赖项的依赖项中的 api。

发布是一项艰巨的任务，因为它需要我们对 100 多个存储库中的直接和间接依赖项进行所有版本更新。

有人可以分享一些可以简化这种困惑的最佳实践吗？是否有任何工具可以用来以更可控和可靠的方式可视化/管理传递依赖关系？

Answer 1

微服务不需要在传递依赖方面保持同步，并且您不会一次部署完整的堆栈。例如。每个服务都是可独立部署的独立代码。

如果您有共享代码，则应将其视为可以独立更新每个服务的外部依赖项(保存在 Nexus 等中央存储库中)。

唯一存在的硬依赖是服务之间的公共(public) API。例如，您可以通过 REST 使用基于 JSON 的 API 在服务之间进行通信。如果其中一个 API 以不向后兼容的方式更改，那么您需要小心/考虑部署顺序。

没有什么可以替代思考诸如 API 应该或不应该公开什么、每个服务的适当大小和责任以及架构简单性等问题。如果你把这些事情弄错了，无论你是编写微服务还是单体应用程序，你都会陷入无法维护的困惑局面。

编辑:
通常(当我这样做时)如果 service2 想要调用 service1，它会使用 REST API 进行通信，并在 service2 本身内实现与该 API 通信所需的一切。例如。有一个RestTemplate已连线，Service1.java那将@Autowire RestTemplate实例，并且对 service1 的请求和响应建模的 POJO 直接在 service2 中实现。例如。没有共享代码依赖，有 API 合约依赖。
正如我最初提到的，您也可以采用“共享代码方法”，将客户端库放在 Nexus 之类的东西上，但我个人发现这比它的值(value)更麻烦。很多时候，我发现即使一个特定服务有多个调用者，不同的调用者实际上使用不同的 API，并且任何给定的服务只对 API 的一部分(端点和子集)进行建模POJOs) 是需要/适用的。如果发生这种情况，共享库实际上并不涉及共享，因为它掩盖了哪些服务将受到特定 API 更改的影响。