构架设计说明

现状

目前科室库由U-PS,U-SC,U-HQ3套应用系统组成，其中U-SC和U-HQ用于医院端的业务管理，其业务架构如下： 其中U-SC和U-HQ均可以由一个应用系统挂载多个业务数据库（物理隔离）。可以认为实现了数据库层面的节点化。

节点化方案

将U-SC和U-HQ合并称为科室库院内系统，则目前的构架体系可以视为U-PS与院内系统是一对一的单应用系统。只不过是院内系统在数据库层面实现了多医院数据解耦。 现将架构体系进一步演进，通过节点化设计建立科室库应用系统节点，即一个系统间通过节点进行进行关联。实现系统的业务解耦。

节点架构说明

基于业务解耦的思路，应用系统层面

• 一个物理部署的应用定义为一个节点，并分配一个全局唯一的节点值，即app_node_id
• 节点间通信将通过mq基于节点值+主题的方式实现

部署层面

• 应用散列部署，各个应用间无直接依赖关系
• 应用间依据业务通过mq进行数据关联，构成逻辑上的依赖关系

需要实现实现一个业务节点间能够互相关联的应用架构模式。这种架构管理模式就是系统节点化管理，其中： 消息监听设置如下：

• UPS系统需要监听所有业务关联的USC，UHQ以及新增加的UCN系统发送的消息
• USC系统需要监听UPS，UCN以及UHQ系统发送的信息，其中假设一个USC系统只有一个UHQ进行对应
• UCN系统暂时没有监听，只有发送。
• UHQ系统需要监听UPS,UCN以及对应的医院的USC系统发送的消息 如图：

  节点实现说明

从架构体系来看，需要指定一个节点管理其他的节点，具有管理功能的称之为医院管理中心节点(UCN)，被管理的称之为业务节点.其中：

医院管理节点：

• 本身是可选节点，可不做部署
• 其只要功能是在SAAS平台上负责创建各个医院以及集团，并维护医院和集团间的关系。
• 目前的实现中，需要改变：维护数据库创建过程，统一组织ID

业务节点UPS:

• 其关联功能是接收并处理USC，UHQ，UCN相关的业务
• 关键事项：供应商信息共享问题，附件共享问题

业务节点USC:

• 作为业务的主要节点，存在多种部署位置的可能，需要对其发送的目的节点以及监听节点做管理。
• 关键事项：webservice以及restful接口方式的处理，以及可能是HIS接口

业务节点UHQ:

• 常规化改造即可
• 关键事项：实时调用usc系统的处理

问题以及待做事项

上述架构方案是通过节点间业务数据分发的方式实现了数据共享，会产生mq监听量的增加，对服务器负载和数据库存储都会产生影响，并不是一种最优方案，采用这种方案的原因是：

• 当前代码改动量最少，变动的部分基本上属于框架层面，业务代码没有任务变化，因此对现有的代码侵入性最小
• 考虑需要支持医院的内外解耦，节点只通过MQ进行信息交互，会减少医院网闸部分配置难度
• 代码迁移过程中只需要考虑应用相关数据交互即可。

未来优化方向：

• 灵活配置节点以及节点监听能力
• 突破系统的限制，实现定义化的数据共享
• jms接口发送和监听与现有业务代码解耦

节点化改造事项

1. UCN集团和医院创建流程调整，不再创建医院业务库

2. 节点管理：

   • 建立节点组织关系表，维护组织节点关系
   • 建立节点关联关系表，维护节点间的关联关系
   • 将对节点有关系的组织信息推送给对应节点

3. 应用节点化改造

   • 组件改造
   • 代码调整

4. 供应商授权以及同步问题 按照目前的方式，usc节点存储全部UPS已注册的供应商 授权时，查询页面只显示授权记录 输入供应商以及邮箱后，系统排查当前供应商是否已注册，并根据注册情况针对性进行提示 供应商信息存储在USC的主数据库中

5. rest方式梳理与改造

6. 文件同步与CDN环境配置

7. 节点主库同步方案

8. 业务节点WAR包打包以及系统发布方案