您的位置:402cc永利手机版 > 互联网动态 > 车联网上云最佳实践

车联网上云最佳实践

2019-10-02 07:57

痛点2:没有弹性扩容缩容能力,应对流量高峰代价高

当出现数据存储容量和访问量瓶颈时,DRDS 支持在线存储容量扩展,扩容无需应用改造,扩容进度支持可视化跟踪。

MongoDB集群:公司目前有3套MongoDB集群,主要用来存储车辆上报的原始数据,和解析后的车辆状态、点火、告警、轨迹等数据。采用的是副本集,通常由只是3个节点组成。其中一个是主节点,负责处理客户端请求,其余都是从节点,负责复制主节点上的数据。

分布式服务集群:

有2种方式快速构建应用运行环境:

Elasticsearch集群:ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。该架构中ES集群采用3个节点,这个3个节点都是候选主节点。这里我们主要用于轨迹查询,信息检索、日志系统等场景。

 为了解决大规模的车机上报而导致数据写入延迟问题我们改用云上IOT套件 HiTSDB;

2、 早晚出行高峰比较固定

我们对传统IDC应用架构进行分析之后,我们发现之前的系统架构存在一些不合理的地方导致了很多的痛点,为了解决这些痛点我们最终考虑上云。开始思考怎样利用云上产品来解决目前遇到的痛点。例如

代码管理:采用gitlab进行代码托管;

作者:云攻略小攻

2、应用架构

综合性能对比

首先大致梳理下车联网行业的特性有哪些:

 为了降低上云迁移复杂性,我们改用云上VPC虚拟专用网络,IP地址可以和原来保持不变;

第三方合作平台:是指通过调用第三方平台接口来完成为用户提供部分功能,例如保险服务,违章查询功能,停车位查找功能,4S店服务等功能。

数据库运维:采用阿里云数据管理DMS,解决数据库运维管理问题

我们公司应用刚上线的时候系统各方面的设计比较简单,横向扩展能力不强,随着业务爆发式增长,因为我们很多资源无法及时扩展,导致系统故障,用户体验降低。例如文件存储,刚开始的时候我们是自建的NFS文件存储,用于存放用户头像,驾驶证,朋友圈等图片文件。由于各方面原因当初没有投入足够的资源建设,导致一段时间之后存储就不够用,读写性能下降,用户访问延迟等等。最痛的一点是硬件设备的扩展周期长,从提出采购需求到最后的实施硬件扩展,往往需要5-10天甚至更长,因为这期间需要经历采购审批流程,物流发货,到货验收,机房上架等。

问题4:单机MySQL数据库遇到IO性能瓶颈和容量扩容瓶颈,如果业务和用户规模继续增长将面临单机数据库扩展困难。

车联网核心平台:主要包含应用层、支持层、物理层等功能,其中应用层包含功能有用户注册,用户登录,导航功能,车友功能,车辆检测功能,轨迹查询功能以及其他娱乐功能。这些是APP的核心功能。其次是支持层的功能,例如运营管理系统,用户管理系统,车辆管理系统等辅助运营和运维的系统和工具。

阿里云容器服务提供高性能可伸缩的容器应用管理服务,支持用 Docker 和 Kubernetes进行容器化应用的生命周期管理,提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务简化了容器管理集群的搭建工作,整合了阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器运行环境。阿里云容器服务可以提供一站式容器生命周期管理以及集群管理。更多关于阿里云容器管理介绍请详见文章附录第5.5小结。

数据展示:

 分库分表

Java环境:采用Centos7 JDK1.7 Tomcat7

