APP下载

医院内部应用的云迁移研究

2020-12-23杨雪寒焦玮张倩孟洁

微型电脑应用 2020年11期

杨雪寒 焦玮 张倩 孟洁

摘 要:针对将医院内部部署的面向患者和社会公众的应用程序迁移上云所面临的系统架构重组和目标云服务选择的问题,提出了一种医院内部应用云迁移方法。该方法从识别应用程序的体系结构和配置文件开始,通过BPM生命周期确定云计算服务的需求,然后通过识别和选择能够满足应用需求的云服务类型,并最终将应用程序部署到选定的云中。文中将该方法应用于医院患者支持系统的云迁移实践,以示该方法的具体操作。

关键词:医院内部应用;云应用;迁移方法

中图分类号:TP 399

文献标志码:A

文章编号:1007-757X(2020)11-0009-04

Abstract:This paper proposes a hospital internal application cloud migration method for the problem of system architecture reorganization and target cloud service selection for the migration of applications for patients and the public in the hospital. The method begins by identifying the application's architecture and configuration files, then determines the requirements of the cloud computing service through the BPM lifecycle, and identifies and selects the type of cloud service that can meet the application's needs, and ultimately deploys the application to the selection in the cloud. In order to illustrate the specific operation of the method, the method is applied to the cloud migration practice of the hospital patient support system.

Key words:hospital internal application;cloud application;migration method

0 引言

医疗行业的云计算技术应用问题已经在实践和学术领域得到了广泛的讨论。云计算技术从数据安全性、感知技术能力、信息技术成本和降低信息系统复杂性等方面给医疗行业信息技术的发展带来巨大改变,使得云计算技术在医疗行业得到充分重视[1-3]。对医院业务系统而言,相对于传统信息技术基础设施,具有按需服务、广泛的网络访问、资源池按需分配、快速弹性和可测量的业务服务等特点的云计算服务具有巨大的成本优势和技术优势,因此基于云的WEB应用已经成为医院业务系统发展的主流趋势[4]。就医疗领域现有应用程序的体系结构而言,客户端-服务器(B/S)模式在过去几十年中使用得最多,几乎所有现有的应用程序都是使用这种样式构建的[5]。为此将基于传统技术架构应用迁移到云端已成为医院IT从业者不可回避的挑战。已有一些学者针对这个问题开展研究,然而研究结果普遍存在一些不足之处[6-8]:(1)很少考虑Web应用程序和云的体系结构;(2)对迁移后的云应用程序的分布式风格的云需求很少有说明。这些缺陷不可忽视,因为经过深思熟虑的迁移流程对于以系统和管理的方式指导许多应用程序的迁移至关重要。为此,本研究提出六步骤应用程序迁移方法。该方法从识别应用程序的体系结构和配置文件开始,然后通过BPM生命周期[9]确定云计算服务的需求,然后通过识别和选择能够满足应用需求的云服务类型,并最终将应用程序部署到选定的云中。为了说明该方法的有效性,本研究将该方法应用于将面向医院宣传的患者支持系统的迁移实践中。其中该医院患者支持系统主要功能是为正向为企业收集患者信息和反向为患者提供医疗服务。

1 迁移方法

1.1 步骤1基线架构标识

该方法从识别内部应用程序的体系结构和概要文件(即基线架构),如图1所示。

图1显示了一个客户支持系统的体系结构,该体系结构具有4层的协作组件,患者通过社区、知识代理和任务服务组件三个系统模块与企业交互。社区帮助患者共享关于他们想要了解的医疗信息。知识代理收集患者的信息,帮助医院捕捉患者存在的医疗服务需求。医院提供当前医疗服务的具体信息,如科室就诊排队情况,帮助患者进行识别和比较。

完成对应用程序体系结构的识别后是捕获其配置文件以调整应用程序的大小。通常,应收集应用程序配置文件至少10到14天,以便计算出每日或每周使用模式的所有差异。有两种关于应用程序的配置文件数据:1) 有关应用程序运行环境的数据,例如CPU、内存、存储、I/O和网络使用情况;2) 有关患者的操作数据,例如活跃用户数、访问连接数、连接等待时间等。

