关键字
集成平台、集群架构升级、注意事项、事前准备、一体化集群
互联互通等各项测评和集成平台实际应用的关系从“7分为评，3分为用”，逐渐转变为“ 7分为用，3分为评”。 而三甲医院采用一体化集群架构实现集成平台数据交换，正成为一种趋势。 那医院该如何升级，在升级集群架构的过程中，又有哪些注意事项？
集成平台升级为集群架构之前医院的“三问”
医院在进行集群架构升级前，经常会问到的几个问题，即：
1. 集成平台升级为集群架构能够带来的价值和提升在哪里？
满足各类信息化测评
由于医院内靠信息化支撑的业务越来越多，需要通过更多交互服务完成互联互通相关要求。 2020版互联互通测评标准中，需要实现的互联互通交互服务数量也由32个增加到69个。 除了打通内部业务外，标准中还提出集成平台需联通大量外部业务和平台（如上级或本区域的区域信息平台）。 同时智慧服务分级评价标准中也提到了各查询类业务在高并发环境下的稳定运行，这对于集成平台的性能、稳定性和健壮性等方面都提出了更高的要求。
升级为集群架构的集成平台后，能轻松满足互联互通五乙，电子病历六级等各类测评中的相关要求，并为将来更高级别的测评打好“地基”。
提升医院运营效能
随着业务的扩展以及医院整体的数字化转型，医院智慧管理从流程驱动转为数据驱动，2020年国家卫健委同国家中医药局联合印发的《关于加强公立医院运营管理的指导意见》中也指出需要强化信息支撑以“实现资源全流程管理”。
集成平台升级为集群架构之后整体性能和消息处理能力的提升，包括更高的TPS（事务数/秒）、更大的吞吐量、更多的并发数、更快的响应时间等，通过负载均衡和快速扩容能力提供高效合理的动态任务分配机制，提升总体运行效率，能更轻松地支撑起医院的核心业务，助力实现全流程闭环管理。 即使在未来业务快速增长，面对多院区、集团化、区域化等大规模医疗数据应用场景，也能保证集成平台的稳定运行。
降低管理运维成本
传统“双活”或“多活”方式在运行时，消息、操作数据、日志等都分布在不同服务器上，难以实现数据的有效整合、实时监控和远程管理。
升级为集群架构之后，能真正实现一体化集群，包括界面的一体化、组件的一体化、功能的一体化等。 一体化集群有着统一配置监控管理界面而不是分散化的平台，降低运维难度，提高监控可及能力。 同时也能结合态势感知等功能对一些数据交换和集成过程中的异常值（如队列内的消息量、发布服务的处理延时等）提前进行报警，提示运维人员进行检查，在源头上对问题进行控制，防患于未然，降低运维管理成本。
2. 集成平台升级为集群架构的过程中会不会影响现有稳定性？
集群架构的升级过程通常是会分步，逐渐将数据消息的生产方和消费方由当前架构迁移至升级后的集群架构上，集群架构中的统一监控功能能在切换时很好地监控消息的流向，由于集群架构中的生产和监控分离，即使生产服务器出现异常也不会影响到对于整体的监控功能。 这使集群架构能自动侦测并在其他服务器（节点）自动启动该任务的模块来进行处理，实现业务服务的精细化故障转移，从架构上规避了单点故障的风险。
3. 集成平台升级为集群架构的过程是否难度很高？ 周期很长？
通常情况下，如果合作厂商有集群版产品，难度并不高； 如果没有，需要通过不同厂商的集成平台之间进行集群架构升级，只要和厂商做好充分沟通，医院事前也做足规划和准备，想要实现集成平台的平滑快速升级也并不困难。
医院如何能让集成平台平滑快速地升级为集群架构
对于医院集成平台升级为 集群架构这一个事项的规划和设计，有如下的建议和思路可供参考：
产品方面
若合作厂商已拥有集群版产品能直接进行架构升级，则侧重于关注厂商本身的产品和服务能力，包括：
厂商的集成平台产品要具备快速升级能力
集成平台进行架构升级过程中，厂商的支持是必不可少的。 产品进行此类集群架构的升级，考验的是产品自身的延续性。 医院在考察时可着重注意厂商对于该产品是否有前瞻、明确、成熟的升级路线图。 一般情况下，有着明确架构升级路线的产品，都会考虑到医院升级集成平台产品架构的需求，因此产品本身也会具备快速升级的能力。
厂商需要做好协助平台进行架构升级的配套服务
除了产品之外，厂商在医院进行架构升级时的配套服务也非常重要。 一旦厂商有一套统一的、行之有效的架构升级流程，能帮助医院在升级过程中少走很多弯路，但同时医院自身也需要做好与医院业务相关的准备工作，有一些能复用的配置可以直接复用，不能复用的也需要在厂商的协助下重新改造调整。
若合作厂商没有集群版，需要用到其它厂商的集群版产品，医院要关注的方面包括：
对原有业务进行分析，分类，重构等
由于更换了不同厂商的产品，集成平台的架构也有所不同，这势必会对医院各业务产生影响。 因此医院需要对原有业务重新进行分析，分类、重构等。 这部分会在下文的业务方面详细展开描述。
根据集群化带来的新特性对部分业务进行重定义
一体化集群相比之前的集成平台架构，保证了高性能、强稳定和容灾，避免了单点故障的风险。 集群还能进行定向隔离负载和动态扩展，更好地保证集成平台的高可用性。 医院集成平台从仅仅满足单一的互联互通要求的单机架构，转为以满足日常生产环境下医院集成需求为目标，兼顾互联互通要求的集群架构，在医院的定位也将从“润滑剂”转变为“主动脉”。
业务分析方面
医院除了对集成平台产品进行了解外，在业务方面也需要重新进行整合和重构，更好地发挥出集群架构的高性能、一体化等特点，满足医院需求，其中包括：
1. 分析
第一步就是要对业务进行分析，明确升级之后不同业务场景下所数据交换需求。 以门诊预约挂号业务场景的集成为例，其中包括了挂号、退号、信息注册、信息查询、注销等功能。
其中信息查询要求响应速度快，有同步处理要求，响应时间不能超过3秒。 对于查询的内容能够根据业务变更灵活调整；
而预约挂号业务对于响应要求不高，但是需要保证消息的传输以及传输时的顺序，因此在应用端的预约和取消预约通过异步进行处理，结果信息的接收可通过发短信或刷新实现查询。
2. 规划
除了具体业务需求的分析之外，还需要做好集群升级项目的规划和顶层设计，随着业务规模越来越大，医院需要将以前较为零散的业务统合到一起，对医院的所有集成业务进行整体的规划与重构，捋清各个集成业务之间的脉络。
通常情况下医院需要将不同的项目按照业务域进行分类，例如分为门诊项目、住院项目、检查项目、检验项目、手术项目等。 而每个大类下再进行细分，例如门诊项目下又包含了门诊挂号、门诊退号、门诊挂号信息查询、门诊就诊接诊、门诊就诊信息查询等。
实施步骤方面
1. 理清顺序
原业务迁移和新业务建设的顺序，建议新业务直接搭载在新平台上，原业务逐步迁移，不影响现有生产。 在业务的迁移顺序方面，非实时业务先迁移，实时的高并发业务先迁移。
2. 做好预案
迁移过程做好恢复预案，一旦此业务迁移到新平台出现问题还能够及时切回原平台，逐个实现集成业务的升级。
结语
集成平台升级为集群架构的过程，需要厂商和医院两方面共同合作，厂商需要提供清晰明确的产品升级流程，而医院也需要充分了解自身需求，做好医院业务的规划和预案，并与厂商进行深入沟通，将集成平台平滑快速地升级为集群架构就并不困难了。
Odin文章评论：