[医疗信息化PPT]医院信息系统技术架构.pptx

新一代医院信息系统技术架构的挑战与对策;

目录

·一、技术架构相关概念与特性

·二、新一代HIS技术架构需求与挑战

·三、新一代HIS技术架构选型对策;;;

关于应用架构和技术架构

·有些文献里单独提到应用架构或者企业(级)应用架构时

是指应用内部架构，一定程度上类似于TOGAF的技术架构中对逻辑组件划分与关系的描述

·企业应用架构模式(PatternofEnterpriseApplicationArchitecture)

·TOGAF的应用架构关注点在应用划分和应用之间的关系，并不涉及任何应用内部;

技术架构实践的主要步骤

分析技术需求

技术架构选型

评估相关影响;

(UI、DB紧耦合)

云原生架构

·DevOps、容器、

Kubernetes、Service

Mesh

中台“架构”

·业务中台、数据中台、

技术中台;

·忒修斯之船(TheShipofTheseus)

·一艘在海上航行了几百年的战船，归功于不间断的维修和替换部件，只要一块木板腐烂了，它就会被替换掉，以此类推，直到所有的功能部件都不是最开始的那些了。在公元一世纪，有人提出一个问题：最终产生的这艘船是否还是原来的那艘忒修斯之船，或是一艘完全不同的船?如果不是原来的船，

那么在什么时候它不再是原来的船了?

·技术架构是在不断演进中的;

架构演进举例

·为了降低单体系统的复杂度、耦合度，引入微服务架构

·为了解决大量服务的动态发现问题，引入了注册中心

·为了提高多实例服务的资源使用率、吞吐量，引入了负载均衡器与相关算法

·为了解决分布式服务的统一配置管理的问题，引入了配置中心

·为了对微服务内部进行监控运维，引入了可观测性组件

·为了防止服务过载，保证系统稳定，引入了流量控制组件

·为了对服务访问进行统一管理，引入了API网关

·为了实现微服务的快速灵活部署与弹性扩容，降低资源占用，引入容器

·为了解决容器的编排和调度问题，引入Kubernetes(k8s)

·为了平衡开发的频繁交付和运维的稳定可靠，引入DevOps

·为了提高基础架构安全性，将其升级成DevSecOps

·为了改善开发体验、充分利用开发资源，提出平台工程

·为了解决微服务框架的侵入性编码问题???引入Sidecar模式，搭建ServiceMesh架构

·为了有更好的底层支撑，引入Istio,运行在k8s上;

目录

·一、技术架构相关概念与特性

·二、新一代HIS技术架构需求与挑战

·三、新一代HIS技术架构选型对策;

·海量用户(快速扩张)

·流量突增(几乎不可预知)

·可用性(7x24小时不间断服务)

·可维护性(发生故障后迅速恢复能力)

·性能(响应时间)

·易用性(用户用脚投票)

·产品迅速迭代(时间成本昂贵)

·多版本、跨平台;

新一代HIS技术架构设计的需求

系统碎片化;

性能需求

·数据存储

·对关系数据库的需求，对响应时间、并发、一致性要求极高

·对非关系型数据的需求，如文档、图像等数据的存储

·对数据分析的需求，包含大数据、OLAP等

·缓存

·重点关注数据一致性、缓存过期等问题

·服务调用

·不同场景下，选择合适的通信协议、编解码方式

·性能比较：进程内vs跨进程，本地vs远程，直连vs代理

·减少分布式事务

·服务/接口的编排与粒度设计

·合并，例：通过BFF(Backend-for-Frontend)实现数据聚合

·拆分，例：门诊处方开单校验;

互操作性需求

·核心系统内部访问

·耦合程度高，互相访问频繁，重点关注复杂架构的简化

·支持长连接、异步、高性能的RPC最佳

·核心系统对外访问

·依然需要ESB/集成平台：统一接入管理，支持各类协议

·让“哑巴”系统开口

·自我介绍：参考FHIR规范，提供服务级能力声明(CapabilityStatement),资源+操作

·即插即用：注册本系统的能力/需求，获取已注册的能力/需求

·声明方式：RPC+IDL,RESTfulAPI+OAS,WebService+WSDL;

可扩展性需求

·Scalability

·通过增加资源提高系统性能的能力——线性增长

·垂直扩展(拆分，分布式)、水平扩展(负载均衡，集群)

·医院内部用户数量与流量相对稳定，高峰低谷基本可预知，除多租户架构外，对此项能力要求一般

·新一代HIS系统上“云”

·Extensibility

·系统方便地增加组件、扩充功能的能力——不以代码量为评价标准

·分而治之：分层、解耦、面向对象的设计模式、服务拆分

·国家医疗卫生行业政策、医院规定复杂