【问题标题】:How to share common Data over several Microservices如何在多个微服务上共享公共数据
【发布时间】:2018-10-07 01:39:19
【问题描述】:

我正在写一篇关于微服务的学士论文。

我正在尝试将单体应用拆分为微服务,但现在我遇到了一个问题,即数据库中有一些表与多个微服务相关。 没有机会将此数据拆分为特定领域的视图。

我的方法是使用该特定表创建一个新的数据库模式,并让所有微服务从中读取。 那将是一种共享内核方法,微服务专家不推荐。

您对这个问题有什么经验或建议吗?

你对类似问题的书籍有什么建议吗?

【问题讨论】:

  • 我建议您除了从技术、数据优先的角度之外,还从语言和业务角度来处理该主题。为什么在两个微服务中需要相同的概念?您需要所有数据还是只需要数据的各个方面?它在两个微服务中的命名方式是否相同?真的是同一个概念吗? IE。子域和限界上下文建模。
  • @guillaume31 我已经完成了 DDD 的战略设计部分,并与开发人员和领域专家进行了很多交流。我正在使用的系统旨在分析一些数据并检查一切是否正常。因此有不同的用例。每个用例都在分析几个表。
  • 你的上下文地图是什么样子的?
  • 有 4 个有界上下文,它们通过共享内核依赖于公共数据。我的方法是让有界上下文在没有写权限的情况下从共享数据库中读取
  • 如果不是 BC,谁有写权限?那是什么常见的数据?

标签: domain-driven-design microservices


【解决方案1】:

您可以创建单个微服务来管理这些公共数据(例如:国家或地区数据等)并在所有微服务之间复制表。

这个微服务是管理这些数据的单点(使用 CRUD)。在创建、更新或删除操作中,您使用异步通信(kafka、rabbitMQ)同步所有微服务

使用此解决方案,所有微服务都相互独立,并且无需 http 调用即可与数据同步,以实现最佳速度性能。

【讨论】:

    【解决方案2】:

    一般的方法是复制这些数据。每个微服务都有一份工作所需的数据副本。如果您认为这会使您的解决方案变得更加复杂,那么您是对的,这是为了获得可独立发布的隔离服务的好处而进行的权衡。

    另外需要考虑的是,如果您有 N 个微服务需要的不仅仅是对相同数据位的引用,那么最好将这些用例放在一个服务中,而不是将其分解。 Fred George 有一个很好的演讲,谈到要小心尝试将微服务拆分为“实体服务”:

    https://www.youtube.com/watch?v=vs_XiP5Lkgg

    我建议不要允许多个独立部署的服务读取和写入相同的数据,因为您最终会遇到防止耦合的情况,例如该数据的架构迁移没有潜在风险。

    【讨论】:

      【解决方案3】:

      您应该熟悉 Pat Helland 的论文 Immutability Changes Everything

      您还应该查看 Udi Dahan 的 Data Duplication and Replication,但请仔细阅读:Udi 的服务语言会小心区分物理边界和逻辑边界。确保您在任何特定时间都清楚他所描述的内容。

      【讨论】:

        猜你喜欢
        • 2019-11-19
        • 1970-01-01
        • 2016-07-30
        • 1970-01-01
        • 2015-06-10
        • 2017-05-29
        • 2018-05-01
        • 2018-11-16
        • 1970-01-01
        相关资源
        最近更新 更多