10万级用户规模下Azure AD B2C生产环境性能相关问题咨询

首先可以明确的是，10万用户规模完全在Azure AD B2C的设计承载范围内，不需要担心基础能力不足，两个核心问题的实际表现和优化方案如下：

JWT 生成与校验性能 #

JWT的生成和校验逻辑本身和租户的用户总存量没有直接关联，这两个操作都是基于单次请求的上下文做运算，不需要扫描全量用户数据：

• 登录/授权流程里的JWT生成，单租户默认可以支撑每秒数千次请求，端到端耗时普遍在100~300ms区间，请求量远超默认阈值的话可以提交工单申请提升配额，不需要修改业务逻辑；
• 资源侧的JWT校验是本地用B2C公钥验签的操作，不需要请求B2C服务，耗时普遍在10ms以内，性能影响基本可以忽略。

Graph API 用户查询性能 #

Graph API的查询性能要看你用的字段类型和过滤规则：

• 内置字段的过滤，包括startsWith前缀匹配：displayName、mail、userPrincipalName这类高频查询的内置字段默认都有全局索引，10万用户规模下查询耗时稳定在200~500ms，不会有性能问题；
• 自定义扩展字段的过滤：默认状态下自定义扩展属性没有全局索引，直接对这类字段做过滤或者startsWith匹配会触发全表扫描，10万用户规模下耗时可能达到数秒甚至超时，startsWith这种字符串匹配操作的性能衰减会更明显。

性能优化方案 #

如果确实有扩展字段的查询需求，可选择的优化方案很多，你提到的标签分组方案是可行性很高的选择：

• 优先把高频过滤的枚举类标签（比如用户分组、用户类型、业务线标识这类可选值固定的属性）存到未被使用的内置字段里，这类字段默认有索引，作为前置过滤条件先缩小查询范围后再做其他匹配，整体性能可以提升70%以上；
• 如果必须用自定义扩展字段做查询，可以提交工单申请给指定的扩展字段配置全局索引，配置完成后startsWith操作的性能可以达到和内置字段相同的水平；
• 如果你们有复杂的多字段联合模糊查询需求，建议通过Graph API的增量同步接口，把B2C用户数据定期同步到业务侧自己的数据库，自定义索引满足个性化查询需求，增量同步的延迟普遍在5分钟以内，适配绝大多数业务场景。

内容的提问来源于stack exchange，提问作者LilleElefant