统一配置:采用阿里云应用配置管理,传统IDC架构中我们的应用因为微服务架构的需要全部采用了的统一配置管理,将配置中心化管理,保存在zookeeper当中,通过一个web前端进行配置管理。应用通过本地客户端向服务端请求配置。这样做的好处是应用配置可以集中存放,统一配置,方便管理。但是我们的web配置管理中心提供的功能比较简单,甚至不具备权限管理,配置快照,备份和恢复等功能。在云上我们改用阿里云的应用配置管理ACM产品。云上应用配置管理是一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。基于该应用配置中心产品,可以在微服务、DevOps、大数据等场景下极大地减轻配置管理的工作量,增强配置管理的服务能力。阿里云ACM 是分布式系统的配置中心。通过提供配置变更、配置推送、历史版本管理、灰度发布、配置变更审计等配置管理工具,ACM 帮助集中管理所有应用环境中的配置,降低分布式系统中管理配置的成本,并降低因错误的配置变更带来可用性下降甚至发生故障的风险。更多关于阿里云应用配置管理ACM介绍请详见文章附录以及官方网站。

对于缓存最大痛点在于运维,经常出现因磁盘IO瓶颈导致的redis集群故障,以及因用户快速增长需要经常对Redis集群进行在线扩容等。而且Redis运维都是只能是手动运维,工作量大,且容易误操作。因Redis集群而导致的故障不计其数。当然也跟当时的应用强依赖相关,Redis集群故障就导致整个应用也挂了,这是应用系统设计的缺陷。

另外选择用堡垒机来替换原来的开源堡垒机,相比开源的产品,阿里云堡垒机多了一些审计合规,高效易用,多协议支持,追溯回放等功能。

在复杂的系统架构和海量的服务器环境中,需要合适的运维管控软件来提升运维的工作效率。

问题3:车联网行业是典型的大数据行业,有大量的大数据分析应用场景需求,但是自建大数据平台成本高,维护困难,大数据人才不好招。

监控:采用的是Zabbix开源监控系统;

阿里云日志服务是针对日志类数据的一站式服务,在阿里巴巴集团经历大量大数据场景锤炼而成。无需开发就能快捷完成日志数据采集、消费、投递以及查询分析等功能,提升运维、运营效率,建立 DT 时代海量日志处理能力。具有全托管,实时性强,生态丰富,完整API等特点。更多关于阿里云日志服务介绍请详见文章附录第5.7小结。

Node.js环境:采用Centos7 Node8.9.3

DRDS 提供独有分布式数据库运维指令集,如 SHOW SLOW、TRACE、SHOW NODE 等指令,有助于快速发现和定位问题。

负载均衡集群:

持续集成:传统应用升级发布主要靠的人肉升级或者脚本升级,后来尝试过利用开源的Jenkins docker方式构建一个简单的应用发布系统,我们希望到云上可以继续保持这种发布方式,所以改用云上CodePipeline,阿里云CodePipeline是一款提供持续集成/持续交付能力,并完全兼容Jenkins的能力和使用习惯的SAAS化产品。它无需运维,开箱即用,全量兼容Jenkins插件,支持ECS,容器服务持续部署,快速上手。更多关于codepipeline介绍请详见文章附录第5.9小结。

1.2 应用架构介绍

1.7流计算集群:

消息队列集群:

 数据库账号权限体系

首先通过车载智能终端设备收集汽车相关行驶数据,然后通过物联网卡(即sim卡)上报到平台,平台经过协议解析服务将数据转换成可读的数据并进行存储下来,并且需要把原始数据也保存一份。

1.11运维管控集群:

现在国家法定节假日期间,由于高速公路在此期间免费的政策,导致越来越多的人们开始选择驾车出行或出游,所以每当节假日来临时必然导致车联网用户暴增,这个洪峰流量来临的时间和流量是不确定的。如何能准确做好每次节假日出行高峰预测是个问题。

www.402.com ,![20180831141508]()

如今汽车技术更新越来越快,汽车厂商越来越多,厂商发布的新车型的频率也越来越高,车联网企业对这汽车行业的新技术必须保持非常高度关注,必须加快版本迭代,提高研发效率才能及时应对汽车市场的变化,才能在第一时间解决和满足市场和用户的需求。

www.402.com 1

作者:云攻略小攻

DRDS 实例可以通过改变资源数量实现服务能力的弹性扩展。

缓存集群采用的Redis3.0 Cluster集群模式,该架构中有10套Redis缓存集群,每个集群的内存从60G-300G不等。缓存服务器是典型的内存型主机,对CPU开销不大,如果要做持久化,对磁盘IO要求较高,磁盘建议使用SSD。

