4. 医疗App总体架构风格选型

医疗App的架构选型，本质上不是“哪种技术更先进”的问题，而是“哪种架构风格与当前业务复杂度、合规约束和团队规模最匹配”的问题。医疗场景有三个绕不开的硬约束：数据强一致与可追溯（处方、医嘱、计费不能错）、隐私合规（等保、个人信息保护、数据分级）、业务链路长且异构（挂号、问诊、处方、支付、药品配送、随访、医保结算）。这三点决定了我们不能照搬互联网电商的架构演进路径。

四种架构风格在医疗场景的适用性

单体（Monolith）并非落后选项。对于日活几万以内、业务模块耦合度高（如挂号—缴费—就诊记录天然共享同一套患者主索引）的互联网医院早期产品，单体配合模块化分包（按 domain 划分 package，禁止跨模块直接访问对方数据表）是成本最低、事务最简单、部署最可控的选择。它的代价是：一次发版全量重启、单点故障影响全站、团队超过 15～20 人后代码冲突和回归成本急剧上升。

微服务解决的是“独立部署与独立扩容”，但它把本地事务变成了分布式事务。医疗里最典型的坑是“开方成功但库存扣减失败”。因此微服务在医疗场景的落地前提是：能接受最终一致的核心链路（如随访提醒、健康档案同步）才拆，强一致链路（处方、计费）要么保留在同一服务内，要么用 TCC/Saga 显式补偿。服务粒度建议按业务能力而非技术分层划分，例如：患者服务、预约服务、问诊服务、处方服务、支付服务、药品服务、消息服务。

事件驱动（Event-Driven）是医疗场景中被低估但价值极高的一层。它不一定要独立成“架构风格”，更常作为微服务之间的解耦手段。典型事件如 AppointmentCreated、PrescriptionSigned、PaymentSucceeded、OrderShipped。事件驱动的核心收益是：下游（短信、推送、随访计划、数据仓库、风控）可以按需订阅，上游不必知道谁在消费。医疗场景尤其需要它来做审计留痕——每个事件带时间戳、操作者、患者ID、幂等键，天然形成可追溯链路。代价是调试变难、事件顺序与重复消费必须处理（幂等表 + 版本号）。

服务网格（Service Mesh）解决的是“服务间通信的治理”，而不是业务拆分。它把熔断、重试、超时、mTLS 加密、流量镜像、灰度发布下沉到 Sidecar（如 Istio + Envoy）。医疗App对它的真实需求集中在两点：传输加密与身份认证（满足等保对东西向流量的要求）和灰度发布（新版本问诊流程先放 5% 流量观察）。但服务网格会带来约 1～3ms 的额外延迟和显著的运维复杂度，团队没有专职 SRE 时，建议先用 API 网关 + 客户端负载均衡替代，等微服务数量超过 20 个再引入。

基于业务复杂度与团队规模的技术选型决策

把上面的判断落到可执行的决策上，建议按三个维度打分：业务复杂度（模块数量、链路长度、变更频率）、团队规模（并行开发人数、是否有专职运维/SRE）、合规等级（是否涉及处方、医保、三级等保）。

一个可参考的落地路径

假设一个互联网医院App，当前团队 12 人，已有挂号、问诊、处方、支付四个模块，日活约 3 万。合理的做法不是立刻上微服务，而是：

1. 先做模块化单体：按 patient、appointment、consultation、prescription、payment 分包，模块间只通过接口调用，禁止直接访问对方 Mapper。
2. 把异步链路抽出来：短信、推送、随访计划、数据同步改为订阅领域事件，用一张 event_outbox 表保证“业务写入 + 事件写入”在同一本地事务内完成，再由投递器发到消息队列。
3. 当处方与支付需要独立扩容时，再把这两个模块拆成独立服务，其余保持单体，形成“单体 + 少量微服务”的混合形态。
4. 服务数超过 20 个、且需要灰度发布时，再评估引入 Istio，先只对问诊链路开启 mTLS 和 5% 流量镜像。

总结来说：单体是起点，微服务是规模化的手段，事件驱动是解耦与审计的骨架，服务网格是通信治理的补丁。四者不是互斥选项，而是可以按阶段叠加的组合。判断标准始终是：当前业务复杂度是否需要独立部署、当前团队是否有能力承担分布式带来的运维与一致性成本。