interface - 为什么微服务之间的共享库不好？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

去年关闭。
社区在 7 个月前审查了是否重新打开此问题并将其关闭:

原始关闭原因未解决





Improve this question




Sam Newman 在他的《构建微服务》一书中指出

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

我只是不明白服务之间的共享代码是如何邪恶的。作者的意思是如果出现对共享库的需求，服务边界本身设计得不好，还是真的意味着我应该在常见业务逻辑依赖的情况下复制代码？我看不出这能解决什么问题。

假设我有两个服务共有的实体共享库。两个服务的公共(public)域对象可能有异味，但另一个服务是用于调整这些实体状态的 GUI，另一个是其他服务的接口(interface)，可以根据其目的轮询状态。相同的领域，不同的功能。

现在，如果共享知识发生变化，我将不得不重新构建和部署这两个服务，而不管公共(public)代码是外部依赖项还是跨服务重复。通常，根据业务逻辑的同一篇文章，两个服务的所有情况都相同。在这种情况下，我只看到代码重复的危害，降低了系统的凝聚力。

当然，在共享库的情况下，偏离共享知识可能会让人头疼，但即使这样也可以通过继承、组合和巧妙地使用抽象来解决。

那么，Sam 说重复代码比通过共享库进行过多耦合更好是什么意思？

Answer 1

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

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

像对待第三方实体的依赖项一样对待共享的库。

确保每个组件/库/服务都有不同的业务目的。

正确地对它们进行版本控制，并将使用哪个版本的库的决定留给相应的微服务团队。

将共享库的开发和测试职责与微服务团队分开。

不要忘记——微服务架构风格并没有过多关注代码组织或内部设计模式，而是关注更大的组织和流程相关方面，以允许扩展应用程序架构、组织和部署。见 this answer概览。