破解大型三级医院集成平台性能痛点

传统集成平台面对快速增长的业务需求常常出现性能瓶颈，也使上述常见的问题和抱怨成为了医院和HIT厂商对于集成平台性能的“灵魂拷问”。

据统计，三级医院每天要处理的消息总量都在百万量级。假设一家大型三甲医院每天需要处理900万消息请求，以每天10小时作为集成平台的核心工作时间，如果全部走平台的话，可得出中间件(集成引擎)平均每秒处理的数据为:

9,000,000/10/3600=250；

即中间件(集成引擎)平均TPS(每秒事务数)为250能满足日均900万量级的消息请求。

但考虑到医院的运行峰值对性能要求会更高，相对严谨一些则基于“二八原则”(二八原则：每天80%的请求数量集中在20%的时间段里，这20%的时间即为医院峰值)，估算出医院运行峰值时中间件(集成引擎)的极限TPS为：

(9,000,000×80%)/(10×3600×20%)=1000；

即使刨去消息头大小限制，医院消息在复杂场景下需要落盘储存或异步处理等影响因素，理想情况下日均900万消息处理数量级的医院理论上也需要中间件(集成引擎)极限TPS达到1000才能满足医院峰值时的稳定运行,这个性能是一般普通的单机架构中间件(集成引擎)难以达到的。因此现在很多医院只能将部分系统的数据集成通过中间件(集成引擎)处理。

那三级医院集成平台该如何面对海量高并发消息的毫秒级延迟需求？本文将从中间件(集成引擎)架构设计的角度，聊一下不同架构下的中间件(集成引擎)性能。

单机架构：单机性能存在瓶颈，垂直扩展提升有限

单机架构一般每秒能同步处理数百条消息，如果数据有顺序要求，不能并行处理，需要落盘储存，则在这部分业务场景中TPS仅有几十。

医院通常的解决办法是提升硬件配置 (如CPU从8核变成16核)。除此之外，中间件(集成引擎)还可以通过其它功能设计更好地提升单机性能：如内置的内存数据库、添加分布式缓存等设计，减少与外部I/O交互，提高数据获取速度。

但以上方法并不能解决单机架构的致命缺点—单机性能存在极限。因此，想进一步提升集成平台性能，就需要改变现有中间件(集成引擎)的单机架构模式。

传统集群架构：满足当下医院需求的方案

这里的传统集群架构是指在产品设计时根据医院平台的业务特点原生实现的集群架构，并非单机系统部署在多台虚拟机上形成的“集群”(其核心仍是单机架构)。

为什么说传统集群架构可以满足当下医院需求，因为它满足了实现高性能的两个重要条件：

通过集群架构实现横向扩展，并通过负载均衡实现合理的动态任务分配机制后，传统集群架构的集成平台TPS能达到数千。 

传统集群架构的局限性

然而，传统集群架构只能以服务器为单位进行横向扩展，很多情况下扩展的服务器中只有个别应用资源会被使用到，因此和下面即将提到的云原生集群方案相比资源利用率低很多。同时随着服务器的增加，对于集群节点管理和调度的难度也会大幅上升，对性能提升的幅度会越来越少。

云原生集群：着眼未来的前瞻性方案

除了传统集群，现在也有针对医联体和集团化医疗机构的基于K8s等容器化技术实现的云原生集群。云原生是未来医院业务快速变化背景下的必然技术趋势，而支撑起云原生集群的就是Kubernetes容器编排和以Docker为代表的容器技术。

任务进程监管粒度更细，突破传统集群局限

和传统集群相比，融入最新容器技术的云原生集群进一步深化了传统集群架构的技术特点。容器作为实现微服务的最佳载体，能对服务器中的运行的任务一一进行更细致的监控和管理，这是传统集群架构中所不能实现的。这种监控管理粒度上的突破使云原生集群打破了传统集群架构的性能局限，具体可以体现在以下三点：

医院集成平台建设是一个长期持续性的建设过程。医院选择集成平台时，应结合自身当下以及未来的需求，寻找有能力集成更多核心业务，承载更大交易量的高性能集成平台，为医院今后持续加强集成的广度和深度打好坚实基础。