design-patterns - 微服务和耦合——相互竞争的设计原则

Question

所以耦合是微服务的一个热门话题，除了顶层设计概念之外，我还没有找到具体的建议。

我有一项服务可以整合来自多个数据源的数据。一个关键功能是关联数据。现在，代码正在迁移到具有微服务的平台。

所以我现在有一项服务可以提供

• 具有我分配的键的数据源 A，该键保存在内存中。数据很快就会过期，因此将其放入内存是一种可接受的资源使用优化。
• 具有与数据源 A 关联的键的数据源 B

因此，如果 App A 重新启动，所有关联都会丢失，我们重新开始。

现在，如果我将其拆分为两个微服务，当微服务 A 崩溃时，微服务 B 中的密钥“过期”并且不再有效。在我看来，这使我们紧密耦合。

一个微服务目标是松散耦合。但我只是不明白如果我紧密耦合，我怎么能做到这一点。单一职责原则允许“内聚相关功能”的单一职责例外，这似乎适用。

我一直认为单一责任原则需要智慧磨练。在某些时候将每个微小的功能拆分为单独的程序会变得很浪费。

所以底线是我在这里进行哲学论证，我不知道如何处理有关耦合的问题。显然，在某些时候数据是否耦合并不重要，您必须在某些时候划定界限，这使得拆分服务的选择成为主观决定。您可能会争辩说，主键关联是您可能拥有的最少耦合量，所以我应该克服自己。同时，创建两个数据库（每个服务一个）来跟踪关键关联似乎有点矫枉过正。

还有一个实际的论点。我有可以工作的软件。没有必要改变它。将这些分开将是很多工作。例如，我需要建立一个永久数据库来存储这些密钥。我需要解开耦合的类和功能。在工作与价值等式中，很难说“100 小时工作的价值就是为了微服务而微服务”。这并不是说为微服务而微服务无效，而是我宁愿花 100 个小时来创造“真正的”价值。

你如何决定？我在这里错过了一个明确的指导原则吗？

标签： design-patternsmicroservices

Answer 1

我对微服务的看法是，你不需要微代码库来拥有你称之为微服务的东西。我这是什么意思？我的意思是，我们不应该将微部分发挥到极致，让微服务几乎什么都不做，只是为了拥有 20 个不同的微服务，而最好的决定可能是拥有 3 个、2 个甚至一个。重要的是构建一个实际上能够提供某种有用的完整功能的微服务。但是，此功能必须足够大，才能拥有自己的微服务。

正如您所描述的那样，数据源 A 和数据源 B 是如此紧密耦合，以至于试图将它们分开似乎并不正确。试图在一个不需要微服务方法的用例中强制使用几个微服务是你能做的最糟糕的事情。维护微服务很困难，在某些方面比单个单体要困难得多。只需考虑更改一个用作微服务 A 和微服务 B 之间通信的 DTO 的类。您不能进行破坏性更改，否则您的整个生态系统将受到影响，因此您需要小心谨慎并逐步进行。当你有一个单体时，你可以一次性完成。

话虽如此，我并不主张支持单体。我只是说微服务应该有合适的大小，既不能太小也不能太大，通常，它归结为业务逻辑中合理的关注点分离。

再一次，正如您所描述的，我不会使用 2 个微服务。