如何在微服务全部共享数据和概念时重新组织这些服务？

Question

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

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

那么，我们使用微服务的想法。我们不应用推荐的everthing。在我们的例子中，我们使用通过REST和JMS消息进行通信的松散耦合的Tomcat War。所有的webapp都使用相同的数据库服务器，但他们都有自己的方案（所以没有整合）。

我们有两个问题，这种方法：服务的

1. 75％生成报表数据。有一个报告服务负责持久化和提供这些数据。因此，所有生成报告数据的服务都将他们的发现发送到报告服务。实际上，每个 服务都有自己的责任，但我们仍然需要所有这些沟通。这似乎与微服务理念相冲突。它就像一个水平层，将所有垂直微服务绑定在一起。
2. 由于上面的“水平”耦合，我们还共享接口对象。报告数据是以某种方式构建的。而且每项服务都需要遵循这一结构。我们强烈地感觉到域/接口对象的共享库违背了一些原则。但是，正如你将会理解的那样，复制所有接口对象似乎很笨拙，并且在接口改变时仍然需要很多工作。

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

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

在“产品”通过整套服务扮演中心角色的销售应用程序中可能会出现同样的问题。

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

Answer 1

报告通常与您的应用程序域模型无关。通常它是一个单独的，交叉的问题，并出于性能原因在后端数据存储中实施。

做一个通用的领域模型只是为了报告将你所有的服务耦合到一个不可接受的程度，你将创建一个庞然大物。

看起来您已经创建了一个折衷方案，报告服务通过使其成为自己的服务来解耦。这似乎是合理的，但正如你所说，这会造成很多通信开销。它还会产生运行时间的开销，这可能或可能不合理。无论如何，正如我所说，报告通常是交叉性的，因此，通常不适合特别好的域模型。决定将它移入后端进程还是使其像您这样的运行时进程取决于系统的运行要求。

我会极力鼓励你而不是试图让你的所有微服务域都适合一个共同的模型。这将创建一个庞然大物，并将对该域进行非常昂贵的更改。你将拥有巨石的所有开销，加上所有微服务的开销......

Answer 2

是的，还有其他选择。其中之一叫做Self-Contained Systems，这是一种“更严格”的微服务形式。

其主要思想是，每个服务应该能够履行其职责，而不需要与他人进行业务逻辑通信（在执行期间不会与其他服务进行同步调用）。这就是真正解耦的意思。

现在显然服务不是真空存在，所以我们如何让他们一起玩。有两种首选的方法可以避免你面临的问题。

离线/异步通信

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

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

前端组成

如果您已经使用REST，你可能有与他们的联系网络的界面和其他服务。

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

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

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

反模式，以SCSS

正如你所说，如果你碰到这样的“产品”，而你建立一个单独的服务，你会有耦合。由于所有其他人都可能依赖于“产品”，因此您只是为所有人创建了依赖关系。

在南海，我们不为“东西”创建服务，如产品或用户，我们像“搜索”，“购物车”，“配置”，等等。每个功能创建服务他们有自己的“产品”观点。很酷的部分是，他们通常对产品的概念都有不同的概念，所以几乎没有重复或冗余。

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