基于微服务的车联网车辆数据采集与分发系统
发布时间：2020-06-05 20:43
【摘要】：车联网业务除传统的车载信息服务,比如安全保障、远程控制和语音导航等功能,还包括不断创新的服务,比如车队管理、驾驶行为分析、车辆鉴定评估等基于大数据分析的业务。车辆数据的采集与分发是所有这些业务的基石。随着车辆日益增多,需要采集的车辆数据的种类不断增加,车辆数据以亿级数量增加,亟待解决车辆数据采集与存储的性能、按业务服务类型管理采集及分发任务等问题。针对上述问题,本文以国内占领先地位的某车联网信息服务公司的实际项目为背景,在对微服务架构、微服务监控、Kafka消息中间件等相关技术进行分析研究的基础上,设计并实现了一个基于微服务的车辆数据采集与分发系统(以下简称VDCDS系统)。该系统的核心功能包括基于Kafka的车辆数据采集及分发、基于Cassandra的车辆数据存储、基于Spring Cloud Sleuth的任务服务监测等。测试情况表明,该系统是可行和有效的。本文的工作要点如下:1)基于Kafka的车辆数据采集与分发。车联网的车辆数据采集需支持数以千计的数据类型和诸如SOAP、REST、JMS等多种传输协议,采集后的车辆数据需根据业务类型分发给多个下游业务系统。本文提出了一种基于微服务的车辆数据采集与分发任务管理方案,采用Spring Cloud和Kafka框架实现了该方案。测试情况表明,VDCDS系统能够支持百万车辆每秒10万条近50MB车辆数据的采集。2)基于Cassandra的车辆数据存储。车联网的车辆数据存储需支持百万活跃车辆早晚高峰时高并发量的数据上传和以亿级增加的车辆数据数量,支持按照车辆、时间和业务类型的秒级数据查询。本文设计并实现了一个基于Cassandra的分布式车辆数据存储模块。测试情况表明,VDCDS系统可支持每秒10万级的混合读写场景,写入和读取的延迟99.9%情况下都在300毫秒以内。3)基于Spring Cloud Sleuth的服务监测。车辆数据采集、分发和存储服务需支持高可用,需监测服务请求的生命周期时长。本文采用Spring Cloud Sleuth和Zipkin等开源框架设计并实现了服务监测功能。测试情况表明,当服务监测的采样率设置为0.1时,服务的吞吐量约降低0.5%,响应的延迟约增加1%。VDCDS系统可应用在所有需要使用车辆数据的车联网业务中。例如支持车队管理的历史轨迹等基于车辆位置数据的服务;支持驾驶行为分析等基于车辆点/熄火和速度数据的服务;支持车辆鉴定和评估等基于车辆故障诊断和碰撞数据的服务。VDCDS系统的设计和构建能够增强车联网平台各个系统内聚性的同时,保持各个系统之间的松散耦合,从而可以降低各个系统开展新业务功能及维护的成本,增强整个车联网平台的健壮性和可用性。
【图文】：
图 2-1 单体架构与微服务架构Figure 2-1 Monolithic architecture and Microservices architecture例如，系统由订单管理服务，用户管理服务组成等。服务之间通信使用同步的HTTP/REST 协议，或者使用异步的 AMQP 协议。每个服务可以独立的开发和部署。每个服务拥有自己的数据库，从而和其他的服务解耦。数据的一致性可以使用数据复制机制或者服务间的事件来维护。使用上述架构解决方案有如下优点：每个服务相对来说代码规模小，易于开发人员理解。集成开发速度较快，利于开发人员提高生产率，部署和启动速度快，利于维护和测试，以及加快部署的频率。服务之间相互较为独立，利于单个服务的升级。每个小组可以负责单个服务，利于开发团队的扩充。开发小组可以对服务的开发，部署和扩展做出独立决策，从而利于开发团队的组织和协作。利于错误隔离，比如某个服务有严重的内存泄漏，只有那个服务会受到影响，其他服务可以正常处理请求。而在单体架构中，单个服务组件有可能拖垮整个系统。服务可以独立开发和部署。消除了对特定技术栈的长期捆绑和依赖。
基于微服务的车联网车辆数据采集与分发系统单体系统分解为多个服务，每个服务需要隔离，需要使用单独的应用服务器实例，其消耗的硬件和软件资源必然会增加。何时选择何种架构是需要慎重考量的。当开发系统的早期版本时，使用单体架构通常不会面临很多问题，此时如果使用需要精细的分布式架构则会拖慢开发进度。对于初创公司，或者急需开展新业务的时候，单体架构就较为合理，选择分割服务即微服务架构会使迭代速度变慢，对业务模型的进化产生不良影响，有可能得不偿失。如果采用单体架构，业务规模增长后，需要使用功能分解来扩展系统时，软件组件之间模糊并且错综复杂的依赖关系，使得把单体架构转变为一系列服务的困难就大大增加。2.1.2 基础设施服务微服务架构中业务服务通常依赖基础设施服务，来完成所需要的集中化或自动化工作[22]。如图 2-2 所示。
【学位授予单位】：上海交通大学
【学位级别】：硕士
【学位授予年份】：2018
【分类号】：U495;TP274.2
【图文】：
图 2-1 单体架构与微服务架构Figure 2-1 Monolithic architecture and Microservices architecture例如，系统由订单管理服务，用户管理服务组成等。服务之间通信使用同步的HTTP/REST 协议，或者使用异步的 AMQP 协议。每个服务可以独立的开发和部署。每个服务拥有自己的数据库，从而和其他的服务解耦。数据的一致性可以使用数据复制机制或者服务间的事件来维护。使用上述架构解决方案有如下优点：每个服务相对来说代码规模小，易于开发人员理解。集成开发速度较快，利于开发人员提高生产率，部署和启动速度快，利于维护和测试，以及加快部署的频率。服务之间相互较为独立，利于单个服务的升级。每个小组可以负责单个服务，利于开发团队的扩充。开发小组可以对服务的开发，部署和扩展做出独立决策，从而利于开发团队的组织和协作。利于错误隔离，比如某个服务有严重的内存泄漏，只有那个服务会受到影响，其他服务可以正常处理请求。而在单体架构中，单个服务组件有可能拖垮整个系统。服务可以独立开发和部署。消除了对特定技术栈的长期捆绑和依赖。
基于微服务的车联网车辆数据采集与分发系统单体系统分解为多个服务，每个服务需要隔离，需要使用单独的应用服务器实例，其消耗的硬件和软件资源必然会增加。何时选择何种架构是需要慎重考量的。当开发系统的早期版本时，使用单体架构通常不会面临很多问题，此时如果使用需要精细的分布式架构则会拖慢开发进度。对于初创公司，或者急需开展新业务的时候，单体架构就较为合理，选择分割服务即微服务架构会使迭代速度变慢，对业务模型的进化产生不良影响，有可能得不偿失。如果采用单体架构，业务规模增长后，需要使用功能分解来扩展系统时，软件组件之间模糊并且错综复杂的依赖关系，使得把单体架构转变为一系列服务的困难就大大增加。2.1.2 基础设施服务微服务架构中业务服务通常依赖基础设施服务，来完成所需要的集中化或自动化工作[22]。如图 2-2 所示。
【学位授予单位】：上海交通大学
【学位级别】：硕士
【学位授予年份】：2018
【分类号】：U495;TP274.2
【相似文献】
相关期刊论文 前10条
1 薛宁;;财务数据采集的统一处理框架设计与应用[J];审计月刊;2019年08期
2 阳泽;韩睿婷;林晓婷;;教育实证研究中数据采集的基本规范、现实困境及其改进[J];教育测量与评价;2019年08期
3 管宇e，
本文编号：2698588
本文链接：https://www.wllwen.com/kejilunwen/jiaotonggongchenglunwen/2698588.html
