关键字
医院规模、集成平台、低成本、多功能、高可用、高性能、集群
不同规模医疗机构的建设侧重点
通过前一篇文章了解到在选择集成平台中间件（例如集成引擎，ESB）时应做到“知己”（即分析自身情况和需求）和“知彼”（即了解集成平台中间件具有的功能和特性），那具体到不同规模的医疗机构，它们的建设侧重点又分别是什么？
二级医院
知己： 二级医院在集成平台建设时兼顾需求与成本
医院规模
二级医院集成平台建设方面配备的人员少，甚至会出现 整个信息科只有一个员工的情况，可供调配给医院信息化建设的物力、财力资源也有限。 有统计显示，北京地区三级医院的实际床位数为二级医院的3.24倍，但医疗信息化投入是二级医院的7.59倍，同时三级医院获得的政府财政资金为二级医院的5.53倍，可见在除去规模因素外， 三级医院的信息化建设的可调配资金和信息化投入意愿仍然都高于二级医院。
承载业务
承载的业务量相对较少，总体建设的复杂度也较低，但仍需要通过各类数据交换技术实现基本的业务场景（如医院门诊挂号、内网服务分发、抽取数据通过平台上报等），并且需要在有限的人力财力条件下保证日常业务的正常运转。
集成平台定位
由于大部分二级医院有着升三级医院的诉求，现有系统和设备也将会不断更新完善。 但对于集成平台建设没有系统规划，更多时候仅为解决电子病历、互联互通评级所需的场景，后续集成建设缺乏连续性，也难以快速实现对新业务系统的接口和协议支持。
因此，总结下来就是： 钱不够、人不够、规划不够
知彼： 二级医院侧重于从以下几点了解集成平台中间件
IE（集成引擎）、ESB、ETL“三合一”
兼顾成本和业务需求
二级医院想兼顾成本和业务场景需求，因此更需要融合“IE(集成引擎)、ESB、ETL”三种数据交换技术的集成平台中间件，不仅满足场景需求，医院也不用购买多套产品，而且维护更加简单方便，缓解”钱不够“的问题。
稳定性和易用性
二级医院缺乏专业信息化人才，因此产品的稳定性和易用性也更关键。 稳定性可以保证各系统正常运转，同时考虑 冷备、热备、双活等容灾方案保证高可用性。 易用性则能帮助运维人员快速上手，快速定位并解决错误，大幅降低人手短缺对于日常业务运行的影响，缓解”人不够“的问题。
易扩展和易开发性
由于二级医院缺乏长期规划，很可能没有预先考虑到完善设备系统时的配套设施，这就需要集成平台随着系统设备的更新而扩展，为未来二次开发或升级改造留下余地，例如能否提供各类协议支持，或能否开发出适合未来新设备、新系统的API接口，保证新业务的迅速接入（如疫情期间的“健康码”应用的快速上线）。 即通过集成平台核心中间件的易扩展和易开发性缓解“规划不够”的问题。
三级医院
知己： 三级医院有着更全面的业务建设需求
医院规模
三级医院的信息部门人员更多，科室的系统和设备更完善； 相对应的床位数和日门诊量也水涨船高，也有能力且愿意在集成平台建设上投入更多人力财力，是现阶段集成平台建设的主力军。
承载业务
三级医院子系统更多，集成平台普遍需要连接上百个服务点以及几十个集成业务流程，且接入服务点需要随着需求的变更不断增加。 因此需要更多个性化改造定制服务，并开放更多功能。
集成平台定位
基本明确集成平台定位，除了最基础的通过IE(集成引擎)、ESB、ETL实现的各种复杂医疗业务场景，整合多源异构数据，还需要对数据进行标准化处理和二次应用，并根据医院情况和外界大环境提出其它新的信息集成需求，如：
- 以高级别互联互通和电子病历评级为目标，让更多系统通过平台进行数据的交换和集成，实现海量信息共享 （各类符合评级要求的标准支持和配套功能）；
- 集成平台中间件（集成引擎）不允许发生计划外停机的情况 (更严苛的容灾方案)；
- 进一步推动互联网医院 （打通线上线下业务数据）；
想合理运用现有系统和设备中的大数据、物联网等新技术（新技术支持）；
……
知彼： 集成平台如何实现对新集成需求更全面的支持
协议标准及其配套功能本土化
部分国外的特有标准和法案并不适合国内环境，国内医院花大价钱，这些标准却完全用不到。 而像互联互通要求中的CDA标准、数据集标准等国内常用标准，却由于缺乏配套功能（如数据映射）需要医院二次开发。 因此，三级医院对于本土常用标准的配套功能需要格外关注。
关注传统集群方案
这里的集群是指在产品设计时根据医院平台的业务特点原生实现的集群架构，并非单机系统部署在多台虚拟机上形成的“集群”(其核心仍是单机架构)。 它具备着下列特性：
1. 秒级自动化容灾迁移保证高可用
当模块出现异常时，原生实现的集群能自动侦测到异常并在其它服务器(节点)自动启动该任务的模块来进行处理， 实现业务服务秒级自动故障转移 ，展现更好的容灾能力。
2. 横向扩展和负载均衡保证高性能
横向扩展是目前实现高性能的最优解决方案，通过增加服务器数量，大幅提升系统性能； 负载均衡则能根据不同业务场景进行动态任务分配，最大化利用集群中的计算节点。 通过集群架构实现横向扩展，并通过负载均衡实现合理的动态任务分配机制后， 传统集群架构的集成平台TPS能达到数千。
3. 统一的开发监控界面保证易用性
该集群方案还能将处理不同任务的服务器整合至一个逻辑接口，实现了一处配置、多点运行、数据一致的效果， 统一配置监控管理界面， 在一个页面中实现消息追踪、消息监控以及日常消息检索等功能，操作更加便捷，易用性高。
互联网医院建设支持
集成平台中间件提供符合互联网要求的多种协议支持，能帮助线上互联网医院连接线下的各种系统和设备，而具备的API网关能在互联网医院受到外部访问时提供权限管理、访问控制、设置黑名单/白名单等功能，为互联网医院的线上预约、线下复诊、预约床位等业务提供协同支持。
新技术支持
三级医院在信息化建设中都希望融入“云大物移智”等新技术，相对应的集成平台中间件也需要为不断变化的新技术和新的应用场景需求提供支持，如支持流式数据处理的Kafka分布式流平台，支持大数据应用的ZooKeeper、Hadoop等服务和系统架构，支持物联网的MQTT、XMPP等应用层协议......这些都能让集成平台中间件为先进技术的应用打好基础。
集团化医院和大型区域医疗机构
知己： 集团化医院对集成平台中间件高性能和高可用性要求更高
医院规模
集团化医院和大型区域医疗机构由于规模的进一步提升，不仅需要考虑院内系统的集成，还需要转变角色，考虑医院和医院之间以及医联体/紧密型医共体之间的数据集成和交换。
承载业务
经由集成平台核心中间件实现数据交换和集成的“真”集成业务也将由院内延伸至院外, 以浙江省某集团化三甲医院为例，完成多个院区集成所需要建立的集成项目、使用的终端连接和自助机终端有数百个，日消息处理量也有好几百万，如果全部业务都走平台理论上的日消息处理量甚至能达到上千万。
集成平台定位
不仅需要集成院内的HIS、EMR、LIS、PACS、PDA、自助机等各类系统和设备，还需要连接预约平台、省质控平台、上报平台、微信等外部平台，此外还需要注重多个院区间的信息数据交换和集成。 这些目标不是一朝一夕就能达成的，多数情况下这类集团医院或区域医院都有着较为长期（5年以上）的集成平台建设规划。
因此，上述情况会对集成平台中间件的高性能和高可用性上提出更高的要求，而集群化部署方案就成了医院实现集成平台高可用和高性能的首选方案之一。
知彼： 集成平台中间件如何实现真正的集群化部署
传统集群架构的局限性：
资源利用率低； 性能仍存在上限
传统集群架构只能以服务器为单位进行横向扩展，很多情况下扩展的服务器中只有个别应用资源会被使用到，因此和下面即将提到的云原生分布式集群方案相比，资源利用率低很多。
同时随着服务器的增加，对于集群节点管理和调度的难度也会大幅上升，对性能提升的幅度会越来越少，难以完全满足集团化医院或区域医疗机构的性能需求。
云原生分布式集群：
着眼未来的前瞻性方案
除了传统集群，现在也有针对医联体和集团化医疗机构的基于K8s等容器化技术实现的云原生分布式集群。 云原生是未来医院业务快速变化背景下的必然技术趋势，而支撑起云原生分布式集群的就是Kubernetes容器编排和以Docker为代表的容器技术。
任务进程监管粒度更细，性能和可用性突破传统集群局限
和传统集群相比，融入最新容器技术的云原生分布式集群进一步深化了传统集群架构的技术特点。 容器作为实现微服务的最佳载体，能对服务器中的运行的任务一一进行更细致的监控和管理，这是传统集群架构中所不能实现的。 这种监控管理粒度上的突破使云原生分布式集群打破了传统集群架构的性能局限，具体可以体现在以下几点：
- 更强大的横向扩展能力满足海量数据处理需求: 新的监管模式让弹性扩容成为可能，TPS跃升至数万，可以轻松满足医联体等区域医疗机构每天数千万甚至上亿的数据处理和调用的请求。
- 精细化资源配置大幅提升资源利用率: 容器技术的轻量级特性能大幅解耦，提升应用程序的整体敏捷性和可维护性，扩展时也能根据不同应用的资源需求分别进行扩展，扩展粒度更细，整体资源利用率更高，轻松面对超高并发环境。
- 容器化分布式部署缩短响应时间： 通过容器化的分布式部署将不同进程独立存放到不同的容器中分别管理监控，更加适配微服务。 在事务处理时也能明确分工，对消息请求的响应时间更是缩短到毫秒级。
此外该方案还具有集团化、互联网化、区域化等大规模数据交换所需的微服务化支持，灰度发布，多人协同，中间件租赁化等优秀特性应用，这也是传统架构无法比拟的。
结语
集成平台中间件（例如集成引擎，ESB）特点和架构均需要医院根据自身情况谨慎选择，医院需要审视自身需求，先做到“知己”而立于不败之地，再深入了解集成平台中间件，做到“知彼”，才能在选择集成平台中间件和建设集成平台的道路上走得更稳、更远。
Odin文章评论：