分布式分析中的微服务有界上下文答案

【问题标题】：microservices bounded context in distributed analytics分布式分析中的微服务有界上下文
【发布时间】：2017-01-24 00:28:22
【问题描述】：

在我们当前的系统中，我们正在将过去是单个单体应用程序的多个服务分割成独立的服务。

我们在分析方面有一个非常标准的架构（类似于 lambda）：

架构类似于下图：

由于消费者和报告服务使用相同的表，因此我们打破了有界上下文并且我们在此处遵循反模式，因为每次我们需要进行架构更改时，我们都需要部署消费者（服务创建数据）和报告（读取数据的服务）“同时”。然后我们可能还需要部署策展服务。

我能够想出遵循有界上下文规则的唯一方法是在报告服务上公开一个方法，以根据消费者调用参数构建汇总。策展服务也是如此，在报告服务中公开了策展方法。将这种“报告服务”转变为某种上帝服务。

此解决方案的巨大缺点是无法预测报告的延迟，因为同一个机器可能会执行批处理作业，创建大量汇总并计算报告，因为该服务将承担多项职责。

有没有办法将这三个服务（消费者、报告、管理）构建为松散耦合且不直接依赖于它们之间的数据库集成？

【问题讨论】：

【解决方案1】：

有没有办法将这三个服务（消费者、报告、管理）构建为松散耦合且不直接依赖于它们之间的数据库集成？

不要将数据库公开给消费者、报告和管理服务，而是公开新服务的 API（例如 REST API），该服务将独占访问数据库。使这些服务不依赖于数据库，而是依赖于这个 API，并对消费者、报告和管理服务隐藏数据库。

如果您有许多限界上下文，那么您可以为每个限界上下文创建单独的服务：

【讨论】：

这是我能想到的最佳解决方案，但我担心“汇总服务”将来会“太大”且难以拆分。尽管如此，我认为这是这种情况的最佳解决方案。感谢您的回答和图表:)
@SamuelGarcía 欢迎您。是的，这可能是最具挑战性的部分。我将从根据 DDD 定义域开始：实体和值对象、关系、关系的方向、聚合和有界上下文。完成该步骤后，您可以开始重构代码以实现新域。
根据新建议，Roll-up 服务将被其他服务访问。 Rollup 服务会承受非常高的负载，可能会成为 SPOF 或瓶颈？
@Barcelona 是的，它可能是瓶颈或 SPOF。要解决 SPOF 问题 - 启动此服务的几个实例。然后解决数据库单点故障问题——启用数据库复制。解决瓶颈问题更具挑战性，因为这完全取决于负载。我将从启动一些应用服务器和数据库实例开始。