Orleans 容量规划与扩展实战：从工作负载模型到运行时过载防护

• 后端
• 微服务

Orleans 将 grain 激活（activation）与请求处理分布到集群中的多个 silo 上，集群容量会随活跃工作负载动态变化。本指南基于当前仓库中 capacity-planning.md 的核心方法论，系统讲解如何建立工作负载模型、测量激活吞吐量、确定 silo 规格与运行包络（operating envelope）、执行扩展与收缩，以及利用运行时负载脱落（load shedding）抵御过载；读完你可以获得一套可复现的容量测试流程与可落地的配置方案。

规划扩展：从"按活跃负载"而非"按注册总量"出发

Orleans 按需为 grain 身份创建激活，应用只面向 grain 身份寻址，而不关心激活具体落在哪个 silo。添加 silo 能为"可跨激活分区（partition across activations）"的工作负载增加容量。关键在于：

激活的资源消耗从某个 grain 身份第一次被使用的那一刻开始，因此集群规模必须根据"活跃工作负载"和实际资源使用来规划，而不是根据注册了多少 grain 类型或静态节点数。

实际运行包络（practical operating envelope）与应用和运行环境强相关，必须用具有代表性的测试来确定，测试应覆盖：工作负载形态、主机资源、网络、存储与集群（clustering）提供程序、外部依赖，以及恢复要求。

扩展所依赖的底层机制，可进一步阅读：

• 拓扑、网络与集群：silo 到 silo、客户端到网关、主机到提供程序三条网络路径的配置与连通性验证；
• 集群成员协议：成员加入、探活、离开与失败检测；
• grain 目录架构：激活定位与目录更新。

建立工作负载模型

容量测试的第一步是测量"生产形态"的混合负载，至少应覆盖以下维度：

• 按操作的每秒调用数与延迟目标（Calls per second and latency objectives by operation）；
• 按类型的活跃与总 grain 数（Active and total grain counts by type）；
• grain 状态大小、读写频率与序列化成本（Grain state size, read/write frequency, and serialization cost）；
• 热键（hot-key）集中度，以及对其他 grain 或外部服务的扇出（fan-out）；
• 定时器（timers）、提醒（reminders）、流（streams）与后台工作；
• 负载大小与客户端网关流量（Payload sizes and client gateway traffic）；
• 依赖延迟、限流（throttling）与连接数上限。

负载测试不能只做匀速压测，还应包含以下压力场景：

• 突发流量（bursts）；
• 单个 silo 丢失（one-silo loss）；
• 滚动替换（rolling replacement）；
• 依赖变慢（dependency slowdown）；
• 积压累积后的恢复（recovery after backlog accumulation）。

测量激活吞吐量

激活与去激活吞吐量受提供程序延迟、状态大小、应用生命周期代码、争用和 silo 形态影响。一次"冷调用"（cold call）可能包含：目录查找与注册、放置（placement）、对象构造、持久化状态读取、应用激活回调（OnActivateAsync）；去激活则可能包含应用回调、清理与目录更新。

应分别测试以下四条路径：

记录内置的激活/去激活聚合计数器与延迟，同时记录目录、存储、CPU、分配、垃圾回收（GC）与请求延迟信号。若需要按 grain 类型区分速率或延迟，应在 grain 生命周期代码周围添加应用级埋点（可观测性信号）。

若churn（激活流转）是瓶颈，可采取：

1. 移除OnActivateAsync中不必要的工作；
2. 批量访问依赖（batch dependency access）；
3. 针对受影响的 grain 类型调整 激活回收配置（CollectionAge默认 15 分钟、CollectionQuantum默认 1 分钟）。

保留更多激活是用内存换取更少的冷启动，属于典型的容量权衡。

关于"存储页即 grain"的建模提醒

当存储中的一页（page）构成独立可寻址的一致性边界时，可以把它建模为一个 grain；但一次扫描如果立即冷激活大量页面，每一页都要付出激活、消息与后端访问成本。评估以下替代设计：

• 更粗粒度的 grain；
• 使用存储后端 range/batch API 的有界批量读取；
• 专门的索引服务（indexing service）。

无论哪种设计，都必须限制扇出（bound fan-out）。

确定 silo 规格

选择可重复的 CPU 与内存规格，然后测量：

• CPU 饱和与调度延迟（scheduler delay）；
• 分配速率、GC 暂停时间与工作集（working set）；
• 激活数与每激活内存；
• 请求队列、拒绝/负载脱落率与尾部延迟（tail latency）；
• 网络连接数与吞吐量；
• 提供程序延迟与限流。

两个重要的平台边界教训：

• CPU limit 可能在节点 CPU 看似可用时就已经在节流进程（CPU limits can throttle a process even when node CPU appears available）；
• 内存 limit 可能在托管分配报告 OOM 之前，就在平台边界终止进程。

因此：requests 依据观测到的稳态用量设定，limits 必须依据已理解的平台策略与已测试的行为设定。同时为"失去一个主机或故障域后"的激活重新分布与流量预留 headroom；选择 silo 规格时，要在"重启/重新激活的爆炸半径"与"每进程运行时、连接、成员管理开销"之间取得平衡。

找到运行包络：一份可复现的容量测试流程

使用生产运行时版本、主机形态、网络、提供程序、序列化设置与代表性状态进行测试。推荐流程如下：

