我在 Azure 中拥有 STAGING 和 PROD 环境、Web 应用、SQL 数据库等。目前，PROD 的 SQL 数据库规模远高于 STAGING - 这并不奇怪。
我认为将这些 SQL 资源与 SQL Elastic Pool 集中在一起可以节省一些资金。但我担心这会在 STAGING 和 PROD 之间造成耦合，这让我内心深处认为这不是一个好主意。
哪些合法的缺陷可能合理地影响性能、可靠性、安全性等？
答案1
我所遇到的共享 Stage 和 Prod 的最大阻力来自网络方面。如果您必须展示 Stage 和 Prod 之间的明确界限，则不应同时使用弹性池。除此之外，没有任何真正的技术缺点，您始终可以将单个数据库与池混合搭配。在大多数情况下，弹性池更具成本效益，但请注意以下几点：文档。
弹性池不按数据库收费。无论使用量如何，也无论池处于活动状态的时间是否少于一小时，您都需要按池在最高 eDTU 或 vCores 下存在的每个小时付费。
答案2
如果您有客户或合同要求需要物理分离 N 层，那么您就不能这样做。从安全角度来看，将两个环境结合起来是一个非常糟糕的主意。火上浇油的一个好方法是，如果管理层因为成本而推动单一池，那么我反驳说，我很震惊，这家公司的价值不高于第二个池的成本。我见过高管试图在一个项目上削减 5-10 万美元，我为此指责他们，当然他们讨厌我，但这是事实，不是意见。被黑客攻击是何时发生的场景，而不是是否会发生。您只能通过适当的设计来设计更安全的东西。如果这家公司不能以 5-10 万美元的价格出售，我们就有麻烦了。您永远不应该在安全方面吝啬，或者为什么不公开发布所有数据，那么如果这是他们的问题，为什么要尝试保护它呢？如果您还没有，请查看 NIST 800-53 R4 以很好地了解安全框架。此外，CIS-CAT 及其优秀的扫描工具也可以帮助提高安全性。