我正在关注微服务架构，我们得到了两个独立服务
（UserService，OtherService）
UserService写入自己的数据源（mysql和Redis）
客户端向UserService写入更新
另一方面，客户端从UserService获取数据，需要来自UserService的一些用户状态。
OtherService的延迟和吞吐量非常重要。
几个选项：
当状态发生变化时，UserService将更新OtherService（因为它不应该维护用户状态，因此我违反了OtherService的域责任
OtherService会向UserService（通过api）询问用户状态（添加大量延迟对我来说至关重要。我可以缓存但仍然不确定这是正确的方法）
在UserService write和OtherService读取时共享数据存储...在共享相同数据源时也破坏了微服务原则
你们认为什么是正确的？ 谢谢， 射线。
答案 0 :(得分：1)
我们在被动端和消息队列上使用冗余只读数据来进行这类场景的通信。我的意思是在您的其他服务端有一个用户状态表，并在消息来自您的用户服务时更新它。它不会影响OtherService的可用性，性能和可伸缩性。依赖性几乎为零。该方法唯一可能存在问题的方面可能是用户状态数据的新鲜度。通过新鲜度问题我一般都在谈论毫秒。如果在你的情况下那个新鲜度问题很重要，那么你最好的选择就是结合两种服务。
答案 1 :(得分：1)
我认为列表中的选项＃2是正确的方法。你没有在你的问题中说过延迟数字。
通常MS体系结构意味着您可以跨多个区域运行许多“机器/码头工作者”，任何实例都可以在任何给定时刻出生或死亡，如果您没有在同一个数据中心运行，那么无论您做什么，会得到延迟。
我们（来自大型企业应用程序）有时很难将应用程序垂直分解为逻辑功能部分。因此，我认为值得考虑从UserService和OtherService中取出部件并制作另一个MS。不要认为它会有太多的MS，公司在1000年代中期确实存在并且工作正常。不要害怕在盒子外面这样做。