阿里云大数据计算服务(MaxCompute,原名 ODPS)是一种快速、完全托管的 GB/TB/PB 级数据仓库解决方案。MaxCompute 提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决海量数据计算问题,有效降低企业成本,并保障数据安全。

NFS分布式文件系统:

1) 购买ECS服务器后安装操作系统,然后手动部署应用环境,最后将应用环境构建成新的系统镜像。

因为车联网行业的一个特点就是早晚高峰和节假日期间车辆在线率飙升,然后进入平稳期。一天24小时有6个小时是早晚高峰,其余18个小时是正常流量,通常高峰期流量是平常的3-5倍。传统IDC通常需要几天时间才能完成一次线上扩容,根本不可能应对突发性的流量暴涨的情况。我们为了保障系统稳定性以及保障用户体验,只能是投入比平时多几倍的资源,整体资源利用率不到30%,产生巨大资源浪费。

云上流计算采用阿里云的流计算服务,相较于其他流计算产品,阿里云流计算提供一些极具竞争力的产品优势,用户可以充分利用阿里云流计算提供的产品优势,方便快捷的解决自身业务实时化大数据分析的问题。产品优势,例如强大的实时处理能力、托管的实时计算服务、良好的流式开发体验、低廉的人力和集群成本。更多关于阿里云流计算介绍请详见文章附录第6.1小结。

分布式服务集群,采用Dubbo ZooKeeper搭建的分布式服务框架。其中zookeeper的服务器需要保持奇数目的是便于选举。

以前的老万网被阿里云收购之后,变更为阿里云域名服务,它集域名注册、交易、解析、监控和保护为一体的综合域名管理平台。更多关于域名服务介绍请详见文章附录第5.6小结。

虽然当前的运维体系还算比较规范,但是大多数运维工具都是开源的产品,只能满足部分功能需求。随着运维管控需求的增加,需要的熟悉的开源产品也越多。运维管理不够统一,运维人员通常需要熟悉和掌握很多运维系统,导致新手很难入手。

2) 购买ECS云服务器后直接选择云市场的已经封装好的应用环境镜像即可。

二、传统IDC架构介绍及技术详解

 分布式的实时文件存储,每个字段都被索引并可被搜索

www.402.com 2

 为了解决存储性能瓶颈以及用户访问体验问题,我们改用云上对象存储OSS服务 CDN;

俗话说知己知彼百战不殆,我们要上云首先要充分了解自己业务和应用架构。然后在充分了解云上产品的特性,看看哪些产品可以直接被我们使用,哪些是需要我们的应用或架构做出调整的。下面我们来分析下智能车联网平台的相关架构。

分布式服务集群,延用Dubbo ZooKeeper分布式服务框架。采用7台8核16G SSD磁盘200G ecs.c5.2xlarge规格ECS实例用于构建zookeeper集群。Zookeeper集群节点必须是奇数,因为在zookeeper集群中只要有超过一半的机器是正常工作的,那么整个集群对外就是可用的。

www.402.com 3

2.2 文件系统迁移策略

用户通过下载并安装手机APP,注册登录App后用户可以在APP 上查看自己车辆的位置,轨迹查询,油耗,车辆故障以及交友,娱乐等功能。

本文为云栖社区原创内容,未经允许不得转载。返回搜狐,查看更多

将解析后的数据放到消息队列中,后端的各种应用服务开始处理不同的数据,例如轨迹服务会去消息队列中取出轨迹数据进行分析和处理。从而生成用户的行驶轨迹等功能;再例如故障检测服务,通过订阅消息队列中有关汽车传感器数值进行分析和判断该车辆是否存在故障。

文件系统迁移改造方案请看2.2章节。

1.3 传统IDC架构痛点

使用CDN后的http请求处理流程如下图

1.1 数据流介绍

 为了解决日常以及节假日流量高峰的问题,我们改用云上弹性伸缩服务 按量付费,以最低的成本完美解决日常及节假日流量高峰;

