适用于离线环境的一键部署方法、系统及存储介质与流程

1.本技术涉及离线部署技术领域，特别是涉及适用于离线环境的一键部署方法、系统及存储介质。


背景技术：

2.在微服务架构下，一个应用会被拆分为若干个独立的微服务，每个微服务可被单独构建并部署，讲究分而治之，高度自治。这种以每个微服务为颗粒度的部署模型，在toc(to customer)场景下是一个很常规且很标准的流程，但在tob(to business)场景下，由于现场环境复杂，使得部署一个应用变得非常繁琐，且容易出错。
3.因此，为了应对tob场景，目前本领域主要采用以每个应用为颗粒度的部署模型，将应用内部的各微服务一并打包在一起，并且内部处理好各微服务间的依赖关系及配置，最后统一一次性部署，简化部署流程。但随着公司业务的不断扩张，应用变得越来越多，各应用之间的关系也变得错综复杂，此时暴露的问题，与之前以每个微服务为颗粒度进行模型部署所遇到的问题极为类似，这使得部署公司的某一套产品解决方案变得繁琐复杂，因为一套解决方案涉及到一系列的应用需要部署。
4.所以，将一套完整的产品功能体系涉及到的所有应用部署包，能够跨应用边界自动编排部署到k8s集群中，系统内部可以自动处理应用的依赖部署顺序，并能够自动填充各种应用依赖配置项的方案很有必要。这种方案旨在为产品高质量、高效率、低成本交付提供一套适应医院现场环境的一键部署方案。


技术实现要素：

