学校集中普查、企业统一施测时，登录、答题、交卷和报告生成可能在短时间内同时升高。可用的按需扩容方案需要先找出真正拥堵的环节，再选择扩容单元；只增加应用实例，数据库、队列或存储仍可能成为新的瓶颈。
准备扩容前，应先建立容量基线。用接近真实业务比例的压测记录每秒请求数、并发人数、CPU与内存、请求排队时间、响应时间、错误率，以及交卷后等待报告生成的时长。基线要回答一个具体问题：当前配置在什么负载下开始无法满足服务目标。
先看负载怎样传过整条链路
CPU升高只能说明计算资源趋紧。CPU平稳而请求队列持续增长，可能是连接池、下游接口或数据库限制；接口响应正常而报告生成延迟增加，问题更可能位于任务队列和后台消费者。监控应同时覆盖流量、延迟、错误和资源饱和度，并把成功请求与失败请求的耗时分开观察。
多租户场景还要按租户拆分请求量、并发数、队列积压和报告延迟。全站平均值可能掩盖一个大客户集中发放任务造成的“噪声租户”效应。某个租户升高负载时，其他租户的答题和报告时间是否变化，是后续隔离验收的重要依据。
扩容单元要按服务状态拆开
登录、答题接口和结果查询等无状态服务，适合通过增加副本分担流量。以 Kubernetes HPA 为例，副本数可以根据CPU、内存、自定义指标或外部指标调整。扩容后的实例只有在依赖连接、配置和缓存准备完成，并通过就绪检查后，才能开始接收请求。
数据库、存储和任务队列需要分别设计。数据库要检查连接上限、读写比例、锁等待、慢查询和磁盘吞吐，再决定提升规格、增加只读能力或拆分负载。存储扩容解决的是容量问题，无法直接补足数据库计算和I/O性能。报告队列更适合依据待处理任务数、最老任务等待时间和消费速度调整消费者，同时限制并发，避免新增消费者反向压垮数据库。
伸缩阈值要早于服务恶化
扩容阈值应从容量基线和服务目标倒推。CPU、请求队列、响应时间或报告延迟连续超过阈值一段时间后扩容；缩容使用更低阈值和更长稳定窗口，减少实例反复增减。关键接口已经大量超时后才触发扩容，新增容量通常赶不上高峰。
自动伸缩存在采集周期、调度、镜像拉取、应用启动和缓存预热等延迟。高峰可预测时，可提前保留最小副本或安排预扩容；高峰突发时，要用启动探针和就绪探针区分“正在启动”与“已经可接流量”，并保留限流、排队和降级措施吸收这段空档。
每次伸缩都应留下时间、触发指标、目标副本、实际生效时间和失败原因。监控数据要能还原扩容前后的请求量、尾部响应时间、错误率、队列积压和报告延迟。故障记录还应说明冷启动过慢、指标缺失、调度失败或数据库达到上限等具体原因，便于下一次调整阈值。
最后验收性能隔离和数据边界
压测至少包含三组：单租户逐步加压、多租户同时升高，以及一个租户突发流量而其他租户保持正常。验收要确认扩容确实缩短排队和报告等待时间，同时观察普通租户的响应时间与错误率。测试结束后再触发缩容，检查任务是否丢失、重复执行或中断。
性能隔离关注资源是否公平，可通过租户级并发限制、资源配额、独立队列或资源池降低相互影响。数据隔离关注身份、权限和数据边界，需要验证租户标识是否贯穿鉴权、查询、缓存、对象存储和异步任务，并执行跨租户访问的反向测试。性能稳定无法代替数据隔离验证。
采购或验收橙星云这类心理测评系统时，可以要求供应方展示容量基线、触发阈值、压测曲线、伸缩事件和隔离测试结果，无需把某一种云服务或编排工具当成唯一答案。方案能够明确识别瓶颈、选择正确扩容单元，并用可复现记录证明租户间性能与数据边界，才具备真实高峰下的可用性。