微服务:共享库与代码重复 [英] Micro services: shared library vs code duplication

问题描述

类似的问题被问过几次，但由于每个用例都可能不同，我认为值得针对我面临的特定案例再次提问.因此，我们正在使用 .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 实现，如 istio 和 linkerd.服务网格将为基础设施层提供解决这些问题的可能性，因此您可以专注于编写业务逻辑.

Similar questions were asked a few times, but as every use-case can be different I thought it worth to ask it again with the specific case I'm facing with. So, we are developing micro-services using .netCore. Let's call these services ServiceA, ServiceB, ServiceC.

Common entities

If ServiceA calls ServiceC, then ServiceC responds with a JSON content which can be serialized into ResponseC object.

This means, that both ServiceA and ServiceC should know ResponseC class. At this point I see two possibilities. ResponseC class can be in a shared library and both ServiceA and ServiceC should have a reference to this shared library. However I read statements like do not share libraries among micro-services. This leads to an other possible solution. Let's introduce ResponseC class in both micro-services, but then somehow I find this a bit against maintainability, because of code duplication.

Common logic

Both ServiceA and ServiceB communicates with ServiceC. When communicating with ServiceC we intend to have some policy regarding read and connection timeout and regarding the maximum number of retries. These values are configurable and there is also some common parts in the retry logic to be able to read the relevant values from the configuration file and to wrap the http calls. The question is pretty much the same like in the previous case, because I either put these classes into a shared library or I basically introduce the same classes in both ServiceA and ServiceB. These classes are quite simple and generic, so at the moment I cannot imagine, that these classes will change frequently.

So the question is, that what is better in these cases, duplicate code and having independent micro-services or introduce a shared library which makes these services dependent?

解决方案

Of course there is DRY rule in programming. But, as Sam Newman said in his book "Building Microservice": Don't Repeat Yourself inside one microservice.

Common entities: Let's look at your example with ResponseC. Imagine that something in ServiceB has changed so now one of the field from the response have changed - now you have to update each service that uses this shared library, even if the service don't need this changed field. If you had the ResponseA, ResponseB and ResponseC for each service, you didn't had to update each service with the new dependency.

Common logic: Basically the same rules are applied here. However it's common to use some third party libraries for common microservices issues like time-outs and retries. What else I can suggest is to look at service mesh implementation like istio and linkerd. Service mesh will give the possibility to these issue to the infrastructure layer so you can focus on writing business logic.

这篇关于微服务:共享库与代码重复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！