4. 平台总体架构设计
医院物资与耗材管理平台连接的是临床科室、中心库房、二级库、供应商、财务与监管等多方角色，业务上同时存在“高频轻量”的扫码消耗与“低频重载”的采购结算。若采用单体架构，一次盘点高峰就可能拖慢全院领用。因此本平台总体架构采用微服务 + 分层的组合：纵向按职责分层收敛技术复杂度，横向按业务能力拆分服务实现独立伸缩与故障隔离。
一、分层架构：五层职责与依赖方向
平台自上而下划分为接入层、网关层、业务服务层、数据访问层与基础设施层，依赖方向严格单向向下，禁止跨层反向调用。
- 接入层：面向 PC 管理端、移动 PDA、供应商门户、院内 HIS/HRP 系统，统一通过 HTTPS 接入，PDA 支持离线缓存后补传。
- 网关层：承担路由、鉴权、限流、灰度与协议转换。所有外部请求必须携带 JWT，网关校验后透传科室编码与角色，业务服务不再重复解析身份。
- 业务服务层：按领域拆分为物资主数据、采购、库存、消耗计费、供应商协同、报表分析等服务。
- 数据访问层：封装分库分表、读写分离与缓存，业务代码不直接拼接 SQL。
- 基础设施层：注册配置中心、消息队列、对象存储、日志与链路追踪。
二、微服务模块划分与集成边界
模块划分遵循“高内聚、低耦合、数据私有”原则，每个服务独占其数据库 schema，跨服务只通过 API 或事件交互，不允许跨库联表。核心服务与边界如下：
| 服务 | 核心职责 | 数据归属 | 对外边界 |
|---|---|---|---|
| 物资主数据服务 | 耗材编码、分类、UDI、证照效期 | material_db | 提供编码查询 API，被采购/库存订阅 |
| 采购服务 | 请购、订单、到货、结算 | purchase_db | 向供应商门户开放订单接口 |
| 库存服务 | 入库、出库、调拨、盘点、批次 | stock_db | 发布库存变更事件 |
| 消耗计费服务 | 扫码消耗、科室成本归集 | consume_db | 向 HIS 回传计费明细 |
| 供应商协同服务 | 资质、对账、配送预约 | supplier_db | 仅经网关对外暴露 |
| 报表分析服务 | 消耗趋势、库存周转、效期预警 | 只读副本/数仓 | 只读，不写业务库 |
集成边界的关键约定：库存服务是“库存数量”的唯一权威来源，采购服务不得直接改写库存；消耗计费服务只消费库存扣减事件，不反向调用库存写接口。这样即使计费服务故障，扫码消耗仍可继续，事件在恢复后补消费。
三、高可用与可扩展性设计
高可用从“无单点、可降级、可恢复”三方面落地。网关与业务服务均部署至少 2 副本并跨可用区，注册中心集群化；数据库采用一主两从，主库故障由哨兵在 30 秒内切换。关键链路设置降级策略：当报表分析服务不可用时，管理端仅隐藏图表，不影响领用与入库。
可扩展性分两个维度。其一是水平扩展：库存服务无状态，可随 PDA 扫码并发增加副本；库存流水表按“库房编码 + 月份”分表，单表控制在千万级以内。其二是业务扩展：新增“高值耗材追溯”能力时，只需新增追溯服务并订阅既有库存事件，无需改动采购与计费代码。
四、架构关系总览
下图给出分层与微服务模块的对应关系，以及关键数据流方向：外部系统经网关进入业务服务，库存变更以事件方式广播给计费与分析服务。
落地时建议先固化三条纪律：服务只访问自己的库；跨服务写操作通过事件最终一致；任何新模块上线前必须明确其数据归属与对外接口契约。做到这三点，架构才真正具备可演进的基础。