微服务在分布式分析中有限的上下文

时间:2015-12-24 09:49:05

标签: architecture microservices

在我们当前的系统中,我们将过去单个整体应用程序中的多个服务切换为独立服务。

我们在分析方面有一个非常标准的架构(类似于lambda):

  • 解析HTTP请求并将其推送到流中的前端服务。
  • 为每种事件构建汇总并直接调用数据库的消费者服务(主要是出于性能原因)。
  • 报告服务,读取每个汇总表并返回有意义的数据
  • 数据管理服务,每N小时运行批处理作业,读取数据并对其进行采样,删除无用的行和短期数据/报告等。

架构如下图所示: http://i.stack.imgur.com/84aQQ.png

由于使用者和报告服务使用相同的表,我们打破了有界上下文,我们在这里遵循反模式,因为每次我们需要进行模式更改时,我们需要部署使用者(服务)创建数据)和报告(读取数据的服务)在“同一时间”。然后我们可能也必须部署策展服务。

我能够提出遵循有界上下文规则的唯一方法是在报表服务上公开一种方法,以根据使用者调用参数构建汇总。对于策展服务也是如此,在报告服务中公开了策展方法。在某种上帝服务中改变这种“报告服务”。

此解决方案的一个巨大缺点是,无法预测报告的延迟,因为同一个框可能正在执行批处理作业,创建大量的汇总和计算报告,因为该服务将承担多重责任。 / p>

有没有办法将这三种服务(消费者,报告,策展)设计为松散耦合,而不是直接依赖于它们之间的数据库集成?

1 个答案:

答案 0 :(得分:2)

  

有没有办法构建这三种服务(消费者,报告,策展)松散耦合,而不是直接依赖于它们之间的数据库集成?

不要将数据库公开给使用者,报告和策展服务,而是公开新服务的API(例如REST API),它将专门访问数据库。使这些服务不依赖于数据库,而是依赖于此API,并将数据库与消费者,报告和策展服务隐藏起来。

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

suggested microservices architecture