【问题标题】:SaaS implementation with Micro-services使用微服务实现 SaaS
【发布时间】:2018-08-03 14:25:27
【问题描述】:

我正在尝试在 ASP.NET Core 2.0 中构建基于 Web 的 SaaS 解决方案,在微服务架构的帮助下,基于令牌的身份验证和服务将托管在 Docker 上。每个客户都有自己的用户、产品和其他详细信息,以及具有共享模式的多个数据库。每个微服务都有自己的数据库(Schema-per-service)。

我遇到了一个障碍,我需要找到登录用户的数据库凭据(连接字符串),以便将数据库连接动态传递给相应的微服务以从相应的客户端数据库中获取数据?

【问题讨论】:

    标签: microservices


    【解决方案1】:

    我想你有某种微服务来处理客户端身份验证到他的 SaaS 帐户并生成一个令牌来使用 SaaS 微服务(如“私钥”),对吗? 这是微服务架构的完美案例:

    1. 创建一个微服务,将有关客户端环境配置的资源分配给域
    2. 此微服务使用客户端的私钥接收请求
    3. 然后请求身份验证服务验证传递的私钥
    4. 获取身份验证服务的响应和某种客户端的唯一密钥
    5. 使用与该客户端唯一密钥对应的环境配置进行响应(如果身份验证令牌与任何客户端都不匹配,则返回 404)

    现在有了这个微服务(我称之为“环境微服务”),你的 SaaS 的任何其他微服务只需要请求环境微服务来获取客户端的配置(数据库连接字符串、存储系统等)。从这一点开始,您可以在每个服务上实施一些缓存策略,以保持私钥映射到一组配置(如果您的模型允许,还可以保持数据库连接)。只需确保此缓存具​​有针对环境微服务验证令牌和配置的时间间隔。

    【讨论】:

    • 感谢 Vicor 的回复,客户端身份验证在 Identity 微服务中处理(它检查用户的身份并发送身份验证令牌而不传递私钥)。看起来,我需要在令牌本身中添加某种客户端的唯一键并调用环境微服务来获取客户端的配置(数据库连接字符串等)。
    • 只有一件事让我担心,我需要在每个微服务的 RESTful 方法中访问令牌,以便获取适当的客户端连接字符串并建立数据库连接,因为我无法在控制器的构造函数中访问令牌。如果微服务必须为多个租户(比如 50 个)提供服务,它将需要 50 个不同的连接字符串和那么多数量的连接池。这会影响请求性能吗?
    • 为避免您的身份微服务被请求淹没,您可以在需要该配置的每个微服务处将令牌到连接字符串的映射保持缓存(在内存或临时文件中)。因此,在第一次请求时,微服务将向 Identity 微服务请求连接字符串,在接下来的请求中,微服务可以查看缓存是否包含该令牌。您还可以实施缓存刷新策略(例如 x 秒后)。
    • 感谢 Vicor,将尝试将令牌映射合并到连接字符串缓存。
    猜你喜欢
    • 2020-09-20
    • 2019-03-02
    • 2018-03-28
    • 2019-11-01
    • 1970-01-01
    • 2021-04-10
    • 2016-04-07
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多