我目前正在开发一个关于微服务架构的项目。它有大约100多个模块，这些模块是git上不同存储库中的单个项目。其中很少是可运行的启动应用程序，而其他是API和实现，它们作为jar包含在可运行的项目中，并且在需要时也可以包含在其中。
模块之间的依赖关系图很乱，我们在test范围内指定所有依赖关系，许多模块都使用api来自其依赖关系。
发布版本是一项艰巨的任务，因为它要求我们在100多个存储库中进行直接和间接依赖关系的所有版本更新。
有人可以分享一些可以简化这种混乱的最佳实践吗？是否有任何工具可用于以更加可控和可靠的方式可视化/管理传递依赖？
答案 0 :(得分：0)
对于传递依赖关系，不要求微服务保持同步，并且不要一次性部署完整堆栈。例如。每项服务都是可独立部署的独立代码。
如果您有共享代码，则应将其视为外部依赖项（保存在Nexus等中央存储库中），可以根据服务单独更新。
唯一存在的硬依赖是服务之间的公共API。例如，您可以通过REST在基于JSON的API的服务之间进行通信。如果其中一个API以不向后兼容的方式发生变化，那么您需要注意/考虑部署顺序。
无法替代思考API应该或不应该暴露的内容，每个服务的适当大小和责任以及架构简单性。如果你弄错了这些东西，你就会陷入难以维护的混乱中，无论你是在写微服务还是整体。
编辑：
通常（当我这样做时）如果service2想要调用service1，它使用REST API进行通信，并实现在service2本身内与该API通信所需的一切。例如。有RestTemplate连线，Service1.java将@Autowire RestTemplate实例，而建模请求和服务1响应的POJO直接在service2中实现。例如。没有共享代码依赖项，存在API契约依赖项。
正如我最初提到的，你也可以采用共享代码方法＆＃34;将客户端库放在像Nexus这样的东西上，但是我个人发现它比它的价值更麻烦。很多时候，我发现，即使有特定服务的多个呼叫者，不同的呼叫者实际上也使用不同的API，并且任何给定的服务仅模拟API的一部分（两个端点）需要/适用的POJO子集。如果恰好是这种情况，共享库实际上并不涉及共享，因为它会模糊哪些服务会受到特定API更改的影响。