微服务架构:聊天服务或数据复制
Posted
技术标签:
【中文标题】微服务架构:聊天服务或数据复制【英文标题】:Microservices Architecture: Chatty services or data duplication 【发布时间】:2017-08-31 23:24:24 【问题描述】:TL;DR 服务应该选择将数据保存在其偶尔需要的本地数据库中,还是每次都向数据来源的服务请求数据?
让我们举一些网络商店/订购应用程序的通用示例。服务 A 是用户会话管理服务。它处理用户正在做什么、他能做什么等业务逻辑。用户可以创建自己的衬衫以供购买。服务 B 是一个数据聚合器,包含大量库存和可用数据。
用户开始创建衬衫,因此服务 A 向服务 B 请求,有哪些款式/颜色可用。服务 B 发送一个可能的选择列表,然后服务 A 为用户显示该列表。然后用户选择一件,对其进行定制,然后穿上一件新衬衫。同样,服务 A 必须向服务 B 请求可用的样式/颜色。
现在让我们假设在用户会话的生命周期内,这些样式/颜色不会改变,我们知道这将是一遍又一遍地检索相同的数据。不仅仅是这个用户,而是所有用户。所以在这种情况下,由于样式/颜色确实是服务 B 域的一部分,它们应该留在那里并住在那里,或者是否建议防止所有这些不必要的调用,并在第一次请求时(暂时)保存在服务 A 中会话生命周期的数据,以防止聊天服务。
这是一个过于简单的示例,但问题仍然存在于现实世界中。哪种方式更适合构建此设计? 这通常适用于例如当一些相当静态的数据正在通过某个服务时,并且该服务将在这些事务的生命周期内再次需要这些数据几次。所以我不确定该服务是否应该在生命周期中暂时保存它,知道数据不会改变,或者不关心它是否在生命周期内发生变化,或者选择更多的聊天服务并每次都继续请求。
【问题讨论】:
【参考方案1】:我必须赞扬你写得很好的问题,但答案当然很大程度上取决于你正在处理的业务逻辑。这个问题与最终一致性(一些无 sql 数据库提供的属性 - 如 Couchbase)有关。
最终,这是一个权衡问题:检索最新数据的“成本”与使用容易获得的陈旧数据的成本。
有几个因素:
数据多久更新一次?
更重要的是,当您使用陈旧数据时会发生什么(业务逻辑方面)。您的用户/应用是否可以接受它?
每次获取新数据对您的系统有何影响?这样做的基础设施成本是多少(机器/金钱)以及它会产生什么延迟?
【讨论】:
最重要的是,复制状态甚至可能导致数据源中的不同步 - 由于错误、停机时间等原因,通常甚至无法保证最终的一致性。因此,虽然过期缓存似乎没问题,但复制持久化数据也有风险。【参考方案2】:TL;DR 服务应该选择将数据保存在其偶尔需要的本地数据库中,还是每次都向数据来源的服务请求数据?
我不想这么说,但这取决于。这取决于您的业务需求。这取决于您是否想要拥有一个灵活的系统。如果service B
不可用,您希望service A
表现如何?你有两个选择:
您希望 Service A
拒绝工作,因为它无法从 service B
获取新数据。如果数据变化很大或者service A
中使用的数据必须始终是超新鲜的,您可以这样做。
您希望Service A
继续工作,可能通过通知用户数据可能不是最新的。在这种情况下,您应该通过监听事件或缓存将数据从 service B
复制到 service A
。
【讨论】:
【参考方案3】:有一种不同的解决方案可以“回避”这种权衡。
您的问题表明您更多地考虑“旧”“面向服务”的方法。也就是说,服务基本上是提供数据的面向数据的服务。比如“Inventory”、“Session”、“Customer”等。
另一种方法是,这与 DDD 有界上下文非常相似,根据业务领域分解应用程序。这导致了一个完全不同的架构,其中数据没有与在其上工作的功能分离。有点像面向对象。
这将导致 Shirt-Configurator 拥有自己的数据库,其中包含所有相关信息,包括会话、库存等。此外,还包括 UI。
另一个应用程序可能是结帐。结帐可以是一个完全独立的应用程序,只需将 URL 返回到 Shirt-Configurator 以获得正确的演示。 Checkout 应用程序不必调用甚至知道 Shirt-Configurator。
等等……
更多关于这种架构风格的信息:http://scs-architecture.org/
【讨论】:
这里的挑战是业务领域重叠很多。如果衬衫配置器需要库存,您要么将它们视为单个有界上下文(并创建一个大型单体),要么处理非常闲聊的通信以更新库存。我同意分离功能的一般想法,但这与微服务架构的更“微”变体形成对比。以上是关于微服务架构:聊天服务或数据复制的主要内容,如果未能解决你的问题,请参考以下文章