1.2 步骤2目标架构识别

获取应用程序基线架构和概要文件之后,是确定满足其部署目标云的需求。这通常可以通过实施BPM生命周期来实现,通过其策略、设计、执行和控制生命周期阶段来确定目标基线。已确定的云计算的需求包括:1) 能够支持应用程序目标基线功能的在选定云中的配置元素上的部署的架构组件;2) 支持应用程序的非功能性目的的选定云中执行的概要文件,如定制的用户界面和访问模式、应用性能、应用可靠性、数据安全性和系統可扩展性等。

对于所研究的患者支持系统的五个组件可能需要在不同的云环境上分别部署,以支持其体系结构和概要文件需求。此外,为了从患者那里收集信息并向客户传递当前医院的具体服务信息,需要在云计算服务中部署QoS策略,以保证定制的用户界面访问的及时性和和服务信息的可靠性。

1.3 步骤3候选云服务类型确定

在确定对云服务的性能要求之后,该方法继续识别其服务模型(SaaS、PaaS或IaaS)满足这些要求的候选云服务[10-11]。为此考虑提供以下任一云服务模型的所有可用环境:

1. 在SaaS模型中,云服务可以替换应用程序中需要特定QoS特性以确保其替换的服务,如服务级别协议(SLA)、服务的兼容性和数据/访问控制的可移植性[12]。

2. 在PaaS模型中,云服务提供了平台服务,应用程序可以在这些平台服务上部署,这些服务具有SLA、應用程序部署、服务的兼容性和数据/访问控制的可移植性等QoS特性。

3.在IaaS模型中,云服务提供了服务器、存储和网络等基础设施服务,在这些基础设施服务中,应用程序及其剩余平台可以在SLA、应用程序部署、服务兼容性和数据/访问控制的可移植性等QoS特性下使用。

基于满足应用程序需求的考虑,从上述云服务类型选择医疗应用迁移的候选云,如图2所示。

图2显示了医疗患者支持应用的可能候选云,其中IaaS云服务被识别为社区实例的候选者,因为其服务预期由一些基础设施提供,这些基础设施很好地在患者中间支持信息共享的存储和操作。

1.4 步骤4云服务提供商的选择

确定了候选云模型之后,下一步就是基于候选云模型中选择公有云服务提供商。一般来说,可以通过一些评估标准(如上文所述的QoS特性)来进行选择,以切实满足迁移目标对云服务的计算需求和存储需求。

1.5 步骤5云迁移计划的制定

在确定具体云服务提供商后,本研究所设计的迁移方法将指定关于应用程序迁移到上述目标云所涉及的详细执行计划。一般来说,这些活动包括以下方面。

1. 将应用程序组件部署到各自云中的配置元素上。

2. 将应用程序组件之间的交互机制部署在各自云上的云间/云内交互解决方案上。

3.重构任何已部署的组件,以满足使用和用户操作需求,例如定制的用户界面和访问模式、性能、可靠性、安全性和可扩展性。

2 迁移实践

2.1 患者支持系统的基线架构

本研究将所提议的迁移方法应用于医院患者支持系统,验证该方法的有效性。迁移的第一步是从识别内部应用程序的体系结构和基线架构开始。患者支持系统的体系架构如图1所示。该体系结构具有4层的协作组件,患者通过社区、知识代理和任务服务组件三个模块与医院交互。社区帮助患者共享关于医院的具体医疗信息。知识代理收集患者的信息,帮助医院捕捉患者存在的医疗服务需求。医院提供当前医疗服务的具体信息,如科室就诊排队情况,帮助患者进行识别和比较。然后对每个模块功能进行明确。例如,组织社区是为了让患者共享关于其想要了解的医院服务的具体信息,例如门诊人数、专家门诊排班信息等。此外社区组件还负责将收集的信息转发给医院。知识代理重新组织成特定的知识风格。然后将知识发送给任务服务组件,以便转发给企业以满足其需求(例如,提供满足其所需任务的服务)。最后,它还与任务服务组件合作接收服务信息。对这些要求进行相关客户的认可和比较。

