为什么微服务之间的共享库不好? [英] Why shared libraries between microservices are bad?

问题描述

萨姆·纽曼(Sam Newman)在他的书构建微服务中

Sam Newman states in his book Building Microservices

服务之间过多耦合的弊端远比代码重复所引起的问题更严重

The evils of too much coupling between services are far worse than the problems caused by code duplication

我只是不了解服务之间的共享代码是多么邪恶.如果出现对共享库的需求，作者是说服务边界本身的设计不当，还是真的是在出现常见业务逻辑依赖性的情况下我应该复制代码?我看不到能解决什么.

I just don't understand how the shared code between the services is evil. Does the author mean the service boundaries themselves are poorly designed if a need for a shared library emerges, or does he really mean I should duplicate the code in the case of common business logic dependency? I don't see what that solves.

比方说，我有两个服务共有的实体共享库.两个服务的公共域对象可能有异味，但另一个服务是用于调整那些实体状态的GUI，另一个是用于其他服务以对其状态进行轮询的接口.相同的域，不同的功能.

Let's say I have a shared library of entities common to two services. The common domain objects for two services may smell, but another service is the GUI to tweak the state of those entities, another is an interface for other services to poll the state for their purpose. Same domain, different function.

现在，如果共享知识发生了变化，那么无论通用代码是外部依赖项还是跨服务重复，我都必须重新构建和部署这两个服务.通常，这取决于业务逻辑的同一条，涉及两种服务的所有情况.在这种情况下，我只会看到重复代码的危害，从而降低了系统的凝聚力.

Now, if the shared knowledge changes, I would have to rebuild and deploy both services regardless of the common code being an external dependency or duplicated across the services. Generally, same concerns all the cases for two services depending of the same article of the business logic. In this case, I see only harm of duplication of the code, reducing the cohesion of the system.

当然，对于共享库，相异可能会引起头痛，但是即使这样，也可以通过继承，组合和抽象的巧妙使用来解决.

Of course, diverging from the shared knowledge may cause headaches in the case of shared library, but even this could be solved with inheritance, composition and clever use of abstractions.

那么，山姆所说的代码重复比通过共享库进行过多耦合要好吗?

So, what does Sam mean by saying code duplication is better than too much coupling via shared libraries?

推荐答案

服务之间过多耦合的弊端远不如代码重复所引起的问题

The evils of too much coupling between services are far worse than the problems caused by code duplication

作者使用通用词耦合"时非常不确定.我同意某些类型的耦合是严格禁止的(例如共享数据库或使用内部接口).但是，使用公共库不是其中之一.例如，如果您使用golang开发两个微服务，则您已经具有一个共享依赖项(针对golang的基本库).这同样适用于您出于共享目的而自行开发的库.请注意以下几点:

The author is very unspecific when he uses the generic word "coupling". I would agree with certain types of coupling being a strict no-no (like sharing databases or using internal interfaces). However the use of common libraries is not one of those. For example if you develop two micro services using golang you already have a shared dependency (towards golang's basic libraries). The same applies to libraries that you develop yourself for sharing purpose. Just pay attention to the following points:

• 像对待第三方一样，共享共享的处理库.
• 确保每个组件/库/服务都有不同的业务目的.
• 正确地版本化它们，并决定将哪个版本的库使用给相应的微服务团队.
• 与微服务团队分开设置开发和测试共享库的职责.

别忘了-微服务架构样式不是主要关注代码组织或内部设计模式，而是更大的组织和过程相关方面，以允许扩展应用程序体系结构，组织和部署.有关概述，请参见此答案.

Don't forget - The microservices architectural style is not so much focusing on code organization or internal design patterns, but on the larger organizational and process relevant aspects to allow scaling application architectures, organizations and deployments. See this answer for an overview.

这篇关于为什么微服务之间的共享库不好?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！