运维管控集群:

www.402.com 4

一、车联网行业特性讲解

MySQL集群:采用的是阿里云数据库RDS之MySQL版

Dubbo也是比较流行的JAVA应用的分布式服务框架,它是阿里开源的分布式服务框架。但是在使用过程中也发现由于没有一个比较好用的Dubbo监控软件,导致应用出现故障时排查故障很费力,如果有一套比较强大的链路跟踪监控系统对于那分布式应用来说是锦上添花了。

1.5缓存集群:

痛点5:基础设施可靠性差,故障频发

根据当前业务量来看五百万用户,最高峰期间并发最大连接为50万,推荐使用

但是自建NFS分布式文件系统由于公司投入硬件设备有限,导致本身的扩展性是相当差的,而且需要停机相当影响业务。访问速度因客户端增加而变慢。这是个很影响用户体验的痛点,必须改造。

成本对比

配置管理系统:提供应用的集中式配置管理,是基于java开发的配置管理。

性能保障型规格5(slb.s3.medium)最大连接数50w,每秒新建连接数5w,QPS支持3w。完全满足当下的企业需求,如果后续业务和用户规模继续增长,仍然可以在线扩容到更高级别规格的SLB实例。如果未来达到千万级用户规模,需要大于100万规格的实例可以联系阿里云客户经理开通。

数据处理:

应用服务器采用阿里云ECS云服务器,来部署应用环境。之前提到运行环境主要为JAVA环境和PHP环境,还有少部分Node.js环境。

痛点3:运维工具零散、运维工作复杂繁琐

DRDS 支持对核心资源指标和数据库实例指标的实时监控和报警,如实例 CPU、网络 IO、活跃线程等,帮助实时发现资源和性能瓶颈。

痛点4: 硬件设备采购周期长,成本高,扩展性差

阿里云数据管理支持MySQL、SQL Server、PostgreSQL、MongoDB、Redis等关系型数据库和NoSQL的数据库管理,同时还支持Linux服务器管理。它是一种集数据管理、结构管理、访问安全、BI图表、数据趋势、数据轨迹、性能与优化和服务器管理于一体的数据管理服务。更多关于阿里云数据管理DMS介绍请详见文章附录第5.8小结。

随着公司快速发展和用户规模的增长的同时,很容易被别有用心的人盯上,记得有一天下午3点左右,突然遭受到大量DDOS攻击,我们的防火墙一下就被打垮了,系统瞬间就瘫痪了,没有办法,什么都做不了,防火墙已经跪了,登不上去了,一直持续几个小时,业务也瘫痪了几个小时,一点办法没有。我们的安全防护能力真的很弱,也跟成本有关,高端的防火墙买不起,还有运营商的带宽也很贵。

 为了解决我们自建IDC底层基础设施可靠性差的问题,我们改用云计算服务,基础设施可靠性,异地容灾,数据备份,数据安全等问题再也不用担心;

数据分析:

原来自建的NFS文件系统,在扩展和访问速度方面随着文件数量的增加响应也越来越慢,这一块采用阿里云的OSS CDN解决方案,应用也需要进行小小的改造。

本文为云栖社区原创内容,未经允许不得转载。返回搜狐,查看更多

大数据计算平台:采用阿里云大数据计算服务

1、 业务架构

HiTSDB 提供百万级时序数据秒级写入,高压缩比低成本存储、预降采样、插值、多维聚合计算,查询结果可视化功能;解决由于设备采集点数量巨大,数据采集频率高,造成的存储成本高,写入和查询分析效率低的问题。后续文章会详细介绍HiTSDB性能测试内容。更多关于HiTSDB介绍请详见文章附录第。

数据采集:

容器管理:采用阿里云容器服务,一站式解决容器生命周期管理及集群管理问题。

随着用户规模与日俱增,慢慢的这套架构也暴露出很多问题来。

www.402.com 5

