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

程序员文章站 2022-04-15 19:20:15

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

系统设计架构图：

图示：关于技术选型，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就是内部非业务服务。

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

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