如何在微服务架构中重用代码 [关闭]答案

【问题标题】：How to reuse code in microservices architecture [closed]如何在微服务架构中重用代码 [关闭]
【发布时间】：2019-05-28 17:59:06
【问题描述】：

我有 2 个服务（service1 和 service2），两个服务都使用相同的数据模型“studentModel”，我想知道如何在两个服务之间共享 studentModel。

1.构建一个studentModel.jar，所有服务都引用这个jar

2.复制粘贴代码

请帮助我如何在微服务架构中重用代码。

【问题讨论】：

【解决方案1】：

我建议走得更远。根据我的经验，最好的方法如下：

按照这种方法，您可以在每次更改微服务时发布一个新的客户端库 - 这将很容易维护和管理。

此外，当您的系统增长时，它将帮助您节省大量时间。想象一下，您将使用您的核心服务（例如用户服务或配置文件服务）作为所有其他服务的依赖项。在这种情况下，复制粘贴绝对不是一种选择。

更新。 目前，我们的工具集中有 OpenAPI 和 GraphQL 之类的东西。为供应商服务设计一个好的架构并为消费者简单地使用代码生成工具就足够了。

【讨论】：

【解决方案2】：

为了更好的版本控制，我建议您构建一个 jar 并将其添加为对您的微服务的依赖项。或者，您也可以通过在子模块中放置重复代码并在您各自的微服务模块中使用它来探索 git 子模块。

【讨论】：

【解决方案3】：

对于微服务，保留重复文件是可以的，因为您最终可能会得到一个分布式单体。记住 DDD 中的限界上下文并使用您的思维过程。没有共享库意味着没有耦合。

但是 DRY（不要重复自己）又说你不应该重复，但是到什么程度？

一个库中的一次故障不应导致您使用该库的所有微服务都失败，那么微服务的全部目的就没有用了。

有在微服务之间共享代码的工具，你可以看看https://bitsrc.io/

这些都是我的想法，一定有更好的办法。

【讨论】：

是的，耦合和DRY在微服务架构中是不兼容的。
我认为 DRY 和 Decoupling 完全兼容。在微服务环境中，每个服务在系统中都应该有一个用途，因此该模块可能不是重复的，因为它可能在未来出现分歧。使用相同型号的相同罐子的原因仅与它们只有一个更改理由有关。如果他们有更多，那就不是重复。
查看我对 OPs 问题的评论。只需将依赖项视为具有正确版本控制的外部依赖项。复制文件会让你很快陷入更新地狱。
如果你用一个版本来实现你的公共库，那么你就不会违反MS的不耦合。