一种基于微服务架构的车联网大数据分析系统

前言

本发明旨在提供一套通用的技术方案,将微服务的基础设施架构与大数据分析系统有机结合起来,集大数据采集、计算存储、检索分析能力于一体,可广泛应用于物(车)联网、商务智能(BI)大屏展示等应用。本发明申请于2022年3月4日,目前已进入实质审查阶段。特此公开,以方便技术存档和交流之用。

摘要

一种基于微服务架构的车联网大数据分析系统,使用微服务架构的分布式服务治理平台,对车端上报的数据进行采集、转换计算存储、检索分析并进行页面展示。整个数据流使用分布式服务治理的基础设施进行统一的配置管理和服务监控,根据需要对微服务弹性扩容;使用消息中间件对数据采集服务和转换计算存储服务进行模块解耦,提高了数据流的吞吐量;转换计算存储服务根据车辆数据不同的业务特点将数据写入缓存、关系数据库或全文检索服务器;通过对写入Elasticsearch全文检索服务器的海量数据按照数据采集时间进行切片,从而完成车联网大数据的存储和快速查询统计,使得本方案具备扩展性好、易于监控、便于管理、吞吐量大、查询迅速的特点。

技术领域

本发明涉及的是车联网和大数据领域 ,特别涉及一种基于微服务架构的车联网大数据分析系统。

背景技术

随着互联网信息技术的发展,微服务架构已成为取代SOA架构的企业级流行架构,它可以将大规模的软件系统按照功能模块进行拆分,每个模块高内聚低耦合,模块与模块之间通过REST风格的协议进行数据通信。每个微服务的模块可以独立开发维护和部署而不影响其他模块单元,微服务架构拥有分布式服务治理的一整套方案对服务的状态和配置进行统一的管理。伴随着智慧交通和自动驾驶技术的不断发展,车联网系统在提升车辆智能驾驶水平和社会交通的智能化管理方面具有着越来越重要的作用。然而,车联网系统也存在数据接入实时性不高、数据量较大、分析效率低下等瓶颈问题需要解决。传统的车联网系统数据采集、转换、存储、计算、分析的各个环节往往是独立发布和运行的,每个环节各自为政、形成信息孤岛,没有一个全局统一的服务治理、监控、配置的方案,导致整个数据流的处理效率十分低下,而且不易管控。

发明内容

鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于微服务架构的车联网大数据分析系统。为了解决上述技术问题,本申请实施例公开了如下技术方案:一种基于微服务架构的车联网大数据分析系统,包括:服务注册中心、配置管理中心、服务网关、服务监控中心、负载均衡器和断路器,其中,服务注册中心,用于负责微服务的线发布、下线注销和微服务存活状态的心跳检测;配置管理中心,用于集中保存所有微服务的配置参数,发布并动态刷新最新的配置到微服务实例中生效;服务网关,用于负责各个微服务模块的集中路由转发,将前端请求从网关路由到对应的微服务中完成服务调用,同时服务网关还需要完成对各个微服务的鉴权,只有通过鉴权服务调用才能成功;服务监控中心,用于实时监听服务的调用链路,可视化展示服务的健康状况和调用频率,并能展示服务之间的依赖关系;负载均衡器,用于在多个微服务提供方中选择一个服务进行调用,防止请求始终调用某一个服务引发服务宕机,当调用服务超时时,会自动触发重试机制发起新的调用;断路器,用于服务调用失败时,达到超时时间自动将服务调用快速断开,防止调用长时间无法返回引起连锁反应导致大量的网络堵塞。进一步地,该系统包含的微服务包括车辆数据采集微服务,数据转换、计算、存储微服务和数据检索与分析微服务。进一步地,该系统的车辆数据采集微服务,用于通过MQTT协议接入车端实时上报的数据,封装成json格式后投递到kafka消息队列,以供后续服务使用。进一步地,该系统的数据转换、计算、存储微服务,用于利用从消息代理消费车端采集到的数据,进行数据转换或计算,并将处理完成后的数据批量写入缓存数据库、关系数据库或全文检索服务器。进一步地,该系统的数据检索与分析微服务,用于对保存在缓存数据库、关系数据库和全文检索服务器的数据进行查询统计,缓存数据库可提供最新的实时状态数据查询、关系数据库可提供数据量较小结构化查询,对于全文本字段检索、经纬度检索、数据量较大的查询统计由全文检索服务器提供。进一步地,可使用微服务的弹性扩容机制对车辆数据采集、存储写入的吞吐量进行动态调节,使用微服务的集中式配置管理对整个数据流做统一的配置和动态刷新,使用微服务的服务监控机制对数据流中各个服务的健康状态进行实时监控,提高服务的容错性和高可用性。进一步地,车辆数据采集微服务和数据转换、计算、存储微服务之间通过消息代理进行解耦,解决数据采集速度与存储写入速度差距较大的矛盾,使数据采集和数据存储微服务异步处理数据,提高了整个数据流的处理效率和吞吐量。进一步地,缓存数据库用于保存数据量不大但读写频率高、实时性要求高的数据;关系数据库用于保存数据量适中的普通业务数据;全文检索服务器用于保存数据量较大并且会随时间持续增长的数据,微服务在存储数据时,要根据不同的业务特点写入不同的存储介质。进一步地,写入全文检索服务器索引的数据,需要根据数据采集时间分发到不同的索引中,每个索引只保存一段时间内的数据,从而完成对索引容量的线性扩展,保存持续增长的车辆大数据。本发明实施例提供的上述技术方案的有益效果至少包括:本发明公开的一种基于微服务架构的车联网大数据分析系统,包括:服务注册中心、配置管理中心、服务网关、服务监控中心、负载均衡器和断路器,其中,服务注册中心,用于负责微服务的上线发布、下线注销和微服务存活状态的心跳检测;配置管理中心,用于集中保存所有微服务的配置参数,发布并动态刷新最新的配置到微服务实例中生效;服务网关,用于负责各个微服务模块的集中路由转发,将前端请求从网关路由到对应的微服务中完成服务调用,同时服务网关还需要完成对各个微服务的鉴权,只有通过鉴权服务调用才能成功;服务监控中心,用于实时监听服务的调用链路,可视化展示服务的健康状况和调用频率,并能展示服务之间的依赖关系;负载均衡器,用于在多个微服务提供方中选择一个服务进行调用,防止请求始终调用某一个服务引发服务宕机,当调用服务超时时,会自动触发重试机制发起新的调用;断路器,用于服务调用失败时,达到超时时间自动将服务调用快速断开,防止调用长时间无法返回引起连锁反应导致大量的网络堵塞。本发明提供的车联网技术方案与现有技术相比,具有以下优点:1.把车辆数据的采集、转换计算与存储、分析作为一个统一的整体挂接到微服务架构之上,进行统一的配置管理、监控,提升了数据流的处理效率和可靠性;2.车端数据采集以后,经过了转换和计算,按业务用途将数据写入不同的存储介质:对于读写频繁、需要实时查询的业务数据,需要写入到redis缓存中;对于数据量不是太大的常规业务数据,则直接写入关系数据库进行管理;对于数据量很大并且随时间线性增长的数据,则按照采集时间分发到不同的Elasticsearch的索引中,查询时可选定多个索引作为检索范围;3.利用微服务弹性伸缩容易和服务容错性好的特点,方便添加或减少服务实例,对数据流的吞吐量可以按照需要灵活控制;4.消息中间件kafka的使用可以对数据采集服务和数据存储服务进行解耦,全文检索服务器的使用可以大大加快查询统计的性能。

下面通过附图和实施例,对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:

图1为本发明实施例1中,一种基于微服务架构的车联网大数据分析系统的架构图和数据流向图;

图2为本发明实施例1中,将数据按业务类型的不同写入不同的存储介质示意图;

