中文
新闻中心
新闻中心 > 云上医疗提速建设，打造便利就医新生活
云上医疗提速建设，打造便利就医新生活
阶段一
阶段二
阶段三
集成平台的建设需求主要分为三个部分： 集成引擎实现消息的集成；esb实现服务协同；etl进行数据同步。
中间件的设计需求
消息的集成和转发都是通过消息中间件来实现，消息中间件的稳定性设计也成为了集成平台最核心的部分之一。中间件组件主要包含broker（消息服务器），producer（消息生产者），consumer（消息消费者）。
中间件平台设计从稳定性角度来看，分为主备和集群两种模式，针对高性能场景，中间件需支持集群模式，所以硬件平台的设计对于集群模式的支持将成为重要指标。
从扩展性的角度来说，中间件的核心其实就是一个消息队列，在做消息转发过程中，解耦了消息的处理过程，因此增大消息入队及处理的频率是很容易的，只需另外增加处理过程即可，不需要改变代码、不需要调节参数，便于分布式扩容。一般broker数量越多，集群吞吐率越高，所以集成平台对于扩展性的要求就显得尤为重要。尤其是针对高性能集成平台应用，分布式的it架构可以更好地适应其扩展性的设计考量。
应用稳定性的设计需求
如何解决消息转发不一致，业务中出现his和emr能通信，his和lis通信出问题等情况，将是考量集成平台应用稳定性的关键指标。
医疗行业软件方大多采用国外中间件，例如ensemble，orion，mq等，结合在软件系统过程中，不可控因素较多。服务宕机，组件不宕机而导致消息转发不一致的情况较为常见，比如100条消息，实际只转发了50条；那么对于中间件的监听过程也成为了稳定性设计很重要的考量指标。例如通过应用交付的方式重启队列，或者支持自定义消息转发条目的监听机制，比如每秒10次返回监听，保障整体应用的稳定性。
集成平台升级关系重大，如何降低风险、平滑稳定升级是考量集成平台应用稳定性的重要因素。
做完应用、数据和界面集成后，集成平台会成为医院整体业务和数据的访问入口，那么集成平台的调整或升级同样升级为重要的考量因素。
核心业务升级过程中平台经常会出现逐步升级的需求，即让一部分用户继续用版本a，一部分用户开始用版本b，如果版本b使用没有问题，那么逐步扩大范围，把所有用户都迁移到版本b上面来。通过灰度发布机制实现业务升级的平滑过渡会显得非常有意义，切分应用和数据库，升级过程中保证底层数据库一致性和应用系统的稳定，在初始灰度时就可以发现、调整问题，以保证其平滑升级。
微服务架构的设计需求
采用微服务架构技术、docker容器技术，设计与实现基于微服务架构的医疗集成平台方案。以患者、医嘱事件、医疗服务目录以及账务处理为例开发面向医院的统一应用平台，展现了微服务快速构建医疗应用、提高医疗集成开发水平及各部门协作效率的优势。通过微服务架构实现平台和应用的分层解耦合，并通过微服务建设，加强对平台层的自我把控能力，支撑应用层的可替换。
对外共享通用技术服务、通用业务服务和通用数据服务，为服务访问提供安全认证功能，加强对服务访问的管控。
微服务平台架构逐步应用在集成平台建设中，结合docker技术发挥出微服务的优势和运维工作的高效，可见it架构对于容器的需求、统一化的运维管理变得十分重要。
数据中台的设计需求
医院信息化系统的发展，形成了垂直领域的数据中心。如何打通这些数据，按统一的标准进行建设，以达到技术降本、应用提效、业务赋能的目标，是众多医院面临的问题。针对医疗行业，深信服推出超融合一体化凯发登录的解决方案，灵活满足新型集成平台综合性需求，一体化适配微服务架构、容器；另外灵活满足数据库、中间件高性能、高可靠，平台可扩展，数据可应用的全栈式设计方案，并在保障架构性能和稳定的同时，提供应用稳定性的定制化凯发登录的解决方案。
总体来看集成平台的设计，容器化、无状态服务、大数据等新技术、新概念的出现，依赖传统的虚拟化平台 共享存储架构来应对这些新事物时，在成本、性能、扩展性上并没有任何优势，共享存储对于这些应用本身没有太大的价值。在集成引擎中间件odin、ensemble、orion等都在适配分布式架构的今天，传统共享存储架构变得略显多余，全栈式超融合架构才是最佳实践。
联系凯发注册网站