2. 医疗业务负载特征建模

容量规划的第一步不是买机器，而是把“业务怎么用系统”翻译成“系统承受什么样的负载”。医疗业务与电商、社交最大的区别在于：它的请求由人的生理节律、医院的排班制度和临床流程共同驱动，而不是由营销活动或用户兴趣驱动。因此，医疗负载具有强周期性、强时段集中性和强流程耦合性。本节按场景拆解请求模式、峰值规律与数据增长模型，为后续的容量计算提供输入。

一、五类核心场景的请求模式

门诊挂号是典型的“脉冲型”负载。它的请求量并不均匀：号源通常在放号时刻（如每日 7:00 或 8:00）集中释放，形成秒级尖峰；就诊当日 7:30–9:30 又出现一次现场取号、签到、缴费的次高峰。挂号请求本身很轻（一次查询加一次写号），但存在强一致性竞争——同一号源被多人同时抢，数据库行锁与乐观锁冲突会放大响应时间。建模时应关注“并发抢号数”而非“日均挂号量”。

住院医嘱是“长事务、低频次、高关联”负载。医生查房后集中开立医嘱，时间集中在 8:00–11:00 和 14:00–16:00。单条医嘱写入会触发药品库存校验、费用预扣、护理任务生成、检验申请联动等多个下游动作，属于典型的扇出型写放大。它的峰值不体现在 QPS 上，而体现在单请求的处理链路长度和数据库事务持有时长上。

检验检查分为“申请”和“报告回传”两个方向。申请由医嘱驱动，与住院/门诊高峰同步；报告回传则由检验科、影像科的批量上机节奏决定，常在上午 10:00–12:00、下午 15:00–17:00 出现批量写入。LIS 仪器接口常以 HL7 消息推送，单批可达数百至数千条，属于批量突发型负载。

影像调阅是“大带宽、长连接、读多写少”负载。PACS 影像单次调阅动辄几十到几百 MB，请求数不高但网络吞吐极高。门诊医生站、住院医生站、影像科诊断工作站会在早交班后集中调阅，形成带宽峰值。它的容量瓶颈通常不在应用服务器 CPU，而在存储 IOPS、PACS 网关并发连接数和院内网络带宽。

互联网问诊是“晚高峰、会话型、弹性大”负载。患者下班后 19:00–22:00 是咨询高峰，图文问诊表现为长轮询或 WebSocket 会话，视频问诊则叠加实时音视频流。它与院内业务高峰在时间上错开，但会与医院夜间批处理（如日结、报表）争夺数据库和网络资源。

二、峰值规律：三类叠加

把五个场景放到同一条时间轴上，可以看到医疗负载的峰值来自三类叠加。

第一类是制度性尖峰。放号时刻、日结时刻、报表生成时刻由制度规定，时间点固定、可预测，但瞬时强度极高。这类峰值适合用“定时扩容 + 限流排队”应对，例如放号前 5 分钟预启动应用实例，并对抢号请求做令牌桶限流。

第二类是流程性高峰。早交班后的查房开嘱、门诊开诊后的挂号缴费、检验上机后的报告回传，都跟随临床流程出现。它们持续时间较长（1–3 小时），是容量规划的主要依据。经验上，门诊挂号峰值 QPS 约为日均 QPS 的 8–15 倍，住院医嘱峰值约为日均的 5–8 倍，影像调阅峰值带宽约为日均的 6–10 倍。这些倍数属于示例性经验区间，实际应以本院历史监控数据拟合。

第三类是随机性突发。急诊批量伤员、突发公共卫生事件、体检团检集中到院，都会在短时间内把请求量推高数倍。这类峰值无法精确预测，只能通过弹性伸缩和降级预案兜底。

三、数据增长模型

医疗数据增长不是线性的，而是“结构化数据缓增、非结构化数据快增”。挂号、医嘱、费用等结构化记录年增长通常在 20%–40%；而影像、检验原始数据、互联网问诊的图文与音视频，年增长可达 50%–100% 甚至更高。影像数据尤其突出：一次 CT 检查约 200–500 MB，一次 MR 约 100–300 MB，一家日检查量 800 人次的医院，仅影像年新增就可能达到 60–120 TB。

因此数据增长模型应分三层建立：在线热数据（近 3–6 个月，需高性能存储）、近线温数据（6 个月至 2 年，可接受秒级调阅延迟）、离线冷数据（2 年以上，归档到低成本对象存储）。容量规划要分别给出三层的增长曲线和迁移策略，而不是只算一个总容量。

四、把特征转成建模输入

完成上述分析后，应形成一份可计算的负载模型，至少包含以下字段，供后续容量计算直接引用：

需要强调的是，表中的峰值倍数只是用于教学演示的示例区间，真实建模必须用本院 APM、网关日志和数据库慢查询日志做分位数统计，至少取 P95 与 P99，而不是平均值。只有把“业务节律”量化成“请求曲线”，容量规划才有可靠的起点。