使用Azure App Configuration相比App Service自带配置（环境变量）有哪些优势？

• App Service自带的「配置」选项卡支持自定义键值对，应用程序会将这些键值对作为环境变量读取使用。
• Azure App Configuration是云端托管的集中配置服务，类似云端版app.config，可在其中定义键值对供App Service等应用访问调用。

据目前公开的最佳实践指引，对于不与特定部署环境绑定的配置值，推荐优先使用Azure App Configuration存储，而非App Service的「配置」选项卡。

仅使用App Service内置配置的核心弊端 #

很多开发者觉得两者功能接近，就算不需要特性标志、应用数量少的场景，App Service内置配置也存在几个明显的问题：

• 配置更新会触发应用重启：App Service的配置值修改后，默认会触发应用实例重启，对敏感业务会造成秒级甚至更长时间的请求中断；App Configuration支持配置热更新，无需重启应用即可生效。
• 无配置版本追溯能力：App Service的配置修改没有自带版本记录，改错配置后无法快速回滚到历史版本；App Configuration默认保留配置修改的历史记录，支持一键回滚。
• 跨环境同步成本高：就算只有单个应用，只要有开发、测试、生产多套部署环境，同一份通用配置需要在3个App Service实例中分别修改，很容易出现配置不一致的问题；App Configuration可通过标签功能实现同一份配置多环境复用，修改一次全环境生效。
• 权限管控颗粒度太粗：App Service的配置权限和App Service本身的运维权限绑定，只要有App Service的编辑权限就能改所有配置，没法实现「只允许开发者修改业务配置、不允许修改数据库连接串这类敏感配置」的细粒度权限控制；App Configuration支持针对单个键值对设置访问权限。
• 敏感配置存储有风险：App Service的配置虽然支持加密存储，但无法和密钥管理服务无缝联动自动拉取敏感值，直接把密钥、连接串写在App Service配置里，有权限的人都能直接看到明文；App Configuration可以直接引用密钥保管库的机密，配置里只存引用地址，不会泄露明文敏感值。

选型参考 #

• 如果是和当前部署环境强绑定的配置（比如当前实例的部署标记、专属域名配置等），直接存在App Service内置配置里完全符合使用需求
• 如果是通用业务配置、跨环境复用的配置、需要热更新不需要重启应用的配置，不管应用规模大小，使用Azure App Configuration的收益都远高于直接使用内置配置

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