互联互通、集成平台、技术架构、集成引擎、微服务架构、API网关、资源调度、服务注册
国家医疗健康信息互联互通标准化成熟度测评(简称“互联互通测评”)现已成为衡量医疗机构信息化建设水平的重要测评之一。 而在医院的互联互通测评中,其指标最核心的测评对象则是聚焦于医院平台的信息交换层,而这对于平台的技术架构和功能上均提出了要求。
图1 医院信息平台参考技术架构
图片来源: WS/T 447-2014 基于电子病历的医院信息平台技术规范
本文分为上下两篇,分别会以2020互联互通测评评审内容3.1.2“信息整合技术”和3.1.5“平台功能”为例,对互联互通测评备注中提到的关于集成平台的技术架构和平台功能等概念进行梳理和解读。
技术架构
互联互通评审标准 3.1.2 “信息整合技术”
2020互联互通测评中,提出的信息整合技术是总线技术架构,即基于信息平台架构,通过企业服务总线 (ESB)或消息中间件实现服务注册、服务发布和服务适配。 不过在互联互通测评3.1.2“信息整合技术”的备注中也指出: 在总线技术基础上,可进一步探索基于微服务架构的环境搭建,实现服务注册、应用配置、服务监控、API 网关、服务安全、资源调度等方面的系统化管理,实现院内外部分业务的微服务化互通。
其中,微服务、服务注册、API网关和资源调度对于医院平台的数据交换中间件都是非常重要或是在互联互通测评中提出的架构建议。
图2 2020互联互通测评评审内容3.1.2信息整合技术
微服务
对于医院信息平台的中间件而言,微服务架构可以分为业务应用级微服务和自身架构级微服务。
业务应用级微服务,是将平台上运行的业务拆分为多个可独立开发、设计、部署运行的小应用和接口服务,提高对需求的快速响应能力,并能根据不同应用进行灵活组合,对业务进行合理解耦,这是对于微服务这个概念较为基础的应用,是SOA的典型技术场景。
自身架构级的微服务,则是指中间件自身的模块组件和功能是微服务化,通过基于Kubernetes(K8s)分布式容器化技术,搭建“云原生平台”,从原本平台架构对于微服务的适配,变为架构与微服务融为一体,充分展现微服务和云原生的特性及优势。
Odin NeXT云原生平台就具备自身架构级的微服务,能充分发挥PaaS云计算环境下的动态调动、弹性延展、精细化资源配置等特性,更好地支撑超大规模云计算,而这些能力也都是传统IT架构的引擎在部署到云环境时所无法实现的。
服务注册
在了解服务注册之前,我们需要明确对于医院集成平台而言,什么是“服务”?
狭义服务指的是HTTP、SOAP等接口服务,广义的服务还包括数据库对接、HL7、MQ、Kafka、FTP等多种数据交换模式的交互服务等。
在服务注册中,医院平台的数据交换组件需要支持各类应用的接口服务(WebService, HTTP)或者HL7 v2等服务进行注册,并且对已注册的服务可进行管理和查看。 可以设置注册服务的地址、端口、以及访问上下文等,同时如果涉及到SSL传输,则可上传证书实现接口支持。 另外也提供重试策略设定,在运行中如果发现注册服务出错,可根据间隔频率进行重试。
API网关
API网关是用于接收、整合、处理客户端调用后端请求的API管理工具,常常需要对集成平台进行二次开发才能实现该功能。 医院平台中的API网关服务应用,需要具有鉴权管理、流量控制、黑白名单、访问控制等API管理功能,不仅需要起到聚合接口,降低了客户端与后端的耦合度的作用,还需要能统一整合后台服务,并提高整体性能。
Odin引擎集群版不仅具备上述API网关的功能,还打通和服务终端的对接环节,通过服务终端目录进行界面化配置选择,实现API网关路径同服务的绑定。 灵活调整需要系统化管理的服务项目,操作方便,提升用户体验。
资源调度
资源调度,架构层面上一般是指集群或云原生架构下,对于资源的合理利用,根据架构不同其利用和管理的颗粒度也不同。 在集群架构下可以做到虚拟机级别的资源配置,而在云原生架构下则可以实现单集成业务级的资源利用,灵活根据实际需求来合理分配资源。
如果是采用了一体化集群(如Odin引擎集群版),可以通过自定义容灾策略,根据业务实际情况对计算资源进行灵活配置,实现定向隔离计算和负载、精细化故障转移等功能,还能达到智能资源分配的效果,让多台服务器同时运行并进行统一运维监控管理,实现高可用、高稳定、高性能等特点,为大规模集成提供能力支撑。
如果是采用了基于Kubernetes的云原生平台(如Odin NeXT云原生平台),则可以通过Kubernetes提供的水平自动扩展(Horizontal Pod Autoscaler)来根据CPU占用率或其他性能指标参数来进行自动扩展。 当CPU占用率过高时,Kubernetes会自动创建新的Pod来满足运行需求。 通过部署单元,可以灵活地根据实际需求来合理分配资源。 其中,各集成业务在云原生架构下的各节点中运行,当出现业务负载过高时,能通过对不同业务的负载检查,找出过度忙碌的业务,并通过合理的资源调度分摊至有多余资源的节点中运行。
Odin文章评论: