使用按上下文配置规划会话隔离与容量

容量从工作负载开始

浏览器容量是特定工作负载在特定主机上的表现。简单导航、媒体应用、文档生成和长期仪表盘，即使使用相同浏览器版本，也会产生完全不同的资源需求。如果页面、操作、网络条件、图形路径、存储策略和完成标准不同，其他部署给出的并发数字没有直接参考意义。

Per-Context 配置可以让授权会话分别拥有配置文件、存储、区域和网络路线，同时共享部分浏览器资源。这能够减少重复开销，但并不意味着页面本身不再消耗资源。活动文档、媒体、下载、后台任务、截图和应用脚本仍然会占用 CPU、内存、网络与文件句柄。

生产规划应从可测量的工作开始，而不是从承诺的上下文数量开始。定义一份代表性任务，在目标镜像上执行，观察稳定状态和峰值，再设定保留恢复余量的运行上限。浏览器、主机、页面组合或策略发生变化后，重新验证这个上限。

选择隔离边界

先决定哪些内容必须隔离。一个浏览器上下文可以在共享资源中拥有独立存储分区和已批准身份分配。这适合经服务所有者授权的测试租户、区域兼容性检查和相互独立的应用账号。

上下文不是独立的操作系统进程。如果工作负载需要不同进程权限、严格资源限制、独立扩展集合或独立故障域，应使用不同浏览器实例。如果边界还要覆盖操作系统和网络命名空间，则需要独立工作节点或容器。

应把边界决策写入服务策略。调度器要明确哪些任务可以共享浏览器，哪些必须使用独立实例，哪些必须进入专用节点。容量压力不能成为降低已批准隔离要求的理由。

每个上下文在整个生命周期中只使用一份身份分配。第一张页面或后台任务出现之前，绑定批准的配置文件、存储策略、网络路线、区域策略和任务负责人。如果身份计划发生变化，关闭当前上下文并建立新的分配。活动会话中途变更会让结果难以解释。

定义代表性任务

有效基准应从真实应用事务开始，而不是空白页面。选择能够代表生产的页面和操作。只有在账号所有者授权并能保护凭据时，才把登录过程纳入测试。如果正常任务包含媒体、下载、截图、文档处理或后台活动，也要在基准中覆盖。

用运维语言描述任务的到达、导航、工作、完成和清理。明确允许的最长时间、成功条件、重试策略和存储处理方式。这样调度器可以区分快速但不完整的运行与真正完成的任务。

使用生产所用的浏览器构建、部署镜像、主机类别、图形设置、扩展和网络类别。开发者电脑上的测试可以发现明显问题，但不能批准另一环境的生产上限。虚拟化和容器设置也会影响内存压力、共享存储和图形访问。

预热策略要与生产一致。如果工作节点会保持浏览器热状态，分别测量启动和热运行。如果策略要求每组任务创建新浏览器，则把启动和关闭计入结果。缓存、持久存储和连接复用也应遵循同一规则。

工作负载差异较大时，应建立多个任务类别。轻量状态检查和渲染密集报告不应共用一个平均成本。调度器可以为它们分配不同队列和上限，避免高成本任务占满全部容量。

测量完整生命周期

观察浏览器启动、上下文创建、页面活动、空闲、上下文关闭和浏览器停止。资源峰值可能发生在导航、媒体处理、截图或清理期间，而不是稳定状态。只在页面稳定后采样会漏掉真正限制容量的阶段。

记录主机可用内存、CPU 压力、存储活动、网络使用、打开文件、任务耗时、排队时间、成功率、上下文创建时间和关闭时间。这些是运维信号，不是浏览器信息探测。它们说明服务能否在保留恢复余量的情况下完成授权工作。

衡量观察周期内完成的任务，而不只是同时打开的上下文数量。并发继续上升时，任务可能因争用计算、内存带宽、网络或上游服务而变慢。合适的运行点是能够稳定满足服务目标的位置，不是让最多上下文保持打开的位置。

把失败清理纳入测试。在受控阶段取消任务，触发正常超时路径，并确认页面、上下文、存储句柄和调度租约都得到释放。只能处理成功路径的服务，会在真实事故中逐渐丢失容量。

测试持续时间要足以暴露累积问题。每次任务后能够回落的内存，与整场运行持续增加的内存含义不同。关闭时间逐渐增长也可能说明待处理工作过多。提升上限之前先调查这些趋势。

建立安全运行上限

以受控步幅增加负载。每一步保持到出现稳定模式，再与上一步比较完成量、延迟、错误和资源余量。当服务目标开始恶化，或者恢复余量过小时停止。批准的运行上限应低于这个位置。

为实际波动保留容量。生产页面会变化，网络请求会突发，媒体大小不同，主机上也可能有邻近服务。把基准中最高的一次成功结果直接当作生产上限，不会留下处理这些变化的空间。还应设定紧急阈值，在主机失去响应前停止接收任务。

记录上限覆盖的环境，包括浏览器版本、部署镜像、主机类别、代表性任务版本、观察时段、网络类别和审批日期。只记录一个并发数字，环境变化后就无法解释。

浏览器组和主机可以分别设限。浏览器组只能接收其测量负载允许的上下文。主机只能接收符合资源和隔离策略的浏览器组。任一上限达到时都应产生背压。

浏览器、操作系统、图形驱动、扩展、页面设计、媒体行为、存储、网络策略或主机规格有实质变化后，都要复查上限。短期重新验证比在事故中发现基线失效更可靠。

在接收阶段实施背压

无限队列只是把过载隐藏起来。应限制队列最大等待时间和已接受任务总量。如果服务无法在约定窗口内开始任务，应拒绝或延后请求，让调用方得到明确容量结果，而不是长期等待。

每个已接收任务应获得租约。租约把队列项与浏览器组、上下文分配、负责人和截止时间关联。只有清理完成后才能释放。工作节点异常消失时，租约到期可以让调度器通过受控流程回收分配。

接收策略要考虑任务类别。高成本任务可以使用独立资源池或权重。轻量任务不应被持续的大任务永久阻塞，高成本任务也不应为了塞进空位而被拆成产品不支持的半会话。

逐步创建上下文，不要同时启动全部已接收任务。初始化可能造成短时资源峰值，即使稳定负载能够运行。调度器可以分批启动，观察健康信号，并在启动延迟或内存压力上升时暂停接收。

重试与新任务遵循相同限制。立即重复会在上游故障或浏览器问题中放大负载。设置有限次数、等待策略和最终失败状态。授权会话必须连续时保留原身份分配，只有策略要求新会话时才创建新的分配。

保持生命周期责任清晰

每个浏览器组从启动到停止应由一个服务负责。它创建符合批准版本和策略的浏览器，接收上下文，跟踪租约，关闭完成的工作，为维护排空组，并最终停止浏览器。责任分散容易让上下文在调度器认为已经关闭后继续存在。

定义等待、启动、活动、关闭和已关闭等状态。状态转换应允许安全重复，避免重试关闭产生新的问题。超过关闭期限的上下文进入协调流程，并停止接收新任务。

通过支持的应用路径关闭页面和上下文，并等待完成后再释放容量。如果关闭在测量期限内无法完成，根据策略排空并替换整个浏览器组。不要继续向资源所有权不明确的组接收任务。

部署更新前先排空。停止接收，让活动任务在期限内完成，按取消策略关闭剩余上下文，并确认租约释放。完成后再更新或替换浏览器组。这样可以避免一个运维单元中混入不同版本。

浏览器组的最长生命周期应依据稳定性测量和维护需要确定。时间本身不应中断有效会话。应在会话边界排空，并按照保留策略处理持久存储。目的在于可预测维护，而不是任意改变身份。

保护配置与存储隔离

调度器只能分配已获准用于当前任务、浏览器版本和区域策略的配置文件。所需项目忙碌或不可用时，不要用无关项目代替。返回明确分配失败，由调用方或负责人决定是否存在其他可用的已批准身份。

持久存储始终属于同一身份记录。临时存储在会话后按策略删除。不要把一个存储位置挂载给两个活动上下文，也不要把旧存储接到新的配置分配上。即使上下文本身分开，存储错误仍可能跨越隐私边界。

网络路线采用相同的所有权模型。工作开始前绑定批准路线。路线失败后的重试仍需留在允许的网络策略内。会改变预期区域身份的路线调整，应通过新会话分配完成。

