跨域名与环境共享Azure Front Door是否存在不建议的理由？

先说说这么做可能踩的坑 #

• 故障牵连范围太广：要是这个实例出问题——不管是配置改错了还是Azure服务临时中断——所有绑定的开发、测试、生产应用全都会受影响，不像分开实例那样，某个环境挂了只会波及自己。
• 配置越搞越乱：多个端点、路由规则、源组堆在一个实例里，时间久了配置逻辑会变得复杂，改个生产环境的规则，一不小心就可能影响到开发环境的流量。
• 权限不好控：如果不同团队管不同应用或环境，单个实例很难做到精准权限隔离，搞不好开发人员能误碰生产环境的配置，风险不小。
• 容易触配额上限：Azure Front Door对单个实例的端点数量、路由规则数有配额限制，塞太多应用和环境进去，很快就会碰到天花板，到时还要走扩容申请流程，反而麻烦。
• 排查问题更费劲：所有环境的流量日志混在一起，要查某个应用的问题，得额外过滤一大堆无关日志，效率很低。

当然，成本优势是实打实的 #

• 标准版每月35美元的固定费只掏一次，不用每个实例都付一遍，数据传输费按实际用量算，长期下来能省不少钱。
• 所有配置都在一个控制台里，小规模场景下管理起来确实方便，不用来回切换多个实例页面。

给你个参考建议 #

如果你的团队规模小、应用不多，而且能严格把控配置操作，用单个实例完全没问题，但要做好这几点：

• 给不同环境/应用的配置加清晰的命名前缀，比如dev-xxx、test-xxx、prod-xxx，一眼就能区分
• 开配置变更的审核日志，谁改了什么一目了然，出问题能快速追溯
• 用Azure RBAC把权限拆细，比如开发人员只能碰开发环境的配置，碰不了生产的
• 定期备份配置，万一误操作了能快速恢复

但如果是中大型团队，或者生产环境对稳定性要求特别高，还是建议按环境分开实例——毕竟生产环境不能因为开发环境的操作失误就跟着遭殃，稳当比省钱更重要。

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