当前在传统IDC机房中应用的最前端是一台防火墙,用来防御一些常见的攻击和访问控制的操作。因为防火墙并不是什么高端防火墙所以防御能力有限。因公司业务快速发展,期间已经更换过2次防火墙,分别是用户规模在10万和100万的时候。每次更换防火墙对业务都会造成不同程度的停服时间。用户体验很不好,但是没办法因为业务刚开始的时候用户不多,系统设计之初为10万级别,用户从0到10万规模用了1年左右时间。但是从10万到100万用户规模只有了7个月时间,用户增非常快,无奈又更换防火墙到能支撑到500万用户规模。再这么发展下去就不敢想象了。一是硬件设备成本越来越贵,往往投入几十万但是因为业务发展超出预期,刚买来的设备使用不到1年,又面临瓶颈又得换,真是费钱又费力。二是防火墙是所有业务的入口,如果防火墙出问题业务必然会挂,更换会导致业务停服,不更换防火墙会挂还是会停服。

1.9文件存储集群:

七层负载均衡集群采用Nginx服务器,主要为后端web应用服务器提供负载均衡和反向代理功能,此外Nginx支持正则表达式和其他功能。

关于DDOS高防IP和web应用防火墙产品介绍请详见文章附录第7.1&第7.2小结。

由于在高并发环境下,系统来不及同步处理,请求往往会发生堵塞,比如说,大量的insert,update之类的请求同时到达MySQL,直接导致无数的行锁表锁,甚至最后请求会堆积过多,从而触发too many connections错误。通过使用消息队列,我们可以异步处理请求,从而缓解系统的压力。该架构中采用的是开源的Kafka作为消息队列,它是分布式的,基于发布/订阅的消息系统。具有高吞吐率,同时支持实时数据处理和离线数据处理。

数据可视化:采用DataV, 解决了运维大屏,监控大屏没有UI设计问题 企业多多少少有些大屏,在公司接待参观考察工作时展示企业形象,企业运营,以及系统运行情况等。为了提升企业形象,有必要针对数据可视化部分进行美化。阿里云的DataV 可以帮助非专业的工程师通过图形化的界面轻松搭建具有专业水准的可视化应用,让更多的人看到数据可视化的魅力。DataV 提供了丰富的可视化模板,极大程度满足会议展览、业务监控、风险预警、地理信息分析等多种业务的展示需求。更多关于阿里云DataV数据可视化介绍请详见文章附录第5.2小结。

言归正传公司决定选择阿里云作为基础设施,下一步就是如何将业务迁到云上,于是有了这篇文章。该文章篇幅较长,部分引用可能忘记标出来源。

OLAP:ODPS、ADS、流计算。

车联网行业一个比较有规律的特点是早晚出行高峰比较集中。早高峰集中在早上6点至9点3个小时,晚高峰集中在17点至20点的3个小时里。这样会导致每天必须有6个小时左右的流量高峰。如何以较低成本应对早晚高峰是个比较现实的问题。

1.10 大数据计算平台

缓存集群:

 服务升降配

车联网行业用户的月活是非常高的,这个很好理解,因为汽车现在人们出行的必备交通工具,基本上只要一出门就会用车,一用车设备就上线并采集数据上报到平台;每天3小时的平均在线时长,因城市拥堵程度不同而不同。

 为了解决运维自动化问题以及提高运维工作效率,我们改用云上codepipeine 云监控 日志服务 容器服务;

持续集成:我们采用的是Jenkins,它是一款开源持续集成工具,利用Jenkins可以实现代码构建,自动部署,自动测试等持续部署。

为什么我们不自建HBase而选择云数据库HBase呢?云HBase和自建www.402.com 6

目前创业公司一开始就选择了自建IDC机房,起初用户不多,只用几台服务器,后来随着产品越做越好,用户高速增长,不到2年用户规模达到了百万级别,IDC机房的服务器也达到了几百台物理机,几千台虚拟机的规模。但是问题随之也就越来越多。研究规划下一代应用架构和基础设施成了迫在眉睫的事情了,新的应用架构必须满足快速增长的用户量和爆发式的流量访问,用户体验要好;并且基础设施要做到可靠性高,稳定性高,安全性高,成本要低。传统自建IDC方案是很难做到,即便做到成本也是非常的昂贵的。相比之下云计算的各方面能力比较适合用来解决这些问题,所以上云便是最佳选择了。但是云计算厂商有很多,国内有阿里云,腾讯云,金山云等等,国外的有亚马逊,微软,谷歌等。如何选择适合自己业务场景的云计算厂家呢? 我们做了大量的调查分析和对比,最终选择了阿里云。近几年阿里云的发展势头很猛,口碑也越来越好,产品功能丰富性在国内甚至是亚洲是最强的。上云就上阿里云,感觉很接地气。