凭据应保存在配置文件和调度日志之外。工作节点只获得当前任务所需的最小秘密访问权限。容量面板需要资源与生命周期信息，不需要配置内容、账号标识或页面数据。

监控服务健康

面板应围绕用户可见工作和恢复能力构建。关注队列等待时间、接收任务数、活动任务数、完成量、按运维类别统计的失败、重试、取消时间、关闭时间、浏览器组替换、内存余量、CPU 压力和主机可用性。

尽量针对趋势告警。关闭时间、排队时间或残留内存持续上升，比一次短峰值更有参考价值。告警运行手册应说明何时暂停接收、排空浏览器组、移除主机或回退版本。

区分应用失败和容量失败。页面验收可能在主机资源充足时失败。容量压力则可能同时影响多个本来正常的任务。明确分类能够避免通过提高上限解决应用问题，或通过修改页面逻辑解决主机压力。

日志使用稳定的任务、上下文、浏览器组和主机引用，不包含配置内容、凭据或页面负载。确实需要深入证据时，在受保护诊断中短期收集，并让事故记录引用该证据。

定期比较调度租约和活动资源。发现不一致时，通过受支持关闭路径进行协调。这样可以在资源泄漏累积之前找回责任边界。

从过载中恢复

持续过载时，第一步是停止接收新任务。继续创建工作会增加清理时间，并导致健康会话失败。保留仍在服务期限内的活动任务，其他任务按策略取消。

压力集中在某个浏览器组时，先排空该组。如果主机健康继续下降，将主机从调度中移除，由监督服务按策略替换其浏览器组。恢复动作应有明确界限，确保人员和自动化依据相同信号作出一致决定。

恢复后不要立即回到之前上限。先从较低接收量开始，确认清理已经完成，并观察队列和主机趋势。如果事件发生在版本或工作负载变化之后，应重新执行代表性基准，再恢复正常容量。

保留足以说明事件的非敏感证据。时间线、主机指标、队列状态、生命周期事件、版本和任务类别通常足以分析容量问题。只有确有必要时才收集敏感跟踪，并按证据策略处理。

版本发布与回退

把容量纳入版本验收。在候选浏览器和部署镜像上执行代表性任务，对比完成率、延迟分布、资源余量、创建时间和清理时间。出现实质变化时，在推广前调查原因。

先推广到有限部署组。观察期内保留上一版已批准镜像，并确保调度器能同时识别两个组。需要回退时，排空候选组并恢复完整的旧组合。不要在活动上下文下直接替换浏览器文件。

容量变更也需要审批。记录测量证据、审查人、新上限、受影响任务类别和回退阈值。没有工作负载证据的提升，可能把小范围变化扩大成主机级事故。

实际检查清单

进入生产前，确认以下项目：

• 每个任务类别都有代表性任务和明确完成条件。
• 隔离策略明确要求上下文、浏览器实例或独立主机。
• 容量在目标版本、镜像和主机类别上完成测量。
• 批准上限保留恢复余量。
• 接收量、队列时间、重试和创建速度均有限制。
• 每个上下文都有配置文件、存储、路线、负责人和生命周期记录。
• 清理完成后才把容量交回调度器。
• 持久存储不会跨越身份分配。
• 面板不记录凭据、配置内容和私有页面数据。
• 部署组可以排空和回退，不影响无关任务。

运行期间定期检查吞吐、排队、清理趋势、组替换频率和主机余量。数值偏离基线时，先降低接收量并调查，再考虑增加容量。

选择部署模型

当任务需要身份和存储隔离，并且安全策略允许共享浏览器资源时，Per-Context 是合适选择。需要进程级安全、资源、扩展或故障边界时，使用独立浏览器实例。边界需要覆盖操作系统或网络命名空间时，使用专用工作节点。

生产服务可以根据任务组合多种模型。轻量授权测试进入 Per-Context 组，敏感应用会话进入独立实例，高保障任务进入专用节点。调度策略应明确记录每项选择。

Per-Context Fingerprint 适用于对应企业套餐。支持的设置和权限范围以 Per-Context 文档为准。性能指南介绍主机测量，配置文件管理介绍分配责任。选择生产部署方式时可查看套餐。