5.鉴于以上所述现有技术的缺点，本技术的目的在于提供适用于离线环境的一键部署方法、系统及存储介质，用于解决现有技术中的部署方案不适用于医院离线环境的技术问题。
6.为实现上述目的及其他相关目的，本技术的第一方面提供一种适用于离线环境的一键部署方法，包括：rm平台制作医疗机构产品关联的一或多个应用部署包的元数据并引入输出变量；rm平台对所述医疗机构产品关联的一或多个应用部署包进行版本管理；rm平台决策部署顺序以生成部署工作流，并在将所述部署工作流进行序列化后注入所述元数据中形成元数据文件，将所述医疗机构产品关联的应用部署包及所述元数据文件打包成项目包；sm平台上传所述项目包，并执行部署工作流以进行一键部署至k8s集群中。
7.于本技术的第一方面的一些实施例中，所述引入输出变量的过程包括：通过使用所述rm平台的部署包制作构建功能，声明所述应用部署包中的模板服务所需输出的参数配置键，且所述参数配置键(key)具有全局唯一性及不可改动性；在构建部署包时，将除了rm平台自行统一管理之外的参数配置键注入到所述元数据中，供sm平台解析使用。
8.于本技术的第一方面的一些实施例中，对于只能在实施现场确定的现场配置，由sm平台统一声明所述现场配置，且所述现场配置具有全局唯一性及不可改动性；rm平台通
过拉取这些现场配置将其同步到rm平台进行管理，以便输入配置根据需要引用这些现场配置；对于不依赖应用边界配置的输入配置，将配置的值定义为适应现场的默认值。
9.于本技术的第一方面的一些实施例中，所述rm平台对所述医疗机构产品关联的应用部署包进行版本管理，其包括：明确该医疗机构产品的依赖项及其依赖项的版本范围，再进行版本发布的动作；若所述医疗机构产品的依赖项为特定版本，则声明指定的版本号依赖；若所述医疗机构产品的依赖项为某个版本范围，则声明其依赖的版本为某个版本区间。
10.于本技术的第一方面的一些实施例中，所述rm平台对所述医疗机构产品关联的应用部署包进行版本管理，还包括：根据所述医疗机构产品的依赖关系生成对应的产品拓扑结构及部署顺序，并据此生成对应的有向无环图，供sm平台解析该元数据后按所述部署顺序编排该有向无环图中各节点上的应用，以完成整个项目的交付落地。
11.于本技术的第一方面的一些实施例中，rm平台基于医疗机构产品所声明的依赖关系来决策部署顺序，其过程包括：rm平台根据医院项目所需部署的产品范围，分析产品范围内各种产品的依赖，对零依赖的产品最先部署，随后按照依赖链顺序逐项部署，直至依赖链末端，生成依赖关系图，形成部署工作流。
12.于本技术的第一方面的一些实施例中，rm平台基于人工干预调节来决策部署顺序，其过程包括：rm平台先根据依赖关系生成部署工作流，随后响应于用户操作而相应地动态调整部署工作流的部署顺序。
13.需说明的是，rm平台通过设置部署前置动作、部署后置动作、及是否可手工确认部署动作，动态调整部署行为，部署工作流顺序，在rm平台一旦确认即不可更改。
14.于本技术的第一方面的一些实施例中，sm平台执行部署工作流以进行一键部署至k8s集群中，其过程包括：在完成项目包的上传后，基于所述项目包中的元数据文件生成对应的项目部署工作流实例，将所述项目部署工作流实例的初始状态设定为待启动；执行各项前置检测并引导用户进入该项目包的一键部署工作流有向无环图页面；将所述项目部署工作流实例的的状态更改为执行中，并按照所述有向无环图执行各应用节点的部署编排工作；在执行所述有向无环图中的每项应用节点时生成对应的应用节点实例，且将所述应用节点实例关联于所述项目部署工作流实例；在所有的应用节点都完成执行，且符合项目部署工作流实例的执行成功条件时，将所述项目部署工作流实例的的状态更改为执行成功。
15.为实现上述目的及其他相关目的，本技术的第二方面提供一种应用部署包的打包系统，包括：元数据制作模块，用于制作医疗机构产品关联的一或多个应用部署包的元数据并引入输出变量；版本管理模块，用于对所述医疗机构产品关联的一或多个应用部署包进行版本管理；项目包打包模块，用于决策部署顺序以生成部署工作流，并在将所述部署工作流进行序列化后注入所述元数据中形成元数据文件，将所述医疗机构产品关联的应用部署包及所述元数据文件打包成项目包。
16.为实现上述目的及其他相关目的，本技术的第三方面提供一种应用部署包的部署系统，包括：上传模块，用于上传项目包；部署模块，用于执行部署工作流以进行一键部署至k8s集群中；其中，所述部署工作流由rm平台决策部署顺序后生成；所述项目包由rm平台将医疗机构产品关联的应用部署包及元数据文件打包而成。
17.为实现上述目的及其他相关目的，本技术的第四方面提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述适用于离线环境的
一键部署方法。
18.如上所述，本技术的适用于离线环境的一键部署方法、系统及存储介质，具有以下有益效果：本发明将完整产品功能体系涉及到的所有应用部署包，跨应用边界自动编排部署到k8s集群中，本发明能够有效的减少医院现场实施人员的出错率，提升部署效率，因此很好地适应于医院现场高质量、高效率、低成本交付的部署方案。
附图说明
19.图1显示为本技术一实施例中一种适用于离线环境的一键部署方法的流程示意图。
20.图2显示为本技术一实施例中有向无环图的结构示意图。
21.图3显示为本技术一实施例中元数据文件的结构示意图。
22.图4显示为本技术一实施例中一种适用于离线环境的一键部署方法的流程示意图。
23.图5显示为本技术一实施例中一种应用部署包的打包系统的结构示意图。
24.图6显示为本技术一实施例中一种应用部署包的部署系统的结构示意图。
具体实施方式
25.以下通过特定的具体实例说明本技术的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本技术的其他优点与功效。本技术还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本技术的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
26.需要说明的是，在下述描述中，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包含”、“包括”表明存在所述的特征、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。应当进一步理解，此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。
27.本发明针对现有部署流程中的缺陷，提供适用于离线环境的一键部署方法、系统及存储介质，将完整产品功能体系涉及到的所有应用部署包，跨应用边界自动编排部署到k8s集群中，本发明能够有效的减少医院现场实施人员的出错率，提升部署效率，因此很好地适应于医院现场高质量、高效率、低成本交付的部署方案。
28.为了使本发明的目的、技术方案及优点更加清楚明白，通过下述实施例并结合附图，对本发明实施例中的技术方案的进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定发明。
29.如图1所示，展示了本发明实施例中一种适用于离线环境的一键部署方法的流程示意图。
30.通常情况下，医疗机构基于安全考虑，其机房不会直接接入互联网通信，因此本发明的技术方案，设计了供研发人员发布应用的rm平台，及用于医疗机构现场部署应用的sm平台，rm平台与sm平台相互配合，互为补充，既满足了医疗机构离线部署的需求，也将研发-部署-交付整合于一个整体，提升交付流程效率。为便于本领域技术人员理解，先对下文中出现的专业词汇做如下解释说明：
31.rm(release manager)平台是基于gitlab实现打包的平台，供研发人员打包应用后将对应的产品关联应用包发布；医院的现场实施人员可下载对应的部署包，用于医院产品的部署。应理解的是，gitlab是一个用于仓库管理系统的开源项目，使用git作为代码管理工具，并在此基础上搭建起来的web服务；rm平台适用的机构包括但不仅限于医院，还可以是卫生院、疗养院、门诊部、诊所、卫生所、急救站等等。
32.sm(service manager)平台是基于kubernetes实现部署应用的平台，供医院实施人员将研发人员提供的部署包部署到医院现场。应理解的是，kubernetes也通常称为k8s，是一个开源的用于管理云平台中多个主机上的容器化的应用，其目标是让部署容器化的应用简单并且高效，提供了应用部署、规划、更新和维护的一种机制。
33.在本实施例中，所述适用于离线环境的一键部署方法包括步骤s11～s15，下文将结合具体实施例对各步骤进行详细的说明。
34.步骤s11：rm平台制作医疗机构产品关联的一或多个应用部署包的元数据并引入输出变量(outputs)；对于有依赖关系的应用，被依赖方引入所述输出变量供依赖方引用；这样，在部署时，被依赖方部署功能后，其终端应用节点endpoint自动填充到所述依赖方的配置变量中，从而省去热工填充。
35.应理解的是，元数据(metadata)又称为中介数据或中继数据，是描述数据的数据，主要描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
36.在一些示例中，制作所述元数据时引入输出变量(outputs)，用以公开所述应用部署包的特定信息，例如服务器的端点信息或任何其它运行时的运行信息。部署完成后，实例可以公开该应用声明的特定输出。
37.在一些示例中，上述引入输出变量的过程包括：通过使用所述rm平台的部署包制作构建功能，声明所述应用部署包中的模板服务所需输出的参数配置键(key)，且所述参数配置键(key)具有全局唯一性及不可改动性。进一步地，在构建部署包时，将除了rm平台自行统一管理之外的参数配置键(key)注入到所述元数据中，供sm平台解析使用。
38.在一些示例中，对于只能在实施现场确定的现场配置，例如数据库服务器地址等，由sm平台统一声明所述现场配置，且所述现场配置具有全局唯一性及不可改动性；rm平台通过拉取这些现场配置将其同步到rm平台进行管理，以便输入配置根据需要引用这些现场配置。需说明的是，现场配置统一在sm平台管理定义，每次部署到现场时刷新现场配置定义列表，且现场配置的值由现场集成人员填写。
39.在一些示例中，对于不依赖应用边界配置的输入配置，将配置的值定义为适应现场的默认值，避免现场部署时需要调整。其中，边界配置是一种半解析的数值方法，是边界
发展之后的另一种新的数值分析方法。
40.步骤s12：rm平台对所述医疗机构产品关联的一或多个应用部署包进行版本管理。
41.在一些示例中，所述rm平台对所述医疗机构产品关联的应用部署包进行版本管理，包括明确该医疗机构产品的依赖项及其依赖项的版本范围，再进行版本发布的动作。
42.进一步地，若所述医疗机构产品的依赖项为特定版本，则声明指定的版本号依赖；若所述医疗机构产品的依赖项为某个版本范围，则声明其依赖的版本为某个版本区间。应理解的是，上述两点的完善性及正确性直接影响后续生成依赖关系图并决定产品部署顺序的正确性，因此至关重要。
43.在一些示例中，所述rm平台对所述医疗机构产品关联的应用部署包进行版本管理，还包括根据所述医疗机构产品的依赖关系生成对应的产品拓扑结构及部署顺序，并据此生成对应的有向无环图，供sm平台解析该元数据后按所述部署顺序编排该有向无环图中各节点上的应用，从而完成整个项目的交付落地。其中，所述有向无环图指的是一个无回路的有向图，如果一个有向图无法从某个顶点触发经过若干条边回到该点，那么这个图就是一个有向无环图(dag图)。
44.为便于理解，现结合图2对所述有向无环图做进一步的解释说明。
45.在step1中，编排应用节点sso-3.0.0和logging-1.6.0，每个应用节点都是由产品名称和产品版本组成的唯一标识，其中，应用节点sso-3.0.0的产品名称为sso，产品版本为3.0.0；应用节点logging-1.6.0的产品名称为logging，产品版本为1.6.0。应用节点sso-3.0.0和logging-1.6.0都指向step2。
46.在step2中，编排应用节点taskcenter-3.0.0，且应用节点taskcenter-3.0.0的产品名称为taskcenter，产品版本为3.0.0。应用节点taskcenter-3.0.0指向step3。
47.在step3中，编排应用节点empi-5.0.0和bank-6.0.0，每个应用节点都是由产品名称和产品版本组成的唯一标识，其中，应用节点empi-5.0.0的产品名称为empi，产品版本为5.0.0，应用节点bank-6.0.0的产品名称为bank，产品标识为6.0.0。
48.步骤s13：rm平台决策部署顺序以生成部署工作流，并在将所述部署工作流进行序列化后注入所述元数据中形成元数据文件，将所述医疗机构产品关联的应用部署包及所述元数据文件打包成项目包。
49.在一些示例中，rm平台基于医疗机构产品所声明的依赖关系来决策部署顺序。具体是指：rm平台根据医院项目所需部署的产品范围，分析产品范围内各种产品的依赖，对零依赖的产品最先部署，随后按照依赖链顺序逐项部署，直至依赖链末端，生成依赖关系图，形成部署工作流。
50.在一些示例中，rm平台基于人工干预调节来决策部署顺序。具体是指，rm平台先根据依赖关系生成部署工作流，随后响应于用户操作而相应地动态调整部署工作流的部署顺序。举例来说，用户可对rm平台自动生成的部署工作流，根据实际情况，以拖曳等形式在部署工作流图上动态调整部署顺序。预留人工干预调节的操作，便于人工决策，大大提高准确性。
51.在rm平台决策部署顺序并生成部署工作流后，将部署工作流序列化注入到元数据中，形成元数据文件，随后再将所述医疗机构产品关联的应用部署包及所述元数据文件打包成项目包。应理解，项目包是基于产品的应用包套壳，内部结构延续应用包的格式，也即
项目包的内部实际上还是应用包，这样可将多个应用包放在一起，项目包实际上是组织多个应用包的一层壳，其次再追加一个部署工作流的元数据，以便在sm平台识别并进行部署处理。
52.其中，所述元数据文件(deployworkflow.json)的文件机构如图3所示，对应于图2中有向无环图的编排顺序。在图3中，元数据文件包括如下各项内容：医院项目编码、医院项目名称、描述信息、项目包版本、项目包中基于部署顺序的各应用部署包的唯一标识等等。值得注意的是，本实施例在编排部署时部分或全部的应用部署包可以容忍部署失败，进而直接进入下一步，不至于卡住流程。
53.步骤s14：sm平台上传所述项目包。
54.sm平台通过开放入口上传项目包，在上传过程中，与非一键部署逐个解析元数据所不同的是，本实施例一并解析多个应用部署包的元数据，依次将各个应用部署包上传至sm平台，完成后的下一步将直接引导用户进入一键部署工作流导向。
55.步骤s15：sm平台执行部署工作流以进行一键部署至k8s集群中。所述执行部署工作流的具体过程如下：
56.第一步：在完成项目包的上传后，基于所述项目包中的元数据文件生成对应的项目部署工作流实例，将所述项目部署工作流实例的初始状态设定为待启动，还可将所述项目部署工作流实例存储至数据库中。
57.第二步：执行各项前置检测并引导用户进入该项目包的一键部署工作流有向无环图页面。具体来说，前置检测例如检测各应用节点的节点端口(nodeport)是否存在冲突，引导提示用户调整存在节点端口冲突的应用节点的输入配置项，还会检测已完成部署的应用节点，并在dag图中对应的应用节点上进行标记，例如标记为“已完成部署，跳过该应用节点”等等。
58.第三步：将所述项目部署工作流实例的的状态更改为执行中，并按照所述有向无环图执行各应用节点的部署编排工作。具体来说，在各项前置检测都没问题后，就可以将该项目的一键部署工作流的实例状态改为“执行中”，并开始按照dag图中执行各应用节点的部署编排工作，应用节点的执行部署结果需要实时反馈到dag图中。
59.第四步：在执行所述有向无环图中的每项应用节点时生成对应的应用节点实例，且将所述应用节点实例关联于所述项目部署工作流实例；在所有的应用节点都完成执行，且符合项目部署工作流实例的执行成功条件时，将所述项目部署工作流实例的的状态更改为执行成功。其中，所述项目部署工作流实例的执行成功条件例如可以系统默认以所有pod状态为running conditions都为true作为评判标准。
60.具体来说，在执行dag图中的每项应用节点时，会生成一个应用节点实例，并关联项目部署工作流实例，是具体执行编排的最小单位。应用节点执行成功的条件，系统默认以所有pod状态为running conditions都为true作为评判标准，仅当“应用节点实例”被标记为“执行成功”，才能进入下一step的应用节点编排执行工作(除非当前“应用节点”在rm中定义时被标记为“允许失败”，可以容忍执行失败，直接进入下一step)。依次类推，直到每项应用节点都完成执行，并且符合项目部署工作流实例的执行成功条件，即可将该项目部署工作流实例状态标记为执行成功，同时代表对该项目包一键部署完成。
61.为便于本领域技术人员对于本实施例中基于rm平台和sm平台的适用于离线环境
的一键部署方案有更全面的了解，下文结合图4来做整体性地描述：
62.rm为一键部署创造条件，用于制作医疗机构产品关联的一或多个应用部署包的元数据并引入输出变量。通过使用所述rm平台的部署包制作构建功能，声明所述应用部署包中的模板服务所需输出的参数配置键(key)，在构建部署包时，将除了rm平台自行统一管理之外的参数配置键(key)注入到所述元数据中，供sm平台解析使用。
63.rm声明产品依赖关系，随后根据医院项目产品范围，生成依赖关系图，并决策产品部署顺序，将依赖关系图注入元数据中，一并打包成项目包。
64.sm平台通过开放入口上传项目包，一并解析多个应用部署包的元数据，依次将各个应用部署包上传至sm平台，完成后的下一步将直接引导用户进入一键部署工作流导向，最终一键部署至k8s集群中。
65.如图5所示，展示了本发明实施例中一种应用部署包的打包系统的结构示意图。所述应用部署包的打包系统500包括：元数据制作模块501、版本管理模块502、项目包打包模块503。
66.其中，元数据制作模块501用于制作医疗机构产品关联的一或多个应用部署包的元数据并引入输出变量；版本管理模块502用于对所述医疗机构产品关联的一或多个应用部署包进行版本管理；项目包打包模块503用于决策部署顺序以生成部署工作流，并在将所述部署工作流进行序列化后注入所述元数据中形成元数据文件，将所述医疗机构产品关联的应用部署包及所述元数据文件打包成项目包。
67.如图6所示，展示了本发明实施例中一种应用部署包的部署系统的结构示意图。本实施例的部署系统600包括上传模块601和部署模块602。
68.上传模块601用于上传项目包；部署模块602用于执行部署工作流以进行一键部署至k8s集群中；其中，所述部署工作流由rm平台决策部署顺序后生成；所述项目包由rm平台将医疗机构产品关联的应用部署包及元数据文件打包而成。
69.需说明的是，所述应用部署包的打包系统500及部署系统600的实施原理及过程，已于上文的适用于离线环境的一键部署方法的技术内容中予以详述，此处不再赘述。
70.应理解，以上系统的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，项目包打包模块可以为单独设立的处理元件，也可以集成在上述系统的某一个芯片中实现，此外，也可以程序代码的形式存储于上述系统的存储器中，由上述系统的某一个处理元件调用并执行以上项目包打包模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
71.例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(application specific integrated circuit，简称asic)，或，一个或多个微处理器(digital signal processor，简称dsp)，或，一个或者多个现场可编程门阵列(field programmable gate array，简称fpga)等。再如，当以上某个模块通过处
理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(central processing unit，简称cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称soc)的形式实现。
72.本发明还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述适用于离线环境的一键部署方法。
73.本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过计算机程序相关的硬件来完成。前述的计算机程序可以存储于一计算机可读存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
74.于本技术提供的实施例中，所述计算机可读写存储介质可以包括只读存储器、随机存取存储器、eeprom、cd-rom或其它光盘存储装置、磁盘存储装置或其它磁存储设备、闪存、u盘、移动硬盘、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。另外，任何连接都可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字订户线(dsl)或者诸如红外线、无线电和微波之类的无线技术，从网站、服务器或其它远程源发送的，则所述同轴电缆、光纤光缆、双绞线、dsl或者诸如红外线、无线电和微波之类的无线技术包括在所述介质的定义中。然而，应当理解的是，计算机可读写存储介质和数据存储介质不包括连接、载波、信号或者其它暂时性介质，而是旨在针对于非暂时性、有形的存储介质。如申请中所使用的磁盘和光盘包括压缩光盘(cd)、激光光盘、光盘、数字多功能光盘(dvd)、软盘和蓝光光盘，其中，磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。
75.综上所述，本技术提供适用于离线环境的一键部署方法、系统及存储介质，本发明将完整产品功能体系涉及到的所有应用部署包，跨应用边界自动编排部署到k8s集群中，本发明能够有效的减少医院现场实施人员的出错率，提升部署效率，因此很好地适应于医院现场高质量、高效率、低成本交付的部署方案。所以，本技术有效克服了现有技术中的种种缺点而具高度产业利用价值。
76.上述实施例仅例示性说明本技术的原理及其功效，而非用于限制本技术。任何熟悉此技术的人士皆可在不违背本技术的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本技术所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本技术的权利要求所涵盖。