1. 定义延迟百分位、完成吞吐量、错误率、超时率与恢复目标；
2. 在固定集群规模下逐步增加负载，直到某一目标失败或某一资源饱和；
3. 以更大的集群规模重复，用**已完成吞吐量（completed throughput）**结合提交的工作量（submitted work）来选定运行包络；
4. 重复冷启动、热键、突发、扩容、缩容、滚动升级、依赖限流与 silo 丢失场景；
5. 在第一个持续瓶颈之下选择运行点，并为所需故障域预留 headroom。

将客户端可见结果与每 silo 的 CPU、调度延迟、内存、GC、网络、激活分布、请求队列、被拒工作、提供程序延迟/限流相互关联。注意：均衡的集群平均值可能掩盖单个饱和的 silo 或存储分区——务必逐 silo 核对，并使用部署版本实际发出的可观测性信号。

扩展与收缩

扩容（Scale out）

扩容要在饱和之前进行。缩放决策应基于以下信号的相关趋势（correlated trends），而非单一指标：

• 持续 CPU；
• 调度延迟；
• 尾部延迟；
• 激活压力；
• 网关负载脱落（load shedding）；
• 应用队列深度。

扩容的机制要点（详见 grain 放置与迁移）：

• 新 silo 加入后，会进入后续放置决策的候选集；已活跃的 grain 继续留在原 silo 运行；
• 成员收敛后，新激活可立即使用新增容量；
• 被回收/去激活的 grain 重新激活时，也能利用新容量；
• 实验性的 **激活重平衡器（activation rebalancer）**可迁移符合条件的激活以降低计数与内存偏差；实验性的 **激活重分区器（activation repartitioner）**则迁移激活以改善调用局部性（call locality）。两者均产生编译期实验性诊断（ORLEANSEXP002/ORLEANSEXP001），实现细节见 放置与激活平衡。

扩容时必须计入：

• 调度主机、启动进程、加入成员、预热缓存的时间；
• 对集群与存储提供程序的容量和连接影响；
• 大量 grain 在新/剩余 silo 上激活时的状态读取与序列化负载；
• 放置约束与集中工作量的 grain；
• 跨故障域所需的最小 silo 数。

缩容（Scale in）

缩容应比扩容更慢：

• 尽可能一次只选一个实例；
• 使用优雅关闭流程（先停止接收新流量、报告 not ready、IHost.StopAsync、让 Orleans 离开成员并去激活/移交运行时职责，最后在关闭截止时间后终止进程）；
• 等待集群健康稳定后再继续；
• 离开的 silo 在关闭期间去激活其普通激活，剩余 silo 必须留有足够容量处理重新激活、状态加载与被重定向的流量。

处理过载：运行时负载脱落与准入控制

无界队列会把过载转化为高延迟与内存压力。应组合使用：

• 应用入口的准入控制（admission control）；
• 有界队列与并发（bounded queues and concurrency）；
• 覆盖下游调用的请求截止时间（request deadlines）；
• 通过Orleans.Configuration.LoadSheddingOptions启用客户端网关请求拒绝与流队列流控；
• 防止单一工作负载饿死其他的每租户/每键限制。

负载脱落的配置与默认值

负载脱落的选项类源码位于 src/Orleans.Core/Configuration/Options/LoadSheddingOptions.cs，关键配置如下：

设置LoadSheddingEnabled = true后：

• 越过 CPU 或内存阈值即把该 silo 标记为过载（overloaded）；
• 启用客户端网关请求拒绝（client-gateway request rejection）；
• 使**资源优化放置（resource-optimized placement）**优先选择非过载候选；
• 流队列流控（stream queue flow control）使用 CPU 阈值暂停读取（LoadShedQueueFlowController）。

阈值应设置在平台硬限制之下，并在负载下验证拒绝与恢复行为；集群容量本身交给宿主平台的自动缩放器（autoscaler）调整。

// 在每个 silo 上配置负载脱落（示例） builder.UseLoadShedding(options => { options.LoadSheddingEnabled = true; options.CpuThreshold = 90; // 默认 95，建议低于平台硬限制 options.MemoryThreshold = 85; // 默认 90 });

注意：重试也消耗容量。要把重试流量计入负载模型，并使用指数退避 + 抖动（jitter）、重试预算（retry budget）与端到端截止时间。

选择租户拓扑

根据隔离与运维边界要求选择租户拓扑：

在共享集群中：按租户与键（key）划分热点工作，对每个租户施加准入与并发限制，并测试最偏斜（most skewed）租户的行为。当安全、数据驻留、独立升级或故障/资源隔离需要硬边界时，使用独立集群。混合多个租户池往往优于"一个无界大集群"或"每个小租户一个部署"两个极端。

重新审视模型

容量模型不是一次性工作。在以下变更后应重新评估：

• grain 状态或状态大小变化；
• 放置策略变化；
• 序列化器变化；
• 提供程序变化；
• 运行时版本升级；
• 主机规格变化；
• 流量形态变化。

同时，始终保持一份经过测试的应急容量程序（emergency capacity procedure），确保在紧急扩容时仍能保持身份（identity）、网络与提供程序限制不失控。关于放置与激活平衡机制的选型对比，可进一步阅读 Placement and activation balancing。

总结

Orleans 的容量规划是一条"测量驱动"的闭环：建立工作负载模型 → 分别测量激活/去激活路径 → 选定 silo 规格 → 用递增负载法找到运行包络 → 在饱和前扩容、缓慢优雅缩容 → 用负载脱落与准入控制守住过载边界 → 持续复审。配合本仓库中的 LoadSheddingOptions、ResourceOptimizedPlacementOptions 与激活回收配置，你可以在任何托管平台上建立一套可复现、可观测、可回退的容量管理体系。

• 后端
• 微服务