mel*_*onT 8 .net architecture microservices asp.net-core
类似的问题被问过几次，但由于每个用例都可能不同，我认为值得针对我面临的特定案例再次提问。因此，我们正在使用 .netCore 开发微服务。我们将这些服务称为ServiceA、ServiceB、ServiceC。
如果ServiceA调用 ServiceC，则ServiceC以 JSON 内容进行响应，该内容可以序列化为ResponseC对象。
这意味着，ServiceA和ServiceC都应该知道ResponseC类。在这一点上，我看到了两种可能性。ResponseC类可以在共享库中，并且ServiceA和ServiceC都应该引用这个共享库。但是，我读过诸如不在微服务之间共享库之类的语句。这导致了另一种可能的解决方案。让我们在两个微服务中引入ResponseC类，但不知何故，由于代码重复，我发现这有点不利于可维护性。
无论ServiceA和ServiceB与之通信ServiceC。在与ServiceC通信时，我们打算制定一些有关读取和连接超时以及最大重试次数的策略。这些值是可配置的，重试逻辑中还有一些通用部分，以便能够从配置文件中读取相关值并包装 http 调用。问题与前一个案例几乎相同，因为我要么将这些类放入共享库中，要么基本上在ServiceA和ServiceB 中引入相同的类. 这些类非常简单和通用，所以目前我无法想象这些类会经常变化。
所以问题是，在这些情况下，复制代码并拥有独立的微服务或引入一个共享库使这些服务依赖哪个更好？
当然，编程中有 DRY 规则。但是，正如 Sam Newman 在他的《构建微服务》一书中所说：不要在一个微服务中重复自己。
常见实体：
让我们用ResponseC. 想象一下，某些ServiceB内容发生了变化，所以现在响应中的一个字段发生了变化 - 现在您必须更新使用此共享库的每个服务，即使该服务不需要此更改的字段。如果每个服务都有ResponseA、ResponseB和ResponseC，则不必使用新的依赖项更新每个服务。
通用逻辑：
基本上相同的规则在这里应用。但是，通常使用一些第三方库来解决常见的微服务问题，例如超时和重试。我还能建议的是查看service mesh像istioand 之类的实现linkerd。服务网格将为基础设施层提供解决这些问题的可能性，因此您可以专注于编写业务逻辑。
说到模型类，我说重复代码。使用 JSON 或其他某种语言独立协议而不是序列化的本机 Java 对象（例如）的整个想法是避免在整个生态系统中波动的一个微服务中的类更改的副作用。模型类的共享库将多个微服务锁定到一夫多妻制的婚姻契约中，即使一对成员之间的小分歧导致离婚也可能非常昂贵。服务 A 可能需要对其模型进行更改，这不仅是服务 B 不需要的，而且可能与其完全不兼容。
这并不意味着代码不能在不同的微服务之间共享。在不同的微服务之间共享库并没有错，只要它们的功能仅限于解决交叉问题。也许您提到的常见超时和重试功能属于该类别。在我看来，除了保留语言独立协议的数据表示之外什么都不做的模型类不属于这一类。