图3为本发明实施例1中,将车辆轨迹数据按月份写入不同的Elasticsearch索引示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。为了解决现有技术中存在的问题,本发明实施例提供一种基于微服务架构的车联网大数据分析系统。实施例1本实施例公开了一种基于微服务架构的车联网大数据分析系统,如图1,包括:服务注册中心、配置管理中心、服务网关、服务监控中心、负载均衡器和断路器,其中,服务注册中心,用于负责微服务的上线发布、下线注销和微服务存活状态的心跳检测;配置管理中心,用于集中保存所有微服务的配置参数,发布并动态刷新最新的配置到微服务实例中生效;服务网关,用于负责各个微服务模块的集中路由转发,将前端请求从网关路由到对应的微服务中完成服务调用,同时服务网关还需要完成对各个微服务的鉴权,只有通过鉴权服务调用才能成功;服务监控中心,用于实时监听服务的调用链路,可视化展示服务的健康状况和调用频率,并能展示服务之间的依赖关系;负载均衡器,用于在多个微服务提供方中选择一个服务进行调用,防止请求始终调用某一个服务引发服务宕机,当调用服务超时时,会自动触发重试机制发起新的调用;断路器,用于服务调用失败时,达到超时时间自动将服务调用快速断开,防止调用长时间无法返回引起连锁反应导致大量的网络堵塞。

具体的,服务注册和配置中心采用Nacos、服务监控中心采用Zipkin和服务网关采用Spring cloud gateway,微服务负载均衡器使用ribbon,断路器使用sentinel。服务网关的集群需要用Nginx做负载均衡器,前端展示页面放在Nginx中,将Http请求分发到后台的服务网关集群上,然后去调用后端的各个微服务。

在本实施例中,该系统包含的微服务包括车辆数据采集微服务,数据转换、计算、存储微服务和数据检索与分析微服务。具体的,数据采集微服务会消费MQTT中车端实时上报的数据消息,取出后使用json格式将数据投递到kafka。根据车端数据的不同业务类型发送到kafka不同的topic中,以便后续进行区分处理。后台日志会实时记录当前采集的数据内容,以便采集出问题时可以从日志定位问题。在本实施例中,该系统的数据转换、计算、存储微服务,用于利用从消息代理消费车端采集到的数据,进行数据转换或计算,并将处理完成后的数据批量写入缓存数据库、关系数据库或全文检索服务器。使用转换计算与存储微服务以前,需要在配置中心配置kafka的地址和主题列表以及存储的内存数据库redis、关系数据库mysql和全文检索服务器Elasticsearch的地址。转换计算与存储微服务包含很多kafka的消费者,它会将各个topic中的kafka实时数据源源不断地取出来按照实际需要进行数据清洗、转换和计算,转换和计算完毕以后按照数据的类型确定数据应当写入的存储介质,然后将数据写入。图2展示了不同的业务数据写入不同储存介质的例子,例如车辆状态数据可能随时会发生变化,意味着这些数据需要频繁读写,因此将它们存放在redis中保存用于反映车辆最新的状态信息;车辆的里程统计数据需要按照时间周期每日、每月统计一次,数据量也不大,这些计算结果直接写入关系数据库供业务端查询;车辆轨迹数据随时间线性增长,数据量很大,这里将每个月产生的轨迹数据保存在一个单独的索引中,写入时,根据轨迹数据的采集时间写入对应月份的索引,搜索时则可将全部轨迹索引作为搜索范围,图3展示了这个过程,它使用了一种平滑扩容的机制来存储索引中线性增长的数据。在本实施例中,该系统的数据检索与分析微服务,用于对保存在缓存数据库、关系数据库和全文检索服务器的数据进行查询统计,缓存数据库可提供最新的实时状态数据查询、关系数据库可提供数据量较小结构化查询,对于全文本字段检索、经纬度检索、数据量较大的查询统计由全文检索服务器提供。具体的,数据检索和分析微服务根据数据库redis、mysql和Elasticsearch中保存的数据提供查询统计的服务,对于数据量较小的查询较快的表,可以直接读取mysql做查询;对于数据量很大的统计分析,需要读取Elasticsearch的索引发布检索和统计分析服务,最终的查询结果在数据分析大屏页面上进行展示。

在一些优选实施例中,缓存数据库用于保存数据量不大但读写频率高、实时性要求高的数据;关系数据库用于保存数据量适中的普通业务数据;全文检索服务器用于保存数据量较大并且会随时间持续增长的数据,微服务在存储数据时,要根据不同的业务特点写入不同的存储介质。写入全文检索服务器索引的数据,需要根据数据采集时间分发到不同的索引中,每个索引只保存一段时间内的数据,从而完成对索引容量的线性扩展,保存持续增长的车辆大数据。

