.net - 微服务：共享库 vs 代码重复

Question

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

共同实体

如果ServiceA调用 ServiceC，则ServiceC以 JSON 内容进行响应，该内容可以序列化为ResponseC对象。

这意味着，ServiceA和ServiceC都应该知道ResponseC类。在这一点上，我看到了两种可能性。ResponseC类可以在一个共享库中，ServiceA和ServiceC都应该引用这个共享库。但是，我阅读了诸如不在微服务之间共享库之类的声明。这导致了另一种可能的解决方案。让我们在两个微服务中引入ResponseC类，但不知何故，由于代码重复，我发现这有点不利于可维护性。

通用逻辑

ServiceA和ServiceB都与ServiceC通信。在与ServiceC通信时，我们打算制定一些关于读取和连接超时以及最大重试次数的策略。这些值是可配置的，并且重试逻辑中还有一些公共部分能够从配置文件中读取相关值并包装 http 调用。这个问题与前一个案例几乎相同，因为我要么将这些类放入共享库中，要么基本上在ServiceA和ServiceB中引入相同的类. 这些类非常简单和通用，所以目前我无法想象这些类会经常更改。

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

标签： .netasp.net-corearchitecturemicroservices

Answer 1

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

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