java - 在微服务之间共享版本库有什么问题？

Question

为什么在微服务之间共享库是不好的做法？假设我想在两个微服务之间共享一个域模型(它们具有相同的限界上下文，原始微服务由于其大小而被简单地拆分为两个较小的微服务)。这种方法有什么问题？更改域模型不会破坏任何东西，因为库的使用者使用它的特定版本？

Answer 1

如果两个微服务共享一个 3rd 方库就没有问题，事实上这种情况经常发生。许多使用相同的服务框架、日志记录框架、来自 apache、google 等的公共(public)库。

当微服务团队共享一个他们可以根据自己的目的修改的第 3 方库时，就会出现问题，因为如果可以，那么他们最终会。来自许多服务的需求最终将被插入库中，其目的将变得困惑且难以陈述。它的代码会膨胀。

然后，服务团队将不得不在日常业务过程中定期修改库。因为图书馆为许多大师服务，那么，他们将不得不非常小心地做这件事……与利益相关者交谈……确保他们不会破坏别人的东西……嘘!图书馆变得像一个小巨石。

如果您共享一个库，您也会共享其他库。最终它们都将成为小整体，而您的整个架构将成为一个整体，将其拆分为多个存储库会变得更加烦人。

--(为评论添加):

现在，您建议只要微服务依赖于库的特定版本，就不会发生此问题。但这并不能解决问题。它只是移动工作。

假设您依赖于库的特定版本，并且自该版本以来有 6 个团队对库进行了自己的修改。按照您的建议，没有团队愿意与您的团队讨论这件事，所以现在一团糟，您有一个选择:

1. 花所有必要的时间来解决他们的更改可能给您的服务带来的任何问题(不要费心与他们谈论这件事，所以他们在下次升级时必须做同样的事情)，然后升级；或
2. 只需 fork 库即可摆脱他们的所有更改并解决您自己的问题。

选项 2 是正确的选择，但是几乎没有人这样做!因为所有服务共享同一个库，所以人们认为它们共享同一个库是某种业务规则。

由于人们在建立共享模式后非常不愿意 fork 库，所以最好在开始时 fork 它，即一开始就不要共享它。