微服务:共享库与代码重复 [英] 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屋！