科室库集群化改造方案 需求设计 记录 ASC-USC

lake 2020-6-30 2015

构架设计说明

现状

目前科室库由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包打包以及系统发布方案

最后于 2020-10-21 被lake编辑 ,原因:
最新回复 (0)
全部楼主
返回