.net - 微服务: shared library vs code duplication

Question

类似的问题被问了几次，但由于每个用例都可能不同，我认为有必要针对我所面临的具体情况再问一次。
因此，我们正在使用 .netCore 开发微服务。我们将这些服务称为 服务A , 服务B , 服务C .

共同实体

如果 服务A 来电服务C ，然后 服务C 以可序列化为 的 JSON 内容响应回复C 目的。

这意味着，服务A 和 服务C 应该知道回复C 类(class)。
在这一点上，我看到了两种可能性。 回复C 类可以在共享库中，也可以在 中服务A 和 服务C 应该有对此共享库的引用。
但是我读了 之类的声明不要在微服务之间共享库 .这导致了另一种可能的解决方案。介绍一下回复C 两个微服务中的类，但不知何故，由于代码重复，我发现这有点不利于可维护性。

通用逻辑

两个服务A 和 服务B 与 通信服务C .与 通信时服务C 我们打算制定一些关于读取和连接超时以及最大重试次数的政策。这些值是可配置的，并且重试逻辑中还有一些公共(public)部分能够从配置文件中读取相关值并包装 http 调用。
这个问题和前面的例子差不多，因为我要么把这些类放到一个共享库中，要么基本上在两个 中引入相同的类。服务A 和 服务B .这些类非常简单和通用，所以目前我无法想象这些类会经常更改。

所以问题是，在这些情况下，复制代码并拥有独立的微服务或引入使这些服务依赖的共享库更好？

Answer 1

说到模型类，我说的是重复代码。使用 JSON 或其他与语言无关的协议(protocol)而不是序列化的本地 Java 对象(例如)的整个想法是避免一个微服务中的类更改的副作用在整个生态系统中产生涟漪效应。模型类的共享库将多个微服务锁定在一夫多妻制的婚姻契约(Contract)中，即使一对成员之间的小分歧引发的离婚也可能非常昂贵。服务 A 可能需要对其模型进行更改，这不仅是服务 B 不需要的，而且可能与它完全不兼容。

这并不意味着代码不能在不同的微服务之间共享。只要它们的功能仅限于解决横切关注点，在不同的微服务之间共享库就没有错。也许您提到的常见超时和重试功能属于该类别。在我看来，除了保存语言独立协议(protocol)的数据表示之外什么都不做的模型类不属于这一类。