欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

【远程医疗】互联网医院 卫健委数据上报平台技术方案

程序员文章站 2022-07-06 12:31:38
说到数据上报,很多人第一印象是直接点对点的上报数据,优点是简单直接省事,但是缺点很明显,侵入性太强,业务中会掺杂很多非业务的事情。当然这里的简单省事是短暂的,如果业务以及开发完了,后面追加数据上报功能,再按照这个模式,将带来空前的压力,代码基本上要重新写、测试。这个任务量也许会很大,因为一时的省事为 ......

说到数据上报,很多人第一印象是直接点对点的上报数据,优点是简单直接省事,但是缺点很明显,侵入性太强,业务中会掺杂很多非业务的事情。当然这里的简单省事是短暂的,如果业务以及开发完了,后面追加数据上报功能,再按照这个模式,将带来空前的压力,代码基本上要重新写、测试。这个任务量也许会很大,因为一时的省事为以后埋下大坑,这个是做研发要极力避免的、不能容忍的。此时我们要做的事是如何解耦,将非业务性功能提取出来,做成一个统一的数据上报平台。因此我们就有了下文的技术方案。

系统设计架构图:

【远程医疗】互联网医院 卫健委数据上报平台技术方案

 

 

 图示:关于技术选型,a、b、c都是基于springcloud,数据存储我们选择elasticsearch,消息中间件使用kafka。

 

  上图的业务是将a服务的数据上报到d服务。按照一般的流程我们可以直接将a服务的数据直接发送到d服务,这样的好处是简单,但是缺点显而易见,侵入性、耦合性太强,这不是我们想要的。我们要将与业务无关的服务剥离出来,做成一个统一的数据上报中心也就是上图中的b服务,在这个服务中只做一件事,那就是业务数据上报,而此时的a服务只管专心的做业务,无需关心其它,二者各司其职,互不影响,做到真正的业务分离。

 

   此时b服务的上报数据从哪儿来,a服务直接发给b服务?很明显不是,如果这样做和a服务点对点发送到d服务有什么区别呢,反而增加了一个中间环节,增加了不稳定因素。那我们该怎么做?想一想,多个程序如何进行消息传递?此时我们会想到消息中间件这个很神奇的一个东西。网上搜索一大堆消息中间件,那么我们该如何选择呢?我们这里选择的是kafka,原因是我们这里的数据量大、生态环境非常好,实时数据处理比较好,而且我们之前已经在使用它了,在满足业务的情况下,没有必要再额外的维护一个中间件,我们要本着业务、经济的原则去技术选型,不要为了技术而技术。

 

【远程医疗】互联网医院 卫健委数据上报平台技术方案

 

 

在上报数据的时候我们还得考虑很多问题:

1.上报数据日志监控

我们这里的日志量很大,而且需要各种维度的日志分析这个功能,因此日志存储我们采用elasticsearch。

它是一个分布式搜索引擎,支持海量数据存储,检索查询。在这里使用它再适合不过。

 

2.数据丢失。比如服务d宕机、网络堵塞原因会导致上报数据丢失(在a、b服务正常的情况下),那么如何解决这个?由于我们做了日志监控,所以会很简单的解决这个问题,将上报异常的数据重新发送就好了。

 

使用场景:

本架构使用在互联网医院项目中,业务是卫健委要求医院上报在线看病患者产生的数据,且上报数据不允许丢失,如果对方平台无法使用,则要求补发丢失数据。

a对应医院在线看病服务,d对应卫健委数据接收服务。b、c就是内部非业务服务。

最后总结核心点,我们要将业务和非业务相关的东西剥离开来,各司其职,互不影响,这正符合现在流行的微服务理念。

 

推荐阅读:

【大厂】基于rabbitmq消息中心技术方案
【干货】一篇文章讲透数据挖掘
【干货】微服务设计的基础知识【对话老王】聊聊那数据
【轻松话题】闲话程序员
【划划重点】论大数据中主数据的重要性
【谈大数据】cdh6.x学习笔记(角色简介)