面向服务架构中的业务数据查询/报表

Question

去年的大部分时间，我公司一直在根据（微）服务架构的原则开发一个庞然大物并构建新产品。这一切都很好，并使我们在保持UI和后端逻辑分离并降低依赖关系方面具有很大的灵活性。

但是！

由于这一点，我们的业务中有一个重要部分越来越令人头痛，即报告。

由于我们确保服务之间不存在数据复制（和业务逻辑共享），因此每个服务都知道它自己的数据，如果另一个服务确实需要为该数据保留一个引用，他们通过ID（实体链接，基本上）。虽然其他方面很好，但报告并不好。

我们的业务通常需要创建关于与我们的客户发生的特定情况的临时报告。在'过去的日子'中，您做了一个简单的SQL查询，它加入了一些数据库表并查询您需要的任何内容，但这对于解耦服务来说是不可能的。这是业务看到的问题。

我个人不喜欢数据复制用于报告目的的后端，因为这可能会有另一种趋势发展成恶梦（它甚至已经在我们的传统巨石中）。所以这个问题实际上不是关于遗留巨石与现代微服务的关系，而是关于一般数据依赖关系。

你有没有遇到这样的问题，如果是的话，那么你是如何解决的？

编辑：

我们内部一直在讨论一些可能的解决方案如何解决这个问题，但他们都不是真正好的，我没有得到我要的答案又可以解决大规模的问题。

1. 良好的旧复制一切，让我们的人数字它是今天仍然使用的。从旧的庞然大物时代开始，BI /数据仓库团队重复了所有数据库，但同样的做法更加不方便，但对于所有使用数据库的微服务来说，至今仍是如此。由于各种原因，这种情况并不好，并且伴随着您所期望的共享沙箱癌症。

2. 构建一个单独的微服务或一组微服务，用于提取特定报告。他们中的每一个都连接到设置携带相关数据的微服务并按预期构建报告。这引入了更紧密的耦合，但对于大型数据集来说，这可能会非常复杂并且速度很慢。

3. 构建一个单独的微服务或一组微服务，每个微服务都具有从其他数据库在后台复制的数据库。随着团队数据库的耦合以及数据的直接复制，以及对正在使用的数据库技术的强烈依赖，这是个问题。

4. 让每个服务都向RabbitMQ发送一个事件，BI服务会启动，然后获取额外的数据（如果需要）。这听起来对我来说是最好的，但是到目前为止，实施起来最复杂，因为所有服务都需要开始发布相关数据。这是我目前亲自选择的，从非常抽象的层面来看，就是说。

Answer 1

解决方案是将来自不同服务的数据汇总到中央报告数据库 - 如果收集的数据按时间版本化，这是可行的 - 即您可以访问报告数据并获取时间点数据这是正确的（当时）

获取该数据的服务可以通过各种服务发布的事件或周期性导入，“日志”聚合或它们的组合。

我把这种模式aggregated reporting

注意，除了你仍然摆脱个人服务的事情，需要在数据上最新的汇聚解决方案具有固有的延迟（减少新鲜）

编辑： 考虑到您所做的修改和您所做的评论（即席查询），我想说您需要将此视为一次旅程，也就是说，您希望获得选项4通过从源头获取数据开始，您必须回答当前的临时需求，在开发过程中进行转换并添加更多源代码时转换为消息。

而且你可能要考虑服务之间的差（即不同意他们之间的内部数据结构，并有严格的界限）和方面（服务的半独立的部分，可以使用相同的源）

PS 我也写过，汤姆在评论中提到 - 基本上谈论这个想法 - 这篇文章是从2007年开始的，也就是我已经成功地将它应用了十多年了（不同的技术，从写模式转向在架构上读取等，但相同的原则）

Answer 2

所以，我不知道这会回答您的需求 - 但我会形容我们的总体思路BI：在我们的系统

1. 一切都产生一个事件：在后端的行动，移动应用程序中的操作 - 我们想要跟踪的所有事件都会生成相关数据（ID，时间，名称等）。
2. 所有事件都发送到一些通用的收集漏斗 - 它是一个需要事件的后端应用程序 - 确保它们是有效的 - 并存储它们。
3. 您可以将事件存储在一些非sql存储（如Elasticsearch）或云中（如Google的BigQuery）。
4. 一旦他们进入，它只是一个查询和交叉引用的问题，以获得您想要的整体图片。这就是我们的BI人员所做的事情：他们从我们收集的大量事件中生成一张图片。