医院集成平台故障率高，应从哪些方面进行排查？且看Odin如何应对

问题： 医院集成平台故障率高，应从哪些方面进行排查？ 

学员： 我们建设集成平台的项目失败了。 最初上线时是成功的，并且和HIS等业务系统连接到了一起，但之后平台不断发生故障，导致业务系统崩盘，我们慢慢地就把集成平台砍掉了，变回原来HIS、LIS、CIS之间用接口连接的方式。 我想请教各位老师，如果翻建的话，应注意哪些方面的问题，以降低集成平台的故障率？ 

薛万国 老师： 集成平台失败不一定是集成平台本身的问题。 对于集成平台我们既不能迷信，也不能轻易否定，要就事论事，具体分析。 今天的课程已经把集成的过程从业务交互开始都分析了一遍，支持的业务模式也都捋过了。 集成平台毕竟是个成熟产品，不管是哪家的产品，都不至于本身存在很多问题。 是不是我们在集成的实施中，前期设计和测试没有做到位？ 该约定的格式、语义是不是都约定清楚了？ 

不了解出现问题的具体细节。 可能要跟厂商专家再沟通一下，集成平台也是需要开发的，不是即插即用的，开发中甚至要写脚本，不仅仅是做好配置就行了。 脚本有错误可能导致队列拥堵，进而带来更多问题，这些问题都是在实施过程中要去解决的。 产品平台本身是一个层次，实施又是另外一个层次。 实施可以理解为二次开发，这方面的问题要关注一下。 

肖识战老师： 集成平台作为服务总线来讲的话，核心是在业务系统之间通过ESB总线来进行数据之间的接口交互。 它不存储数据，只是作为系统中间的缓存。 出现问题一般有以下几个原因： 

首先，产品本身的并发能力可能不够，没有充足的横向扩展能力。 如果业务体量大且快速增长时，需要进行足够的扩容。 如果某些业务系统在调用时出现了变慢的情况，这可能就是薛万国老师讲到的阻塞问题，这时系统会形成一个队列，如果产品没有缓冲机制，很快就会把现有的并发能力消耗完。 这也是产品本身的问题。 

其次，集成平台刚上线时运行是好的，一段时间后变得不好了，那可能是自身的管理数据库在面对数据增长时出现了瓶颈。 这时还是需要厂商去排查问题，比如看看本身管理数据库的数据库连接是不是变慢了？ 连接池是不是变满了？ 

总的来讲，要考虑几个主要因素： 第一，是不是业务量上升导致的？ 是否要做横向扩展、扩容？ 第二，对产品本身而言要去检查日志，数据库、连接池等有没有问题？ 第三，要去检查具体的调用量，以及调用接口，看看是不是调用方的问题拖慢了整个系统？ 我大概想到可以从这几点来排查。 

（上述内容来源于第二期培训班第4单元“医院信息系统架构治理”课程答疑环节，HIT专家网整理，未经发言者本人审核确认） 

Odin如何应对上述问题和产品需求？  

上述问答中提到的前期测试设计、队列拥堵、横向扩展能力、对日志，数据库，连接池的排查等问题都是平时集成平台建设中遇到的常见问题，那Odin引擎又是如何应对上述问题的？ 

具备多种测试工具和先进测试环境支持前期测试设计流程  

Odin引擎一体化集群方案实现双环境隔离的DevOps式生产/开发，开发/测试/审核/管理人员可实现精细化的权限分配，不仅支持医院进行前期的测试设计，还能引导医院形成一套规范化的管理流程； 引擎具备单组件测试、集成测试等工具，提供HTTP、SOAP、HL7等协议的用例管理。 

具备队列机制、重试机制以及熔断机制等多种高可用方式 

Odin引擎中具备消息队列缓冲和重试机制,并且在涉及到HTTP、SOAP等服务时可实现服务请求熔断，当请求异常超过设定阙值时，可以自动熔断避免“雪崩效应”，实施管理人员就能够在重要问题发生之前发现项目中性能不佳的节点或可能出现问题的终端或节点，快速排除故障。 

一体化集群架构实现动态横向扩展 

Odin引擎一体化集群架构将服务分布到多台服务器上同时运行，并可以进行动态扩展。 即使某个服务器出现故障，也能由其他服务器无缝进行业务接管，辅以集群架构带来系统整体运行能力的提升和负载均衡提供的高效合理的动态任务分配机制。 既保证了集成平台能充分利用硬件资源，又在高并发、高数据吞吐量的环境下达到高可用。 

提供全局状态仪表盘以及消息跟踪日志 

Odin引擎提供了一个全局状态浏览的仪表盘，以及完整消息处理流程的图形和树形双视角跟踪日志，在查看消息处理情况时，就能快速定位到相关的处理节点，系统调试，维护更直观方便。 同时日志页面可以访问和下载系统日志，实施人员和管理人员就能及时快速发现问题，解决问题。