当前位置: 首页 > 知识库问答 >
问题:

用Django rest框架跨微服务共享数据库关系

袁山
2023-03-14

我有两个django REST API项目,我将它们解耦为微服务架构,其中一个服务是(SSO),它处理身份验证(我使用的是基于JWT令牌的身份验证)并管理用户信息,另一个是工资单服务。

问题是user与工资单服务中的某个模型有关系。具体来说,我在工资单服务中有一个员工类,它有一个user_id字段。这是我将添加用户UUID的地方,我将从查询SSO服务中获得。

考虑到每个服务都有自己的数据库,我如何跨微服务共享数据库。

共有1个答案

蒋星雨
2023-03-14

跨有限上下文共享数据库是不可取的,因为每个微服务都应该能够更改其保存数据的方式。允许多个微服务管理数据库会导致您陷入死星陷阱模式

但是,您可能希望向您的工资单服务发送身份验证上下文中的用户数据的副本/更新。通过这种方式,您可以拥有独立的数据持久性策略。一种方法是在您的身份验证上下文上实现事件发射策略,该事件发射策略将负责广播身份验证上下文上所做的数据更改,来自另一个有界上下文的订户可以侦听这些更改,以便他们可以在自己的持久层上存储您的用户数据的副本。

 类似资料:
  • 我不清楚如何取回购买服务不保存的数据--例如:用户的全名。当试图通过购买用户名进行更复杂的搜索购买时,问题会变得更严重。 我认为,显然可以通过在两个服务之间同步用户来解决这个问题,方法是在用户创建时广播某种类型的事件(并在购买服务端只保存相关的用户属性)。在我看来,这远非理想。当你有数百万用户时,你如何处理这个问题?您会在每个使用用户数据的服务中创建数百万条记录吗? 另一个明显的选择是在用户服务端

  • 在所有情况下,重要的是,如果允许用户Y访问该公司,微服务本身仍然必须检查是否允许用户Y对该公司进行某种操作。因此,此用户到公司的匹配仅用于确保用户对公司有访问权限。 我并不是真的很喜欢这些方法,因为将消息放入队列(1)意味着每个服务都必须被告知一个更改。使用Zuul验证(2)也不是真正实用的,因为它应该只是一个网关。

  • 问题内容: 我实际上是在阅读有关微服务体系结构的文章, 但是,似乎他们正在以最简单的方式处理这些事情, 而无需进行深入的解释。 为了向您解释我的问题,我将向您展示我的实际小体系结构: 在此处输入图片说明 所以,这就是我要使用的。在技​​术上做任何事情之前,我需要更多的 理论信息。 我的网域描述 我有一些基于移动和浏览器的客户,他们能够在 应用程序上建立联系,获得他们的用户信息,并能够查询 有关所购

  • 我正在设计一个微服务架构中的评审分析平台。 应用程序如下所示; 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使

  • 我的微服务架构中有几项服务。 其中两个服务(服务A、服务B)有不同的api,并提供不同的域逻辑。然而,它们确实共享一些应该从Redis返回的逻辑-用户状态。 当用户状态更改时,我正在从第三个服务发布到我的所有微服务 解决方案: > 我可以创建另一个服务,负责“用户状态”并将保存Redis上的所有用户数据。缺点:我的客户端将对每个api请求进行额外调用(以获取用户状态)。 为每个微服务复制用户状态数