微服务建议关注在两个服务之间共享状态

Posted 2023-04-18

【中文标题】微服务建议关注在两个服务之间共享状态

【英文标题】：Microservices advice concern to share state between two services

【发布时间】：2015-11-19 08:45:42

【问题描述】：

我正在关注微服务架构，我们有两个独立的服务

（用户服务，其他服务）

UserService 写入自己的数据源（mysql 和 Redis）

客户端向 UserService 写入更新

另一方面，客户端从 OtherService 获取数据，这需要来自 UserService 的一些用户状态。

OtherService 的延迟和吞吐量非常重要。

几个选项：

UserService 将在状态更改时更新 OtherService（比我打破 OtherService 的域责任，因为它不应该维护用户状态

OtherService 将向 UserService（通过 api）询问用户状态（增加了很多延迟，这对我来说很关键。我可以缓存但仍然.. 不确定那是正确的方式）

在 UserService 写入和 OtherService 读取时共享数据存储。共享同一数据源时也打破了微服务原则

你们认为应该怎么做？ 谢谢， 射线。

【问题讨论】：

您可以让 UserService 公开某种可观察的接口，其他服务可以在其中注册以收到有关 UserService 更改的通知。从 UserService 获取相关数据仍然是 OtherService 的工作。这样，两个服务之间的耦合就不会是显式的，并且您将允许其他服务实现相同的模式。

如何暴露“某种可观察的界面”。该服务使用休息来相互交谈..

UserService 应该有一个订阅端点，其他感兴趣的服务会调用它。他们应该提供自己的回调端点，用户服务将在其中发送更改通知。当状态发生变化时，UserService 会通知订阅者事件发生了变化。一种更通用的方法是使用所有服务都可以发布事件的事件总线。有关更详细的说明，请参阅this article。

我喜欢发布-订阅的想法，但这意味着每个消费者都将维护自己用户的状态数据源。 otherService1,otherService2...每个人都将拥有自己的数据源（在我的情况下为redis）..这不是很疯狂吗？你怎么看。如果您回答这个问题并且无法将其标记为已解决，那就太好了。

【参考方案1】：

我们在被动端和消息队列上使用冗余只读数据来进行此类场景的通信。我的意思是在您的其他服务端有一个用户状态表，并在消息来自您的用户服务时对其进行更新。它不会影响您的 OtherService 的可用性、性能和可扩展性。依赖性几乎为零。该方法唯一可能存在问题的方面可能是您的用户状态数据的新鲜度。通过新鲜度问题，我一般说的是毫秒。如果新鲜度问题对您来说非常重要，那么您最好的选择可能是结合两种服务。

【讨论】：

感谢您的回复。 1.“..在你的另一个服务端有一个用户状态表并更新它..”你说的表是什么意思？额外的数据源或？ 2. 我没有毫秒的刷新要求，而是分钟的刷新要求。

1.是的，您应该有重复的数据，但并非所有数据都只是您其他服务所必需的数据。 2.那么你应该对这种方法没有任何问题

没有复制的可能。但我是否也应该为需要用户详细信息数据的其他服务创建单独的数据源？

通常数据应该由您的 UserService 通过“真实服务”提供。不应该有多余的数据。每个数据所有者都应该提供他们的数据。至少如果你想拥有一个“真正的”可维护、可持续的微服务架构。因此，如果您需要来自 UserService 的数据，您应该使用它。但是在您的情况下，由于您的 OtherService 不能等待 UserService 我提供的是一种黑客攻击。我们正在为我们的一项服务使用完全相同的东西，该服务每天消耗近百万次，并且可以等待其他服务响应。

顺便说一句，如果您可以保证通过使用某些技术以非常低的延迟提供来自 UserService 的数据。就像在内存数据库redis等中一样，你仍然可以使用“正确”的方式。但既然我看到有“mysql”，那么延迟总是一个问题。

【参考方案2】：

我认为您列表中的选项 #2 是正确的做法。您没有在问题中提及延迟数字。

通常，MS 架构意味着您在多个区域的许多“机器/docker”上运行，任何实例都可能在任何给定时刻诞生或死亡，如果您不在同一个数据中心运行，那么无论您做什么会得到延迟。

我们（来自大型臃肿的企业应用程序）有时很难将应用程序垂直分解为逻辑功能块。因此，我认为值得考虑从 UserService 和 OtherService 中取出部分并制作另一个 MS。不要认为会有太多的 MS，公司实际上有 1000 多个，而且运行良好。不要害怕打破常规。