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

Odin Editor, 21 二月, 2023
关键字

高性能、单机架构、传统集群、云原生集群、TPS

海量高并发请求毫秒级延迟, 三级医院中间件(集成引擎)性能不够怎么办? 

“系统好慢,想查个病人信息,鼠标指针一直在转,结果好久才能出来,耽误事。 ” 

“医院接入集成平台的系统越来越多,集成引擎往往力不从心,不堪重负,医院抱怨我们厂商,我们尝试各种方法但往往解决不了问题,最后只好将部分系统的数据集成通过集成引擎处理。 ” 

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

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

9000000÷10÷3600=250 

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

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

(9000000×80%)÷(10×3600×20%) =1000 

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

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


中间件(集成引擎)架构: 决定集成平台性能的关键 

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

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

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

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

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

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

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

  • 横向扩展: 传统集群和单机架构在性能上最核心的差别就在于可实现横向扩展,这也是目前实现高性能的最优解决方案。 不同于提升单机性能的垂直扩展,横向扩展使集成平台能增加服务器数量,大幅提升系统性能。 
  • 负载均衡: 光有服务器数量还不够,如果任务不能自动分配到具有空余资源的集群节点,仍然不能在高并发环境下处理海量数据。 因此需要负载均衡功能根据不同业务场景进行动态地任务分配,最大化利用集群中的计算节点,提升集成平台总体性能。 

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

传统集群架构的局限性 

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

云原生分布式集群: 着眼未来的前瞻性方案 

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

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

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

  • 更强大的横向扩展能力满足海量数据处理需求: 新的监管模式让线性扩容成为可能,TPS跃升至数万,可以轻松满足医联体等区域医疗机构每天数千万甚至上亿的数据处理和调用的请求。 
  • 精细化资源配置大幅提升资源利用率: 容器技术的轻量级特性能大幅解耦,提升应用程序的整体敏捷性和可维护性,扩展时也能根据不同应用的资源需求分别进行扩展,扩展粒度更细,整体资源利用率更高,轻松面对超高并发环境。 
  • 容器化分布式部署缩短响应时间: 通过容器化的分布式部署将不同进程独立存放到不同的容器中分别管理监控,更加适配微服务。 在事务处理时也能明确分工,对消息请求的响应时间更是缩短到毫秒级。  

【结语】 

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

Odin文章评论:

如您在使用此平台时遇到问题,可发送邮件至:customer.service@odin.co.nz 获得帮助