更简单的概述请见本博客底部，那里还包括一个计算器。
Microsoft正在改变F&O应用中的基础设施工作方式。在统一环境中，弹性计算用共享容量模型取代固定环境层，该模型根据实际使用情况自动扩展。沙盒和生产环境一开始就不再选择二级、三级或类似规模，而是采用统一的Power Platform容量模型。
实际上，这意味着客户不再以同样的方式围绕固定基础设施规模进行规划。AOS层仍然是核心计算层，但随着需求增长，AOS实例数量可能会增加。Microsoft将此描述为一种模型，计算是根据真实工作负载而扩展，而非预先选择的环境层级。
Microsoft公布的参考点非常重要。每个AOS实例对应65万个Power Platform Requests（PPR）。沙盒和生产环境至少有两个AOS实例，环境总共可扩展至80个AOS，分布在最多40个交互实例和40个批处理实例中。统一开发者环境是例外，并且固定在一个AOS。
为什么这样更简单
最大的变化是容量不再是作为命名基础设施层级购买的。容量来自租户范围的PPR权利。Microsoft将该权限定义为50万基础PPR，外加每个分配用户许可证的5000PPR，并在需要更大空间时可选5万PPR附加包。
这让模型更容易向客户解释。老问题是，“我们需要哪个环境层级？”新的问题更接近于：“我们预计有多少工作量，以及我们希望有多少共享容量可用？”这在操作上是一个更简单的模型，但也意味着客户需要更多地考虑租户之间的使用模式。
成本随工作量而变化
Microsoft 并未将 PPR 直接按请求定价，但 Microsoft 确实销售 50,000 PPR 的附加包。这为客户提供了一个实际的参考点，帮助他们了解额外利润可能的费用，尽管具体商业价格会因地区和协议而异。
重要的变化是概念上的。在旧模式下，客户无论是否全部使用，通常都要为固定容量付费。在弹性计算下，闲置基线容量不再是规划难题，而繁重活动则更加明显。高并发、API突发、数据宇宙驱动的流量和大批量工作负载现在成为最重要的因素。
这里也没有滚动转存的概念。Power Platform请求限额是在滚动的24小时内测量的，因此未使用的请求余裕不是客户可以存起来并延续到后续峰值的。这强化了这是一个实时用电模型，而非存储的月度配额的观点。
最重要的是要明白：5000和40000并不是同一个数字
这正是许多人感到困惑的地方。Microsoft 用一种模型来衡量弹性计算容量，另一种用于许可用户请求限制。对于弹性计算，这个数字是每个分配的用户许可证 5,000 PPR，加上租户范围的 500,000 PPR。这个数字有助于确定环境的扩展范围。
另外，Microsoft 也记录了授权用户 Power Platform 请求限制。对于付费的 Dynamics 365 企业用户，在请求限制模型中，文档显示的请求限制为每用户每 24 小时 40,000 个请求。这个数字与请求限制行为和限速有关，但不应被纳入弹性计算 AOS 计算中。这两种不同的机制回答了两个不同的问题。
一个有用的解释方式是这样的。5000个数字有助于回答“这个许可证为租户贡献了多少弹性计算容量？”4万个数字有助于回答“这位持证用户在24小时内能提出多少请求，之后请求限制才会生效？”它们有关联，但不能互换。
示例：100名供应链管理用户
假设一个客户有100名分配的供应链管理用户。对于弹性计算，Microsoft的公式给出了50万基础PPR加上100×5000 PPR，等于1,000,000 PPR。Microsoft自己的示例表将此映射为2个AOS容量。
所以客户应该这样看待这个问题，而不是“100个用户意味着4,000,000 PPR用于扩展”。那就是将用户请求限制模型和环境容量模型混淆。对于弹性计算来说，相关数字是1,000,000 PPR租户权限，而不是每用户40,000请求上限。
还需记住，附加许可不会创造额外的平台权限。Microsoft的许可指南指出，附加许可不包含额外的平台权限，而是使用分配的基础许可的权限。因此，客户不应假设基础许可加上附加许可会使他们的弹性计算积累翻倍。
多个环境依然重要
尽管沙盒和生产环境现在使用相同的弹性计算模型，客户仍需在租户层面思考。测试、UAT、Golden及其他环境不再作为孤立的固定层级规划。它们处于同一整体容量模型中，当测试、刷新、迁移、集成和批处理同时进行时，运营需求仍然可能影响它们。
这在实施过程中尤为重要。在那个阶段，客户通常会有多个活跃环境，直到最终生产许可位置完全建立。如果这些环境需要在迁移、测试周期或并行工作负载期间进行扩展，可能需要临时购买额外的5万PPR附加包，直到最终许可模式建立。
哪些更便宜，哪些更难
可能变得更便宜的是未使用的基础设施。客户不再需要为了安全而过度购买固定层级。基线环境和闲置容量的浪费减少，沙盒与生产规划也更简单，因为两者都遵循相同的容量模型。
可能变得更昂贵的是持续的活动。大量集成、API流量、Dataverse调用和大规模批处理工作负载现在更直接地转化为可见的容量需求。该模型更高效，但也使成本更受实际使用影响。
这也使预算制定变得更困难。在固定层级下，基础设施成本即使效率低下，也更容易预测。在弹性计算下，客户可能需要随着时间调整PPR容量，尤其是在需求波动或多个活跃环境中。该模型在技术上更简洁，但财务上不那么静态。
所以如果你没有更多的PPR容量，想增加第二个沙盒环境，预计会买40个PPR附加包，每个大约50美元=每月约2000美元。
如果你需要额外的数据库容量，记得买一些 Dataverse 数据库容量的附加组件，价格是 40 美元/GB/月。
有几个重要的限制需要注意
目前并非所有计算都被该模型完全覆盖。像商业规模单元和电子商务相关工作负载这样的组件，在公开文档中并未明确描述为同一弹性计算模型的一部分，因此客户应谨慎，不要假设完全对齐。这仍是一个不断变化的领域。
还值得注意的是，统一环境是通过 Power Platform 管理中心管理的，而非生命周期服务。Microsoft 当前文档明确将财务和运营统一环境定位为 PPAC 管理，且无 LCS 足迹。
总结感想
弹性计算是F&O的一次有意义的转变。它用共享的PPR驱动容量模型取代固定层级，为沙盒和生产提供相同的计算框架，并允许客户无需经历旧的基础设施流程即可增加容量。
最简单的客户结论是：停止分层思考，开始以工作负载为思维。如果工作负载较轻，模型更简单且通常更高效。如果工作负载繁重或不可预测，模型仍然灵活，但需要更注重容量、集成和预算。
附注：本文部分内容是AI协助的，但我是作者。
参考文献：
许可信息：https://www.microsoft.com/en-us/licensing/product-licensing/dynamics365 关于弹性计算的F&O文档
Microsoft https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/elastic-compute
我从一个朋友那里得到这个（如果他愿意透露名字，可以留言
）：
弹性计算
财务与运营应用根据实际使用量自动扩展计算能力——没有固定层级，没有支持工单，也没有猜测。
为什么选择Elastic Compute？
相较于传统生命周期服务模式，有三大基本优势。
同一性能模型
沙盒环境和生产环境共享相同的弹性计算模型。沙盒中的性能测试反映了生产环境。
无分级选择
计算容量由您的Power Platform Request（PPR）权限决定，并自动扩展——没有层级锁定。
＋简单容量添加
从M365管理中心购买更多PPR附加包，即可立即提升计算上限——无需合同或升级。
一览
弹性计算的工作原理
AOS层是主要的计算组件。实例是有状态的，内存中保留会话状态，并由具有会话亲和力的 Azure 负载均衡器前置。
架构概述
用户👤👤👤互动环节OData / API 调用动力平台数据宇宙虚拟表格流程与插件批次作业背景加工Azure Load平衡器⚖️会话亲和力请求分发通往同一AOS的路线每用户会话AOS互动 #1X++ 业务逻辑内存中的会话状态AOS互动 #2X++ 业务逻辑内存中的会话状态…最多可互动40人AOS批次#1–40背景职位处理独立缩放持久存储层🗄️Azure SQL元数据与事务状态⚡缓存层性能加速📦Blob存储文档与二进制数据外部化——在规模事件中存活下来
部署到中部
环境从中等规模的基线开始——不是最小，也不是最大——因此它们能立即准备好应对典型工作负载。
基线与弹性尺度模型
最高等级（80 AOS）弹性放大区自动 ·无停机 ·透明基线部署（“中间”）基线以下环境从不低于基准线最低要求（2个AOS）高峰用电量正常负载仅在维护窗口计算容量时间→
放大触发器
高并发会议
许多交互用户同时访问环境，推动了交互式AOS实例的扩展。
突发API流量
OData或自定义服务调用的峰值会触发额外的AOS实例来吸收负载。
大批量加工
大型批处理作业队列会触发批处理作业实例的独立扩展。
电力平台调用
来自流、插件或应用的 Dataverse 虚拟表流量增加会触发弹性扩展。
规模扩大与规模减少流程
检测到需求
平台监控会话、API流量和批处理队列深度
放大
横向新增AOS实例——零停机时间
负荷重新分配
负载均衡器将流量分配到所有实例
维护窗口
会谈耗尽，移除多余AOS，恢复基线
Power Platform 请求与计算容量
PPR是衡量计算量分配的单位。每个AOS实例需要650,000个PPR。
PPR的累计方式
全租户基地
50万PPR
任何购买Dynamics 365时自动包含。
按用户许可
5,000 PPR / 许可证
每分配一个用户许可证，都会加入租户的总PPR池。
附加包
每包50,000 PPR
从Microsoft 365管理中心购买。
PPR计算公式
500,000租户基础PPRs+许可证×5,000张按用户累计+50,000包×附加包（可选）=总PPR数÷ 650,000 = AOS楼层：2个AOS • 上限：80个AOS（40个互动班+40个批次）
按用户许可数量划分的AOS容量
每个AOS需要650,000 PPR • 至少2个AOS • 最多80 AOS
| 用户许可 | PPR计算 | 总PPR数 | AOS容量 |
|---|---|---|---|
| 20分钟（分钟） | 500,000 + （20 × 5,000） | 600,000 | 2 AOS（楼层） |
| 100 | 500,000 + （100 × 5,000） | 1,000,000 | 2 AOS |
| 250 | 500,000 + （250 × 5,000） | 1,750,000 | 2 AOS |
| 500 | 500,000 + （500 × 5,000） | 3,000,000 | 4 AOS |
| 1,000 | 500,000 + （1,000 × 5,000） | 5,500,000 | 8 AOS |
| 2,500 | 500,000 + （2,500 × 5,000） | 13,000,000 | 20 AOS |
| 5,000 | 500,000 + （5,000 × 5,000） | 25,500,000 | 39 AOS |
| 10,000+ | 500,000 + （10,000 × 5,000） | 50,500,000 | 77 AOS |
PPR与AOS计算器
PPR有两个目的
1. 容量权利
PPR决定了你的环境可以扩展到多少AOS实例。PPR越多=计算上限越大。
2. 请求限速
PPR还管理Power Platform操作的限速限制——包括Dataverse调用、插件和流程。这些限制与AOS容量无关。
统一开发环境
开发者环境是弹性扩展的例外。
环境类型比较
沙盒与制作最低2 AOS — 最高80 AOS⬆️放大⚖️基线⬇️缩小🔄弹性PPR✓ 全弹性计算开发者（UDE）修正了1个AOS——无缩放单一AOS实例VS 调试器已附加✗ 无弹性计算
生命周期服务与统一环境的比较
弹性计算消除了固定层级的摩擦、手动缩放以及沙盒/生产不匹配。
生命周期服务（Legacy）
- 购买时选定的固定等级（第2至第5层）
- 沙盒≠制作表现
- 需要合同修订（EA/CSP）以改变容量
- 扩展所需的支持工单
- 为每个生产环境单独的LCS项目
- 每个环境最多3–12个AOS（按等级划分）
- 面向开发者的云托管虚拟机
统一环境（弹性）
- 弹性计算基于PPR自动计算尺度
- 沙盒 = 生产 — 相同产能模型
- 从M365管理中心购买PPR插件
- 自动扩展，零停机时间
- 直接从租户容量池提供服务
- 每个环境最多80个AOS（40+40）
- 统一开发者环境，单一AOS
| 相位 | 生命周期服务 | 统一环境 |
|---|---|---|
| 计算模型 | 购买时的固定等级 | PPR上的弹性自动比例 |
| 沙盒=生产？ | 不——不同层级/SQL/AOS | 是的——同型号，最大比例 |
| 容量变化 | EA/CSP修正案或工单 | 通过M365管理层获得PPR插件 |
| 缩放行为 | 手动换级+停机时间 | 自动放大（无停机时间） |
| 创建环境 | 每个等级购买附加槽 | 可用存储空间（需要1 GB） |
| 多部制作 | 需要新的LCS项目 | 容量池中的供应 |
| 性能测试可靠性 | 层级不匹配=不可靠 | 计算上限相同 |
| Max AOS / 环境 | 3–12 AOS（因等级而异） | 最多80个AOS（40+40） |
| 开发环境 | Cloud-hosted Azure VMs | UDE 与单一 AOS 合作 |
增加容量：附加包示例
拥有20个许可证（60万PPR）的客户购买40个附加包，以达到260万PPR，并将AOS从2提升到4个。
附加包加成
之前20个许可证→60万PPR低于65万的门槛AOSAOS2 AOS（楼层）→+40包（+200万PPR）之后60万 + 2 名 = 260万 PPR → 4 AOSAOSAOSAOSAOS4个AOS（2个互动+2个批次）
主要要点
弹性计算用灵活、基于PPR驱动的模型取代固定层级，该模型可自动扩展。