如何在微服务共享数据和概念时重组微服务？

Question

在我们公司，我们使用微服务方法，因为我们希望保持服务的小巧，易懂和可维护。除此之外，我们使用负载均衡器，使我们能够复制大量使用过的服务。

我们知道，如果需要耦合，微服务应该松散耦合。此外，耦合不应该发生在数据库上，但最好是通过API（REST）。

好吧，我们使用微服务理念。我们不适用推荐的外包。在我们的例子中，我们使用松散耦合的Tomcat War，通过REST和JMS消息进行通信。所有webapps都使用相同的数据库服务器，但它们都有自己的方案（因此没有集成）。

这种方法有两个问题：

1. 75％的服务生成报告数据。有一个报告服务负责持久化和提供该数据。因此，生成报告数据的所有服务都会将其结果发送到报告服务。事实上，每一个 服务有它自己的责任，但我们仍然需要所有这些沟通。这似乎与微服务理念相冲突。它就像一个水平层，将所有垂直微服务绑定在一起。
2. 由于水平＆＃39;上面的耦合，我们也共享接口对象。报告数据以某种方式构建。每项服务都需要遵循这一结构。我们强烈认为域/接口对象的共享库违反了某些原则。但正如您将理解的那样，复制所有界面对象似乎是愚蠢的，并且当界面发生变化时仍然需要做很多工作。

当前架构的替代方案是每个服务都会保留其自己的报告数据。然后，您只需在呈现报表时进行通信。在这种情况下，我们不能在服务和报告服务之间进行定期通信。现在缺点是每个服务都需要它的数据库层（没有），并且你仍然需要在所有服务之间共享报告结构。

高级问题是：当行为可以水平和垂直分开时，是否存在划分服务的模式？

在＆＃39;产品＆＃39;的销售应用程序中可能会出现同样的问题。通过整套服务发挥核心作用。

我们应该重新设计架构吗？我们可以使用一种模式吗？或者这是一个已知的反模式？

Answer 1

报告通常与您的应用领域模型无关。通常，这是一个单独的，跨领域的问题，并且出于性能原因在后端数据存储中实现。

仅为报告做一个通用域模型会将所有服务耦合到一个不可接受的程度，您将创建一个整体。

您似乎已经创建了一个折衷方案，即将报表服务与其自身的服务分离。这似乎是合理的，但就像你说的那样，它会导致大量的通信开销。它还会产生运行时开销，这可能是合理的，也可能是不合理的。

无论如何，正如我所说，报告往往是跨领域的，因此，通常不适合领域模型特别好。决定是将其转移到后端流程还是将其作为运行时流程，这取决于系统的运营要求。

我强烈建议您不尝试让所有微服务域都适合通用模型。这将创建一个整体，并将对该域进行非常昂贵的更改。你将拥有整体的所有开销，加上微服务的所有开销......

Answer 2

是的，有其他选择。其中一个被称为Self-Contained Systems，这是一种“更严格”的微服务形式。

主要思想是，每个服务都应该能够履行其角色，而无需与业务逻辑进行通信（在执行其他服务时不需要同步调用）。这就是真正脱钩的意思。

现在显然服务不存在于真空中，所以我们如何让它们一起玩。有两种首选方法可以避免您遇到的问题。

离线/异步通讯

如果数据是异步的，数据仍然可以在服务之间流动。异步不仅意味着它应该通过队列或类似的东西。这意味着它离线。在执行“业务逻辑”期间不会发生这种情况。

所以坚持报告，因为它是逻辑的一部分，是不允许的。但是，您可以稍后（离线）将报告归档到数据仓库系统或其他内容。如果此脱机复制失败或一段时间内不可用，那么“主要”功能仍然有效。

前端构成

如果您已经在使用REST，那么您可能拥有Web界面和其他带有链接的服务。

如果您想要提供一些报告，可以直接链接到各自服务提供的报告。您实际上不必将报告复制到某个“中央”系统。

所以基本上服务是通过UI中的链接组成的。

当然，这意味着所有服务也应该托管自己的用户界面。

对SCS的反模式

正如你所说，如果你有类似“产品”之类的东西，并为此建立一个单独的服务，你将有耦合。由于所有其他人可能都依赖于“产品”，因此您只是为所有人创建了依赖。

在SCS中，我们不为“事物”创建服务，例如产品或用户，我们为“搜索”，“购物车”等功能创建服务，“配置器”等。每个人都有自己的“产品”视图。很酷的部分是，它们通常都有不同的产品概念，因此很少有重复或冗余。

剩余的冗余由离线数据流处理，如上所述。