综上所述,对社区组件的功能需求总结如下:1) 共享有助于客户之间信息共享的客户信息;2) 处理转发共享信息;3) 通过知识代理将收集的信息重新构造为知识,然后将知识发送到任务服务组件;4) 处理任务请求,该请求从所有的客户端接收任务请求,并将经过评估的关于任务的相关医疗服务信息返回给对应客户端;5) 与接收与任务相关的服务的评估信息的任务服务组件合作;6) 为患者提供带有丰富用户界面控件的客户端以便提供便捷的医疗信息服务信息和用于可视化来自任务服务组件的与任务相关的医疗服务信息。

基于上面对社区的需求,如图3所示。

图3显示了实现这些需求的五个组成部分。特别地,为了实现客户端的用户界面的自定义和个性化需求,采用了一个“接口管理器”的组件,其中使用客户概要文件来确定他们更喜欢哪些接口组件;此外,使用这种自定义的用户界面,“接口管理器”可能会保留其包含的界面小部件,以便共享或关于任务相关服务的可视化信息,从而形成自定义的用户界面,并根据患者的交互需求将其所需的信息显示出来。此外,信息/知识管理器访问社区成员信息和患者所共享的个人信息,协助患者将其病患信息分享给医生。信息/知识管理器还可以通过知识代理组件检索到经过整理重组的与患者相关的数据。任务请求管理器将任务请求从患者转发到与任务服务组件协作的“协作管理器”,以接收关于这些医疗信息请求的评估信息。经过评估被认为能够共享的医疗信息将被可视化处理,并通过接口管理器返回给患者。最后,Web服务管理器负责通过Web服务客户端的应用程序编程接口(API)与这两个外部体系结构组件进行互操作,以访问这两个组件提供的远程服务。

2.2 确定迁移后的目标系统架构

根据患者支持系统的体系结构和配置文件确定其云需求。首先,考虑到该系统的五个分布式组件,不同的云环境可能需要各自部署在这些云中的预期配置元素上,以支持其功能或非功能目的。此外,为了为医院收集患者信息并交付医疗服务信息以造福患者,该系统可能需要部署的云资源使用和用户操作的服务质量(QoS)控制策略,QoS包括定制的用户界面和访问模式、计算性能、存储可靠性、数据安全性和系统可扩展性。

2.3 确定患者支持系统的候选云服务模型

第三步是确定云服务配置和模型,即从SaaS、PaaS和IaaS三种云服务模型中为患者支持系统中各个模块选择最合适的候选云服务模型。通常不止一个云服务模型能够满足系统组件的迁移和部署需求,因此需要系统模块的业务需求的选择候选的云服务模型。图2显示了为患者支持系统各个模块所选择的候选云服务模型。

1) 对于患者知识代理和医院模块,由于SaaS云服务模型能够提供代理模型和医院模块所必须的软件资源,因此被选择为这两个模块的候选云服务模块。

2) 对于任务服务组件,PaaS被认为是最优的候选云服务模型,因为PaaS云服务器平台支持与多个医院模块进行协作以转发患者信息或接收社区信息,并能够提供充分的云间数据分析能力以便将收到的医疗服务信息评估成比较模型供患者进行比较和选择。

3) 对于社区模块,IaaS被选择为候选云服务模型,因為IaaS云基础设施能够提供对患者之间所共享的大量信息的数据存储和处理能力,以及在多个知识代理模块之间进行数据协作以重组患者共享信息形成更为具体的患者个体知识风格的能力。

2.4 患者支持系统云服务供应商的选择