RDS与自建数据库对比优势:

堡垒机:采用的是Jumpserver开源堡垒机,用于运维人员的操作审计和提升用户登录的安全性;

可以通过配置DDoS高防IP,将攻击流量引流到高防IP,确保源站的稳定可靠。DDoS攻击防护峰值带宽 20 Gbps ~ 300 Gbps 。同时,提供按天弹性付费方案,按当天攻击规模灵活付费。

痛点6:安全防护能力弱,易受攻击

 为了解决数据迁移的稳定性和便捷性,我们采用阿里云数据迁移工具DTS;

这一块我们目前遇到瓶颈是在IDC网络带宽扩容上,目前我们IDC机房如果对需要对网络带宽扩容需要提申请报备,内部走流程做完在到运营商那里走流程,时间往往比较长,最快也要1-2天,无法及对网络带宽做到快速扩容,当然也就无法应对突发流量增长。如果长期购买大量闲置带宽,本身是一种资源的浪费。毕竟目前国内优质的网络带宽资源成本还是相当高的。作为公司的运维同学,如何为公司开源节流,把每一分钱用在刀刃上是责任是义务更是一种能力。

 为了解决单台数据库性能扩展瓶颈,我们改用云上的DRDS分布式关系数据库;

痛点1:运维自动化程度低,运维工作繁重且无意义

3) 用户直接向OSS发送文件上传请求。

数据库集群又包含多种数据库,例如MySQL数据库集群,MongoDB集群,Elasticsearch集群。

 迁移工具:推荐阿里云数据传输服务DTS

四层负载均衡集群采用LVS服务器,主要为后端的协议解析和数据处理服务提供负载均衡功能,因为单台协议解析服务最大每秒只能处理10000台车,所以lvs下挂了很多台数据采集服务器。这样可以满足每秒海量车辆同时在线。

 分布式事务

能力资源平台:是指的公司具备向外界提供的资源和能力,可以利用开放平台将我们的能力提供给外部需要客户和合作伙伴。例如车队服务,数据应用,位置服务等等。

摘要: 最近两年车联网发展受到政府部门、科研院以及各大互联网巨头的广泛关注和积极推动。从应用来看,主要包括两种模式:一是前装模式(即车辆出厂前安装),是乘用车厂主导或者与有相关能力的公司合作,例如上汽和阿里巴巴的合作。

DRDS 支持分布式全局唯一且有序递增的数字序列。满足业务在使用分布式数据库下对主键或者唯一键以及特定场景的需求。

3、 节假日高峰流量难预测

物联网套件是阿里云专门为物联网领域的开发人员推出的一站式设备管理平台。性能强大的IoT Hub方便设备和云端稳定的进行双向通信;全球多节点的部署让全球设备都可以低延时与云端通信;多重的防护能力保障设备云端安全;功能丰富的设备管理能力帮助用户方便进行远程维护设备;稳定可靠的数据存储能力方便海量设备数据存储和实时访问。物联网套件还提供规则引擎与阿里云众多云产品打通,用户通过规则引擎只需在web上配置规则即可实现数据采集 数据计算 数据存储等全栈服务,灵活快速的构建物联网应用。更多关于阿里云IOT套件介绍请详见文章附录。

应用服务器操作系统统一采用Centos7,运行环境主要为JAVA环境和PHP环境,还有少部分Node.js环境

www.402.com 7

