【问题标题】:Organization on database with userId field in a microservice archecture微服务架构中具有用户 ID 字段的数据库组织
【发布时间】:2020-10-19 18:10:50
【问题描述】:

我有一个关于微服务架构的问题。我有的例子:

  • 提供JWT(以Keycloak为例)的授权认证服务器
  • 2 个微服务,它们之间通过 REST 进行通信。
  • 1 微服务是一种用户服务,它在我的数据库中为来自 Keycloak 的每个新用户创建一个新用户(可能明天我们有 Google 或 Github,记住这一点很重要)。当我创建用户时,我将他的主题从声明中存储在特定字段中。
  • 1个微服务,存储creatorId,例如blog post的updateById。

最好将主题存储在我的 creatorId 和 updatedById 中(像这样,我不需要询问我的用户服务来确定谁是创建者)或存储我的用户服务中的 userId 和我的每次调用post-service 是发出请求的用户(所以我每次都发出休息请求,以通过将 JWT 令牌传递给用户服务来获取发送请求的用户)。

IMO,每次发送休息请求都会增加用户服务的负载,但对于 Google、Github 和 Keycloak,不同用户的主题 ID 可能相同。

【问题讨论】:

    标签: security oauth architecture microservices openid-connect


    【解决方案1】:

    我会执行以下操作,以便您将来可以迁移到不同的授权服务器(Google / Github)而不会产生太大影响:

    • 用户服务在其用户表中为每个新用户创建一行,并使用数据库代理键作为主用户 ID
    • 此用户 ID 保存到您的 creatorId / updateById 字段中
    • 同时 OAuth Id / Sub 声明是用户表中的一列,但不是业务逻辑中的主要用户标识符

    如果您在 Posts Service 中缓存声明,Posts Service 可以避免在每个请求上调用 User Service。我的一些资源可能会为您提供一些可以应用于您自己的解决方案的想法:

    【讨论】:

    • 所以我在令牌中添加了一个声明?使用我的用户服务?
    猜你喜欢
    • 2020-09-12
    • 1970-01-01
    • 2019-03-03
    • 2020-03-13
    • 2018-03-28
    • 1970-01-01
    • 2020-07-05
    • 2017-09-09
    • 2017-11-30
    相关资源
    最近更新 更多