kin*_*ple 6 database soa reporting database-replication microservices
在去年的大部分时间里,我的公司一直在根据(微)服务架构的原则切割整体并构建新产品.这一切都很好,并为我们提供了很大的灵活性,可以保持UI和后端逻辑的分离,并降低依赖性.
但!
由于这一点,我们的业务中有一个重要的部分,即报告.
由于我们确保服务之间没有数据复制(和业务逻辑共享),因此每个服务都知道自己的数据,如果另一个服务确实需要保留对该数据的引用,那么它们通过ID来实现(实体链接,基本上).虽然它很棒,但报道并不好.
我们的业务通常需要创建关于客户发生的特定实例的临时报告.在"过去的日子"中,您创建了一个简单的SQL查询,它连接了几个数据库表并查询了您需要的任何内容,但是对于解耦服务是不可能的.这是业务所看到的问题.
我个人并不是后端报告用途的数据复制的粉丝,因为这可能有另一种趋势,即成长为一场噩梦(它甚至已经存在于我们的传统巨石中).所以这个问题实际上不是关于传统的单块与现代微服务,而是关于数据依赖性.
您是否遇到过这样的问题,如果是,那么您是如何解决的？
编辑:
我们一直在内部讨论如何解决这个问题的几个潜在解决方案,但它们都没有实际上是好的,我没有得到我正在寻找的答案,但它解决了大规模的问题.
很好的旧复制 - 一切 - 让我们 - 人们 - 想出它是今天仍然习惯的东西.从旧的整体时代开始,BI /数据仓库团队制作了所有数据库的副本,但是同样的做法更加不方便,但到目前为止仍然使用数据库的所有微服务都做了.由于各种原因,这并不好,并伴随着你可以期待的共享沙盒癌症.
构建一个单独的微服务或一组用于获取特定报告的微服务.它们中的每一个都连接到设置微服务,其中包含相关数据并按预期构建报告.然而,这会引入更紧密的耦合,并且对于大型数据集而言可能非常复杂且速度慢.
构建一个单独的微服务或一组微服务,每个服务都有从后台其他数据库复制的数据库.这是有问题的,因为团队数据库正在耦合,数据被直接复制,并且强烈依赖于正在使用的数据库技术.
让每个服务向RabbitMQ发送BI服务可以接收的事件,然后根据需要获取其他数据.这听起来对我来说是最好的,但到目前为止最复杂的实现,因为所有服务都需要开始发布相关数据.这是我个人现在所选择的,从一个非常抽象的层面,就是这样.
解决方案是将来自不同服务的数据聚合到一个中央报告数据库中 - 如果收集的数据按时间进行版本控制，这是可行的 - 即您可以转到报告数据并获取正确的时间点数据（为此时间）
可以通过各种服务发布的事件或定期导入、“日志”聚合或它们的组合来将该数据获取到服务。
我将这种模式称为聚合报告
请注意，除此之外，您仍然需要从各个服务获取需要最新的数据，因为聚合解决方案具有固有的延迟（新鲜度降低）
编辑：考虑到您所做的编辑和您所做的评论（即席查询），我想说您需要将其视为一次旅程，也就是说，您想要进入选项 4，因此从提取数据开始您必须从来源中回答当前的临时需求，随着开发的进展转换为消息并添加更多来源。
此外，您可能需要考虑服务之间的区别（它们之间不共享内部数据结构并且具有严格的边界）和方面（可以使用相同源的服务的半独立部分）
PS 我还写了Tom 在评论中提到的关于BI 和 SOA 的 InfoQ 文章- 本质上讨论了这个想法 - 这篇文章是 2007 年的，即我已经成功应用它十多年了（不同的技术，从写入模式到读取模式等，但原则相同）
| 归档时间： |
|
| 查看次数： |
427 次 |
| 最近记录： |