如何使用微服务架构处理共享数据源
我的微服务架构中有几项服务。
其中两个服务（服务A、服务B）有不同的api，并提供不同的域逻辑。然而，它们确实共享一些应该从Redis返回的逻辑-用户状态。
- 当用户状态更改时，我正在从第三个服务发布到我的所有微服务
解决方案：
>
我可以创建另一个服务，负责“用户状态”并将保存Redis上的所有用户数据。缺点：我的客户端将对每个api请求进行额外调用（以获取用户状态）。
为每个微服务复制用户状态数据源（持有多个redis实例），并为每个请求独立返回。缺点：我将复制我的数据并复制Redis实例（每个微服务都将访问自己的）
有一个 Redis 数据源，而所有服务都将使用它。缺点：在服务之间复制redis-logic（为了检索数据），并使用一个共享数据源打破微服务原则
你建议做什么？
共有1个答案
如果你想保持微服务架构的稳固，我肯定会选择数字 1;如果您将“用户/用户状态”视为可以自行运行的完全独立的产品。
我认为一个额外的调用来防止冗余的实现/数据是要走的路，如果Redis在它后面，并且前面的API正在执行，那么你不应该对额外的调用有问题。
如果不是这样，那么2将是一个很好的解决方案。你将面临关于数据完整性和复制问题的挑战，但它是方法之一。
-
在所有情况下，重要的是，如果允许用户Y访问该公司，微服务本身仍然必须检查是否允许用户Y对该公司进行某种操作。因此，此用户到公司的匹配仅用于确保用户对公司有访问权限。 我并不是真的很喜欢这些方法，因为将消息放入队列（1）意味着每个服务都必须被告知一个更改。使用Zuul验证（2）也不是真正实用的，因为它应该只是一个网关。
-
我不清楚如何取回购买服务不保存的数据--例如：用户的全名。当试图通过购买用户名进行更复杂的搜索购买时，问题会变得更严重。 我认为，显然可以通过在两个服务之间同步用户来解决这个问题，方法是在用户创建时广播某种类型的事件（并在购买服务端只保存相关的用户属性）。在我看来，这远非理想。当你有数百万用户时，你如何处理这个问题？您会在每个使用用户数据的服务中创建数百万条记录吗？ 另一个明显的选择是在用户服务端
-
在我们公司，我们正在从一个巨大的单体应用程序过渡到微服务架构。这一决定的主要技术驱动因素是能够独立扩展服务的需求和开发的可扩展性——我们有十个Scrum团队在不同的项目（或“微服务”）中工作。 过渡过程很顺利，我们已经开始受益于这种新的技术和组织结构的优势。现在，另一方面，我们正在努力解决一个主要的痛点：如何管理这些微服务之间依赖关系的“状态”。 让我们举一个例子：其中一个微服务处理用户和注册。该
-
我正在设计一个微服务架构中的评审分析平台。 应用程序如下所示； null null 问题在于，验证服务需要获取site-a的所有评论，应用验证规则并生成错误（如果有的话）。我知道共享数据库模式和实体打破了微服务体系结构。 一个可能的解决方案是 每当验证服务需要对站点进行审查时，它就会请求网关，网关会将请求重定向到审查服务并采取响应。 这种方法的两个可能缺点是 验证服务是否知道网关？是否会带来依赖？
-
当前体系结构： 问题： 我们在前端和后端层之间有一个两步流程。 null 微服务2(MS2)需要验证I1的完整性，因为它来自前端。如何避免对MS1进行新的查询？最好的办法是什么？ 我试图优化的流删除了步骤1.3和2.3 流程1： null 流程2： 2.1用户X已在本地/会话存储中存储了数据(MS2_Data) 2.2用户X在MS1上保留数据(MS2_Data+MS1_Data) 2.3 MS1使
-
我有两个django REST API项目，我将它们解耦为微服务架构，其中一个服务是（SSO），它处理身份验证（我使用的是基于JWT令牌的身份验证）并管理用户信息，另一个是工资单服务。 问题是与工资单服务中的某个模型有关系。具体来说，我在工资单服务中有一个类，它有一个字段。这是我将添加用户的地方，我将从查询SSO服务中获得。 考虑到每个服务都有自己的数据库，我如何跨微服务共享数据库。