4. 技术选型与基础设施架构
互联网医院平台同时承载挂号、问诊、处方、支付、药品配送、医保结算等多条业务链，既有面向 C 端的高并发瞬时流量（如早间放号、流感季问诊高峰），又有面向监管与医保的强一致、可追溯要求。因此技术选型的核心不是“选最流行的框架”，而是让服务框架、容器编排与基础设施组件形成互补：服务框架解决“服务之间怎么调用”，Kubernetes 解决“服务实例怎么部署与伸缩”，基础设施组件解决“调用过程中如何被发现、被保护、被观测”。
一、Spring Cloud、Dubbo、Kubernetes 的定位对比
三者并非同一层面的替代关系，混为一谈是选型中最常见的误区。Spring Cloud 是一套面向应用层的微服务开发与治理方案集合，覆盖服务发现、配置、网关、熔断、链路追踪等；Dubbo 是高性能 RPC 框架，核心在于基于接口的远程调用、负载均衡与集群容错，适合内部服务间高频、低延迟的调用；Kubernetes 是容器编排平台，负责调度、扩缩容、自愈、服务暴露与配置挂载，属于运行底座。
| 维度 | Spring Cloud | Dubbo | Kubernetes |
|---|---|---|---|
| 核心定位 | 应用层微服务治理全家桶 | 高性能 RPC 调用框架 | 容器编排与运行底座 |
| 通信方式 | HTTP/REST 为主 | TCP 长连接、二进制协议 | 不直接定义，提供 Service/Ingress |
| 服务发现 | Nacos/Eureka/Consul | 注册中心（Nacos/ZooKeeper） | Service + Endpoints/CoreDNS |
| 典型优势 | 生态完整、上手快、与 Spring 无缝 | 吞吐高、延迟低、接口契约清晰 | 弹性伸缩、自愈、灰度发布 |
| 适用场景 | 对外 API、业务编排、快速迭代 | 问诊会话、处方校验等内部高频调用 | 所有服务的部署与弹性承载 |
实践中常见的组合是：Kubernetes 作为统一运行底座，Dubbo 承担内部核心服务的高性能 RPC，Spring Cloud Gateway 承担南北向流量入口，Nacos 同时作为注册中心与配置中心。这样既避免重复建设两套注册体系，也让对外 HTTP 与对内 RPC 各取所长。若团队规模较小、服务数量有限，也可统一采用 Spring Cloud + Kubernetes，牺牲部分性能换取运维简单。
二、注册中心与配置中心
注册中心解决“服务实例在哪里”，配置中心解决“服务运行时参数是什么”。互联网医院平台推荐使用 Nacos，它同时提供两者能力，减少组件数量。注册中心的关键设计点包括：
- 健康检查与摘除：采用心跳 + 主动探测双机制，实例连续 3 次心跳超时（示例：间隔 5s，超时 15s）即标记不健康并从可用列表摘除，避免流量打到已宕机实例。
- 命名空间隔离：按环境（dev/test/prod）和业务域（问诊、处方、支付）划分 namespace 与 group，防止测试流量误入生产。
- 保护阈值：当健康实例比例低于阈值（示例 60%）时，注册中心不再摘除实例，防止雪崩式误摘。
配置中心需支持动态刷新与灰度发布。例如将“问诊超时自动结束时间”从 30 分钟调整为 15 分钟，可通过 Nacos 配置项 consult.auto-close.minutes 推送，配合 @RefreshScope 实现不重启生效。涉及医保结算费率等敏感配置，应加密存储并保留变更审计记录。
三、API 网关、服务容错与分布式追踪
API 网关是南北向流量的唯一入口，承担路由、鉴权、限流、灰度、日志埋点。互联网医院场景下，网关需特别处理：患者端与医生端路由隔离、处方类接口强制鉴权与签名校验、放号接口按患者 ID 维度限流。示例限流规则：/api/registration/grab 单用户 5 次/分钟，全局 2000 QPS，超出返回 429 并提示“当前挂号人数较多，请稍后重试”。
服务容错采用“熔断 + 降级 + 隔离”组合。以处方审核服务为例，当调用医保审核接口失败率超过 50%（统计窗口 10s，最小请求数 20）时触发熔断，后续请求直接走降级逻辑：返回“审核中，请稍后查看”，并异步重试，避免线程被长时间占用。线程池隔离可防止某个下游拖垮整个问诊链路。
分布式追踪用于定位跨服务调用瓶颈。统一使用 TraceId 贯穿网关、问诊、处方、支付各环节，采样率生产环境建议 10%，排障时可临时调至 100%。关键指标包括 P99 延迟、错误率、慢调用 TOP N。
四、高可用与弹性伸缩
高可用需从“无状态化、多副本、跨可用区、优雅停机”四方面落地。业务服务尽量设计为无状态，会话数据外置到 Redis；每个服务至少 2 副本并分散到不同节点；Kubernetes 配置 readinessProbe 与 livenessProbe，就绪探针失败即从 Service 摘除，存活探针失败则重启容器。发布时使用滚动更新，maxUnavailable: 0、maxSurge: 1，保证升级期间容量不下降。
弹性伸缩以 HPA 为核心。示例配置：问诊服务目标 CPU 利用率 70%，最小副本 2，最大 20；同时结合自定义指标（如每秒问诊请求数）做多指标伸缩。放号场景可提前通过定时任务在放号前 10 分钟将副本预扩至 10，避免冷启动延迟。缩容需设置稳定窗口（如 300s），防止流量抖动导致频繁扩缩。
最后需要强调的是，基础设施组件的价值只有在“可观测、可回滚、可演练”时才能真正体现。建议对熔断降级、注册中心摘除、HPA 扩容三条链路分别做故障演练，记录触发条件、恢复时间与业务影响，形成平台自身的稳定性基线。