流计算采用的阿里巴巴开源的Jstorm,利用流计算平台可以对实时数据进行处理和分析。该架构中使用2套流计算集群,每个流计算集群规模在8台高性能服务器。并且每个集群中包括2个supervisor管控节点,一主一备实现流计算高可用。流计算主要用于车辆告警,行驶轨迹等一些实时计算场景。

www.402.com 8

数据存储集群包含数据库集群和分布式文件系统。

DTS 是阿里云提供的一种支持 RDBMS(关系型数据库)、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、异地多活(单元化)、跨境数据同步、实时数据仓库、查询报表分流、缓存更新、异步消息通知等多种业务应用场景,助构建高安全、可扩展、高可用的数据架构。

如果有对如何选择云计算厂家感兴趣的朋友可以参考下面这篇文章,我觉得写的不错很客观。文章链接:

阿里云CDN在全球拥有1300 节点,国内完整覆盖 34 个省级区域,大量节点位于省会等一线城市。海外覆盖70 多个国家和地区。阿里云所有节点均接入 万兆 网卡;具备 90 Tpbs 带宽能力储备。单节点存储容量达 40 TB-1.5 PB,带宽负载达到 40 Gbps-200 Gbps。

下图为应用架构,主要分为客户端接入层,负载均衡集群,应用服务器集群,缓存集群,消息队列集群,分布式服务集群,数据存储集群,运维管控集群等。

在车联网行业中有个比较明显的行业特性就是早晚高峰是平时流量的3倍甚至更高,但是平常要应付这么高并发的流量意味着资源投入也要3倍以上。在传统IDC架构中,我们通常是按照平常最高峰流量的1.2倍(1.2倍是为应对特殊情况预留的buffer)来准备相应的服务器资源,在平时资源闲置比较明显,资源利用率不到30%,意味着平常可能100台应用服务器就足够了,但是为了应对高峰流量不出问题我们需要准备360台服务器应对6个小时的高峰流量,其余18小时可能只需要100台服务器。为了确保系统稳定,提升用户体验,当时我们只能投入比平时多几倍的服务器资源。所以在云上我们采用阿里云弹性伸缩服务,它是一种根据业务需求和策略,自动调整其弹性计算资源的管理服务。在满足业务需求高峰增长时无缝地增加ECS实例,并在业务需求下降时自动减少ECS实例以节约成本。更多关于阿里云弹性伸缩服务介绍请详见文章附录第1.2小结。

目前我们的应用开发语言有java 有php 有Python,web环境有tomcat,nginx,Node.js等环境,应用发布自动化程度不够高,大多还是脚本方式进行应用升级发布。通常应用发布升级工作都在半夜进行,加班非常严重。运维重复工作量非常大,导致运维成就感很低。大部分时间不是在解决问题就是在升级发布过程中。没有时间提升自身能力。运维人员开始陷入迷茫找不到方向,运维人员流失率逐渐增高,如果不得到有效解决,必将陷入恶性循环。

数据库迁移是整个上云过程中最重要的一环,难度也最大,因为我们在迁移的时候要尽可能的减少业务本身的影响,最好是不停机不中断现有业务。需要制定非常详细的计划和迁移策略:

应用服务器集群:

用户的请求逻辑:

责任编辑:

6) 应用服务器给OSS返回。

因为有大量的各类应用图片和用户上传的图片需要保存,所有需要一个高性能的文件存储,这里采用自建NFS分布式文件系统。

4) 等文件数据上传完,OSS给用户Response前,OSS会根据用户的回调设置,请求用户的服务器。

数据存储集群:

传统自建Elasticsearch集群存在性能不足,集群节点扩容复杂,管理维护难度大等问题,因此我们改用云上Elasticsearch服务,它具有丰富的预置插件(IK Analyzer,pinyin Analyzer,smart Chinese Analysis Plugin,Mapper Attachments Type plugin等等),还包括集成X-pack插件提供企业级权限管控,实时监控等强大功能。它的特点和优势如下:

下图为公司业务架构图。分为三大业务平台,其中核心是车联网平台,其次是能力资源平台和第三方合作平台。

