📚 课程目录第1章医疗云原生部署平台工程导论

1. 医疗云原生部署平台工程导论

医疗行业的软件交付，长期处在一种“高约束、低容错”的环境中。一套面向门诊或住院的业务系统，往往同时受到三类力量牵引：临床业务要求 7×24 小时连续可用，监管与合规要求数据可追溯、可审计、可隔离，而医院信息科的人力又通常有限。传统“一台服务器装一套系统、上线靠人工、扩容靠加机器”的部署方式，在这种约束下会迅速暴露问题：环境不一致导致“测试通过、上线失败”，版本回退依赖手工备份，资源利用率低却不敢轻易调整。云原生与平台工程，正是为回应这类矛盾而出现的工程方法。

一、医疗行业部署面临的真实挑战

把挑战具体化，才能理解后面每个技术选择的原因。医疗部署的难点通常集中在以下几个方面。

环境异构且难以复制：开发、测试、院内生产往往使用不同操作系统版本、不同中间件参数、不同数据库补丁级别。一个典型的排障场景是：测试环境使用 MySQL 8.0.32，生产环境为 8.0.28，某个 SQL 在测试环境正常，上线后因优化器行为差异导致慢查询，门诊高峰期响应时间从 200ms 恶化到 3s 以上。
可用性要求高、维护窗口极窄：门诊系统通常只能在夜间极短时间窗口内停机，住院与急诊系统几乎不允许中断。这意味着升级必须支持灰度与快速回滚，而不是“停服—替换—启动”。
数据敏感、隔离要求强：患者身份信息、诊疗记录属于高敏感数据，系统之间需要网络隔离、权限最小化，跨环境的数据流动必须受控。
合规与审计：谁在什么时间发布了哪个版本、变更了什么配置，都需要可追溯。人工操作难以形成完整证据链。
多院区与多版本并存：集团医院中，不同院区可能运行不同版本，配置项（如接口地址、字典编码）存在差异，需要“同一制品、不同配置”的部署能力。

这些挑战的共同点是：它们不是某个功能代码的问题，而是交付方式与运行方式的问题。云原生解决的正是这一层。

二、云原生核心概念：从“机器”到“声明式期望状态”

云原生不是某一款软件，而是一组围绕容器、编排、声明式管理与可观测性的工程实践。理解它，关键是抓住四个概念及其相互关系。

容器与镜像。容器把应用及其依赖（运行时、库、配置骨架）打包成镜像，使“在我机器上能跑”变成“在任何符合条件的环境都能跑”。镜像一旦构建完成就不可变，这为可追溯提供了基础：一个镜像摘要（digest）唯一对应一份制品。

编排与期望状态。Kubernetes 这类编排系统采用声明式模型：你提交“期望状态”（例如某服务需要 3 个副本、镜像为 xxx、暴露 8080 端口），控制器持续对比实际状态并纠正偏差。副本意外退出会被自动重建，节点故障会被调度到其他节点。这与“登录服务器手动重启进程”是根本不同的运维范式。

服务发现与流量入口。Pod 的 IP 会随重建变化，因此服务之间通过 Service 这样的稳定抽象互相访问；外部流量通过 Ingress 或网关进入，并在此处实现灰度、限流、TLS 终止等能力。

配置与密钥分离。把数据库地址、接口密钥等从镜像中剥离，通过 ConfigMap 与 Secret 注入。这样同一镜像可以在测试、生产、不同院区复用，只替换配置，避免“为每个环境重新构建一次”。

一个便于记忆的判断：如果一次发布需要人工登录服务器改文件、重启进程，那它还不是云原生交付；如果发布是提交一份声明、由系统收敛到期望状态，并具备自动重建与回滚能力，才进入云原生范畴。

三、平台工程的定义：把云原生能力变成“可自助使用的产品”

只引入 Kubernetes 并不等于解决问题。若每个业务团队都要自己写 YAML、配流水线、管证书、接监控，那么复杂度只是从运维转移到了开发，交付效率未必提升。平台工程（Platform Engineering）的核心主张是：由平台团队构建并运营一个内部平台，把底层云原生能力封装成标准化、可自助、带约束的产品化能力，供业务团队直接使用。

它有三个关键词。其一是自助：业务团队通过模板或门户即可创建服务、申请环境、发起发布，无需逐项对接底层。其二是约束下的自由：平台通过“黄金路径”规定推荐做法，例如必须声明健康检查、必须设置资源上限、必须接入日志采集，从而在提升效率的同时守住合规与稳定性底线。其三是平台即产品：平台自身有版本、有文档、有服务级别目标，也需要被度量与迭代，而不是一次性交付的脚本集合。

对医疗场景而言，平台工程还承担一项特殊职责：把合规要求“内建”为默认行为。例如默认启用审计日志、默认禁止容器以 root 运行、默认对敏感配置加密存储。合规不再是上线前临时补的材料，而是平台默认提供的属性。

四、课程整体框架与学习路径

本课程围绕“从能跑到可控、可审计、可规模化”的主线展开，整体可分为四个层次，下图给出各层之间的支撑关系与关键对象。

对应的学习路径建议按“先建立运行认知，再建立交付认知，最后建立平台认知”推进。第一阶段理解容器与 Kubernetes 的基本对象（Pod、Deployment、Service、ConfigMap），能在本地或测试集群把一个服务跑起来并观察其状态。第二阶段打通流水线：从代码提交到镜像构建、到部署到测试环境、再到灰度发布与回滚，形成完整闭环。第三阶段进入平台化：设计服务模板、环境模型、配置与密钥管理策略、审计与度量体系，把前两阶段的能力沉淀为可复用的平台产品。第四阶段面向医疗特有场景，处理多院区部署、数据隔离、合规审计与容量规划。

五、一个可对照的起步示例

为了让抽象概念落地，给出一个最小但完整的示例。假设要把一个门诊排班服务部署到测试集群，关键输入与操作如下（参数为教学示例，非实测结果）。

# deployment.yaml（节选，教学示例）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: clinic-schedule
spec:
  replicas: 2
  selector:
    matchLabels: { app: clinic-schedule }
  template:
    metadata:
      labels: { app: clinic-schedule }
    spec:
      containers:
      - name: app
        image: registry.example.com/clinic-schedule:1.4.0
        ports: [ { containerPort: 8080 } ]
        envFrom:
        - configMapRef: { name: clinic-schedule-config }
        - secretRef:    { name: clinic-schedule-secret }
        resources:
          requests: { cpu: "200m", memory: "256Mi" }
          limits:   { cpu: "500m", memory: "512Mi" }
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }
          initialDelaySeconds: 5

提交后应观察三件事：一是 kubectl get pods 中两个副本是否都进入 Running 且 Ready，若 Ready 长期为 0/1，通常说明就绪探针路径或端口配置有误；二是通过 Service 访问是否返回预期响应；三是修改 ConfigMap 中的某个非敏感参数后重新发布，确认配置生效而镜像摘要未变——这正是“同制品、多环境”的验证点。若把 replicas 改为 4，应看到副本数自动收敛到 4，这就是声明式期望状态在起作用。

医疗生产环境不要直接照搬示例中的副本数与资源上限。资源 requests/limits 应基于实际压测与业务峰值确定，配置过小会导致门诊高峰被限流或 OOM 重启，过大则浪费集群容量。

从这一章开始，后续内容都会围绕一个判断标准展开：这项能力是否让医疗系统的交付更可重复、更可回滚、更可审计，同时不牺牲临床业务的连续性。带着这个标准去学习容器、编排、流水线与平台设计，技术选择就不再是零散的知识点，而是一条有方向的工程路径。