在本实施例中,可使用微服务的弹性扩容机制对车辆数据采集、存储写入的吞吐量进行动态调节,使用微服务的集中式配置管理对整个数据流做统一的配置和动态刷新,使用微服务的服务监控机制对数据流中各个服务的健康状态进行实时监控,提高服务的容错性和高可用性。车辆数据采集微服务和数据转换、计算、存储微服务之间通过消息代理进行解耦,解决数据采集速度与存储写入速度差距较大的矛盾,使数据采集和数据存储微服务异步处理数据,提高了整个数据流的处理效率和吞吐量。

本实施例公开的一种基于微服务架构的车联网大数据分析系统,包括:服务注册中心、配置管理中心、服务网关、服务监控中心、负载均衡器和断路器,其中,服务注册中心,用于负责微服务的上线发布、下线注销和微服务存活状态的心跳检测;配置管理中心,用于集中保存所有微服务的配置参数,发布并动态刷新最新的配置到微服务实例中生效;服务网关,用于负责各个微服务模块的集中路由转发,将前端请求从网关路由到对应的微服务中完成服务调用,同时服务网关还需要完成对各个微服务的鉴权,只有通过鉴权服务调用才能成功;服务监控中心,用于实时监听服务的调用链路,可视化展示服务的健康状况和调用频率,并能展示服务之间的依赖关系;负载均衡器,用于在多个微服务提供方中选择一个服务进行调用,防止请求始终调用某一个服务引发服务宕机,当调用服务超时时,会自动触发重试机制发起新的调用;断路器,用于服务调用失败时,达到超时时间自动将服务调用快速断开,防止调用长时间无法返回引起连锁反应导致大量的网络堵塞。本实施例提供的车联网技术方案与现有技术相比,具有以下优点:1.把车辆数据的采集、转换计算与存储、分析作为一个统一的整体挂接到微服务架构之上,进行统一的配置管理、监控,提升了数据流的处理效率和可靠性;2.车端数据采集以后,经过了转换和计算,按业务用途将数据写入不同的存储介质:对于读写频繁、需要实时查询的业务数据,需要写入到redis缓存中;对于数据量不是太大的常规业务数据,则直接写入关系数据库进行管理;对于数据量很大并且随时间线性增长的数据,则按照采集时间分发到不同的Elasticsearch的索引中,查询时可选定多个索引作为检索范围;3.利用微服务弹性伸缩容易和服务容错性好的特点,方便添加或减少服务实例,对数据流的吞吐量可以按照需要灵活控制;4.消息中间件kafka的使用可以对数据采集服务和数据存储服务进行解耦,全文检索服务器的使用可以大大加快查询统计的性能。

应该明白,公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好,应该理解,过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素,并且不是要限于所述的特定顺序或层次。

在上述的详细描述中,各种特征一起组合在单个的实施方案中,以简化本公开。不应该将这种公开方法解释为反映了这样的意图,即,所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反,如所附的权利要求书所反映的那样,本发明处于比所公开的单个实施方案的全部特征少的状态。因此,所附的权利要求书特此清楚地被并入详细描述中,其中每项权利要求独自作为本发明单独的优选实施方案。本领域技术人员还应当理解,结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性,上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件,取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用,以变通的方式实现所描述的功能,但是,这种实现决策不应解释为背离本公开的保护范围。结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然,处理器和存储介质也可以作为分立组件存在于用户终端中。对于软件实现,本申请中描述的技术可用执行本申请所述功能的模块(例如,过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内,也可以实现在处理器外,在后一种情况下,它经由各种手段以通信方式耦合到处理器,这些都是本领域中所公知的。上文的描述包括一个或多个实施例的举例。当然,为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的,但是本领域普通技术人员应该认识到,各个实施例可以做进一步的组合和排列。因此,本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外,就说明书或权利要求书中使用的术语“包含”,该词的涵盖方式类似于术语“包括”,就如同“包括,”在权利要求中用作衔接词所解释的那样。此外,使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。