1. 医疗平台容量规划与性能工程导论

医疗平台与一般互联网系统最大的区别，在于它同时承载“业务连续性”和“生命安全”两类责任。挂号、缴费短时不可用，患者会抱怨；但医嘱、检验危急值、影像调阅、监护数据一旦延迟或丢失，影响的是临床决策本身。因此，容量规划与性能工程在医疗行业不是单纯的“扩容省钱”问题，而是要在可预期的资源边界内，保证关键业务在高峰与突发场景下仍然可用、可查、可追溯。

本课程的目标可以概括为三件事：第一，能读懂一个医疗平台的典型架构，知道请求从终端到数据库经过了哪些环节；第二，能用量化方法判断系统“现在够不够、什么时候不够、加多少才够”；第三，能把容量结论落到具体的部署、参数和验证动作上。学完之后，你应当能够独立完成一次小型容量评估，并给出有依据的扩容或优化建议，而不是凭感觉说“加两台服务器”。

医疗平台的典型架构

一个区域性医疗平台通常由若干相对独立又互相依赖的子系统构成。面向患者侧的有预约挂号、在线缴费、报告查询、互联网医院；面向医护人员侧的有门诊医生站、住院医生站、护士站、电子病历（EMR）、计算机化医嘱录入（CPOE）；面向医技侧的有 LIS（检验）、PACS（影像）、RIS；再往下是集成引擎、主数据、统一认证，以及最底层的数据库与存储。它们之间通过 HL7 v2、FHIR、DICOM、Web Service 或消息队列交换数据。

从性能视角看，这条链路有一个鲜明特点：读多写少但写极关键。报告查询、影像调阅是典型的读放大场景，一次调阅可能拉取几十到几百 MB 的 DICOM 序列；而医嘱下达、检验结果回写虽然 QPS 不高，却要求强一致和低延迟。下图给出了一条典型门诊请求的端到端路径，以及各环节最容易被忽视的容量瓶颈。

容量与性能的核心概念

容量（Capacity）回答的是“能装多少”，性能（Performance）回答的是“做得多快”，两者通过负载耦合在一起。容量规划常用的三个量是：并发用户数、请求速率（QPS/TPS）和资源占用率。它们之间不是简单线性关系——当 CPU 利用率超过约 70% 后，排队延迟会快速上升，这就是为什么“还剩 30% 余量”往往已经接近危险区。

性能工程则关注响应时间的分布。医疗场景中，平均值几乎没有意义：如果平均响应 200 ms，但 P99 达到 8 s，意味着每 100 次操作就有 1 次让医生等待 8 秒，这在门诊高峰期足以造成排队。因此我们通常用 P95、P99 作为验收口径，并区分“服务端处理时间”和“端到端时间”，前者用于定位瓶颈，后者用于判断用户感受。

还有一个容易被忽略的概念是工作负载模型。同样是 1000 QPS，均匀到达和集中在早高峰 8:00–9:00 到达，对系统的压力完全不同。容量规划必须基于真实的时间分布，而不是日均值。医疗平台的典型峰值通常出现在上午门诊开诊后 30–60 分钟，以及下午报告集中发布时段。

学习路径与实战项目

本课程按“看懂架构 → 量化容量 → 定位瓶颈 → 落地优化 → 验证复盘”的顺序推进。前半部分建立概念与测量方法，包括负载建模、压测工具选型、监控指标采集；后半部分进入具体场景，如数据库连接池调优、PACS 影像调阅带宽估算、消息队列积压处理、以及高可用与容灾下的容量冗余设计。

课程配套一个贯穿始终的实战项目：为一家日均门诊量 8000 人次、峰值小时挂号 1200 次的二级医院，完成其互联网医院平台的容量评估。你需要产出：一份负载模型（含峰值系数与到达分布假设）、一张资源估算表（应用节点数、数据库规格、存储带宽）、一次压测方案（场景、脚本要点、验收指标），以及一份扩容建议。所有参数均以教学假设给出，实际项目中应以监控数据替换。

下面给出一个可直接参考的容量估算表模板，字段按医疗平台实际需要设置，你可以在实战项目中直接填写。

表中“单请求资源消耗”是教学假设值，用于演示计算方法：设计 QPS 乘以单请求消耗，得到该场景所需资源，再按资源类型汇总并留出冗余。影像调阅单独按带宽计算，因为它的瓶颈通常不在 CPU 而在存储吞吐。实际使用时，这些系数应通过压测或生产监控反推。

学习本课程不需要你成为 DBA 或运维专家，但需要你愿意看监控、算数字、做对比。接下来的章节会从架构拆解开始，逐步把上面这张表填满、填准，并最终形成一份能提交给技术委员会的容量评估报告。