确定了候选云服务模型之后,就是选择要迁移的云服务供应商。对于患者支持系统,所选的云服务供应商确定如下。1)作为国内诸多医疗云服务供应商中,腾讯云提供了较为全面的医院业务流程解决方案,且能够针对各个医院特殊的业务需求进行定制化开发,因此被选定为协作代理模块和医院托管模块SaaS云供应商。2)在诸如百度BBC和微软Azure这样的可用PaaS云中,本研究选择了Azure云作为迁移任务服务组件的载体,因为Azure云具有众所周知的较强的云间协作和数据分析能力,可以充分满足任务服务组件之间的计算资源协作和数据的高效处理的要求。3)在可用的众多的阿里云、华为云等IaaS云中,本研究选择阿里云作为社区模块的上云首选,这是因为阿里云具有良好的数据处理、云间共享和与其他组件交互的性能,同时兼具良好的计算和存储稳定性。社区模块上云后的系统架构,如图4所示。

2.5 患者支持系统迁移计划的制定

在确定了云的选择之后,就可以指定关于应用程序迁移到这些云所涉及的具体迁移计划。这些迁移计划包括:1) 将系统组件部署到各自云中的配置元素上;2) 将系统组件之间的交互机制部署在各自云服务器或云存储系统的交互解决方案上,重构所有已部署的组件,以满足系统运行需要和用户操作需求,如图5所示。

图5显示了患者支持系统五个组件的部署在阿里云的虚拟机(VM)和云存储服务上的概况,其中云存储系统包括S3存储、分布式块存储系统和关系数据库。

3 总结

本文提出了一种将本地面向医院的应用程序迁移到云中的方法。该方法采用BPM生命周期方法对应用程序地架构、业务逻辑和功能需求进行解构,选择最优地云服务模型以实现应用程序的有效迁移。医院患者支持系统的迁移实践表明,该方法能够有效支撑医院内部部署的应用程序的迁移。下一步,本研究将继续探索利用最流行的云计算服务(如新浪SAE和阿里云)将用作部署平台,将医院内部部署的面向患者和公众宣传的应用迁移到云中,以充分提高这些应用程序的运行质量和性价比。同时本研究还将对应用程序的预期迁移质量的量化评估进行研究,充分利用量化指标管控目标云选择、迁移操作等关键项目的质量。

参考文献

[1] 杨凯琪,姚培,赵玉龙,等.面向异构容器云的应用迁移方法[J].计算机工程,2019,45(8):42-47.

[2] 杨凯琪,赵玉龙,陈林.异构容器云间应用迁移模型研究[J/OL].计算机应用研究:1-7[2019-09-21].https://doi.org/10.19734/j.issn.1001-3695.2018.09.0762.

[3] 王雁华.医疗信息云服务建设的关键技术研究[J].科技创新导报,2019,16(3):158-159.

[4] 刘静静.电子就业云迁移框架研究与实现[J].浙江树人大学学报(自然科学版),2018,18(04):8-12.

[5] 顾东晓,李童童,梁昌勇,等.基于云计算的管理信息系统迁移模式与策略研究[J].情报科学,2018,36(12):71-76.

[6] 朱连章,李博,张卫山,等.基于深度学习的普适云服务迁移方法研究[J].太原理工大学学报,2018,49(5):736-744.

[7] 杜昊.云计算技术在医院信息化建设工作中的应用[J].计算机产品与流通,2018(8):259.

[8] 朱广超,史纪强.企业应用系统云环境迁移方案研究[J].油气地球物理,2018,16(3):58-62.

[9] 王伟杰,黄建隆,林耀,等.PACS/RIS系统云迁移若干问题及对策[J].中国数字医学,2016,11(11):101-103.

[10] 应嘉炜.云计算区域数字卫生关键技术信息共享协同平台研究[J].信息与电脑(理论版),2016(2):7-9.

[11] 马海峰,意合巴力,王烨,等.基于清华云监控平台的云迁移性能[J].计算机应用,2015,35(11):3026-3030.

[12] 姜海鸥,宋美娜,鄂海红,等.运营支撑系统混合云迁移策略制定方法[J].北京邮电大学学报,2014,37(5):1-5.

(收稿日期:2020.03.14)