在基于微服务方法（更具体地说是Azure Service Fabric）从头开始编写解决方案时，我想到了拆分用户身份（即登录凭据，声明等）和用户配置文件（可能包含以下内容）的想法一些社交信息，例如头像，指向社交网络的链接，生日等）。
对于身份，我将使用IdentityServer4（无状态ASP.Net Core），并且为了存储所有这些数据，我正在考虑使用实体框架+ SQL。该配置文件将通过连接到Cosmos DB（通过Mongo DB API）进行管理并存储在不同的微服务（无状态）上，从而成为NoSQL存储。
我不知道这种方法有什么缺点吗？
答案 0 :(得分：3)
您在这里混淆了很多东西。首先，您将实际的“用户”实体持久保存到数据库中。没有充分的理由从中拆分“配置文件”，因为所有这些只是关于用户的数据。如果您使用身份来管理用户，角色等，那么它的设计应从头开始即可扩展，这意味着将用户数据放在用户实体上。单独的配置文件实体仅出于不必要的目的而需要加入。
在更高级别上，一旦对用户进行身份验证（通过Identity Server），便有了主体。该主体基本上只是一组与特定“身份”（即经过身份验证的用户）相关的声明。声明来自多个地方，可能是用户记录，角色或什至第三方声明中的数据，例如何时使用外部登录帐户。索赔的来源大多无关紧要。
总之，没有任何理由要使用单独的个人资料实体，尤其是没有理由要使用完全不同的服务来使用个人资料。该概要文件服务不可避免地必须利用用户服务，因此两者之间存在着严格的依赖关系：一个明确的标志，即它不是真正的独立服务。实际上，这只会使您应用程序的其余部分变得更加复杂，因为您必须根据所关注的用户群来使用用户服务和个人资料服务。