Design patterns 当微服务共享数据和概念时，如何重新组织它们？

在我们公司，我们使用微服务方法，因为我们喜欢使服务小型化、易于理解和维护。除此之外，我们还使用负载平衡器，它使我们能够复制大量使用的服务

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

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

这种方法有两个问题：

75%的服务生成报告数据。有一个报表服务负责持久化和服务该数据。因此，所有生成报表数据的服务都将其结果发送给报表服务。事实上，每个 服务有它自己的责任，但我们仍然需要所有这些沟通。这似乎与微服务理念相冲突。它就像一个水平层，将所有垂直的微服务绑定在一起

由于上面的“水平”耦合，我们还共享接口对象。报表数据是以某种方式结构化的。每项服务都需要遵循这种结构。我们强烈感觉到域/接口对象的共享库违背了一些原则。但正如您所理解的，复制所有接口对象似乎很愚蠢，而且当接口发生变化时仍需要大量工作

当前体系结构的另一种选择是，每个服务都保留自己的报表数据。那么，您只需要在呈现报告时进行通信。在这种情况下，我们无法在服务和报表服务之间进行定期通信。缺点是现在每个服务都需要它的数据库层（没有），并且您仍然需要在所有服务之间共享报告结构

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

同样的问题也可能发生在销售应用程序中，其中“产品”在整个服务集中起着核心作用

---

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

报告通常与应用程序域模型关系不大。通常，它是一个独立的、跨领域的关注点，出于性能原因，它在后端数据存储中实现

仅仅为了报告而做一个公共域模型将把您的所有服务耦合到一个不可接受的程度，您将创建一个整体

看起来您已经创建了一个折衷方案，通过使报表服务成为自己的服务来实现报表服务的解耦。这似乎是合理的，但正如您所说，这会造成大量的通信开销。它还带来了运行时开销，这可能是合理的，也可能不是合理的

不管怎样，正如我所说，报告通常是交叉的，因此，通常不适合领域模型。将其移动到后端流程与将其作为运行时流程的决策取决于系统的操作需求

---

我强烈建议您不要尝试让所有的微服务域都符合一个通用模型。这将创建一个整体，并将使对该领域的更改变得异常昂贵。您将拥有一块巨石的所有开销，加上所有微服务的开销…

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

其主要思想是，每个服务都应该能够完成其角色，而不需要与其他服务进行业务逻辑通信（在执行其他服务时没有同步调用）。这就是真正解耦的含义

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

离线/异步通信

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

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

前端合成

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

如果您想展示一些报告，可以直接链接到它们各自服务中提供的报告。你真的不必把报告复制到某个“中央”系统

因此，服务基本上是通过UI中的链接组成的

这当然意味着，所有服务也应该拥有自己的UI

针对SCS的反模式

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

在SCS中，我们不为“东西”创建服务，如产品或用户，我们为“搜索”、“购物车”、“配置器”等功能创建服务。每个服务都有自己的“产品”视图。最酷的是，他们通常都对产品有不同的概念，所以几乎没有重复或冗余

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

这是system i