之前的传统运维,基本都是靠人肉运维,脚本运维,运维自动化程度很低,导致故障频发,故障定位难,我们的运维同学大量时间花在了重复的升级发布工作上,花在了填坑以及解决故障上,长此以往运维同学自身发展受限,信心受挫,人员流失比例高的恶性循环的结果。我们迫切希望这种状况可以得到较好的解决。对比之前大量采用开源的监控工具相比,大部分阿里云的产品本身就自带web控制台,也有一些比较实用的运维管控产品,例如云监控,堡垒机,数据管理,数据迁移,容器服务,域名等等。以前的运维痛点可以通过阿里云的运维产品可以很好的得到解决。

MySQL集群:公司目前拥有几十套大大小小的数据库集群,有的采用一主2从的高可用架构,有的是双主架构,这些MySQL数据库主要用于业务数据库。随着公司业务快速发展以及用户规模的快速增长,对数据库的性能要求也越来越高,从原来的高配虚拟机到后来的高配物理机,后来物理机的本地磁盘IO也满足不了要求,接着就开始上给数据库服务上SSD硬盘。现在勉强能维持着,在不久的将来,即便是目前最高配置的单台数据库服务器性能也不能满足的时候,我们怎么办?数据库团队需要提前掌握和了解未来的解决方案是什么,比如说分布式关系型数据库?

2、数据迁移策略

部分行车数据经过各个模块的处理最终保存在数据库中,通过利用大数据分析进行特定场景的离线分析,例如驾驶行为分析服务通过分析用户每天驾驶行为(例如急加速,急减速,急转弯等行为)来判断用户的驾驶行为是否良好,等等。

问题1:海量车机设备的接入导致网络延时高,设备管理困难,安全性差

车联网行业的用户月活很高,早晚高峰比较集中的特性导致用户并发非常高,每天平均长达3小时的车辆在线时长会导致采集数据量非常大,这也直接导致在数据采集场景下基本都是写多读少,但在群组社交,朋友圈,用车报告等场景下是写少读多的。这样复杂的应用场景对应用架构有很高要求。

据有关机构测试发现一辆联网汽车每小时能收集25GB数据。常规数据库在设计之初并非处理这种规模的数据,关系型数据库处理大数据集的效果非常糟糕;NoSQL数据库可以很好地处理规模数据,但是它比不上一个针对时间序列数据微调过的数据库。相比之下,时间序列数据库(可以基于关系型数据库或NoSQL数据库)将时间视作一等公民,通过提高效率来处理这种大规模数据,并带来性能的提升,包括:更高的容纳率(Ingest Rates)、更快的大规模查询(尽管有一些比其他数据库支持更多的查询)以及更好的数据压缩。有兴趣了解更深层次原因的朋友可以参考这个链接:

4、 高并发,高容量,场景复杂

1.8数据存储集群:

我们公司运维大部分时间还是处于人肉运维,脚本运维时代,运维自动化程度低,原因一是公司业务发展太快,运维人员每天大部分时间不是在处理应用升级就是在解决系统故障,根本没有时间去做运维自动的工作。其次运维开发方向的人才比较难招,也可能是开的薪水没有竞争力。总之各种原因导致我们公司在运维自动化进程上比较慢,有恶性循环的趋势。

www.402.com 9

传统IDC底层基础设施通常都是企业自己搭建的,这里会有很多原因导致底座基础设施不稳定的因素。例如企业一开始对硬件投入不重视,使用廉价的设备;再例如工程师技术能力有限,搭建的基础设施架构稳定性差强人意;例如遇到运营商网络质量不稳定,也没有BGP接入,这个时候也只能干瞪眼了。另外我们的IDC机房一年当中遇到过3次意外断电,导致大面积系统瘫痪。所以说底层基础设施不稳定会导致后续应用经常出现莫名其妙的故障,而且无法及时定位,找不到原因。随时会出现意想不到的问题,每天都是提心吊胆的。

产品选型

日志查询和管理:采用ELK,开源日志系统;

www.402.com 10

本文由402cc永利手机版发布于互联网动态,转载请注明出处:车联网上云最佳实践

关键词: www.402.com 402cc永利手机版