原标题:车联网上云最佳实践(一)

原标题:车联网上云最佳实践(二)

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

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

一、车联网行业特性讲解

云上对标架构及技术详解

最近两年车联网发展受到政府部门、科研院以及各大互联网巨头的广泛关注和积极推动。从应用来看,主要包括两种模式:一是前装模式(即车辆出厂前安装),是乘用车厂主导或者与有相关能力的公司合作,例如上汽和阿里巴巴的合作。另一种就是后装模式(通常是将车机设备安装在汽车的OBD接口上例如各类汽车盒子等等。原理是利用智能终端(即车机)采集汽车OBD接口CAN总线上的所有原始数据进行诊断,数据分析,记录行车信息,并将数据解析出其具体意义(汽车内部电控系统的各项传感器数值)后通过串口输出,供用户读取、解析、开发等使用。将读取到的汽车内部运行数据通过手机APP软件直观展现。

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

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


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

1、 月活非常高,在线时间长


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

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

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

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


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

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


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

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


为了解决大数据存储瓶颈以及降低大数据开发分析工作难度,我们改用云上MaxCompute

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

  • HBase;

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


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

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

 为了解决安全防御瓶颈,我们改用云上云盾+DDOS高防IP +
web应用防火墙+堡垒机;

5、 汽车技术更新频率快

 为了解决负载均衡以及网络扩容瓶颈,我们改用云上SLB;

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


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

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

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

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

我们云上新的应用架构即会兼容部分老应用架构的特性,同时会采用云上新技术和云上产品来解决我们曾经的痛点和瓶颈。并且云上新架构需要满足未来2-3年的业务发展规划,能够支撑千万级用户规模的应用系统架构。下图为云上应用架构图。

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

图片 1

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

1、云上对标架构介绍

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

1.1安全:

1、 业务架构

安全这块以前IDC机房的时候防范能力比较弱。为了解决安全防御瓶颈,我们改用云上云盾+DDOS高防IP

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

  • web应用防火墙+堡垒机;

图片 2

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

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

云盾Web应用防火墙可以防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见攻击,并过滤海量恶意CC攻击,避免网站资产数据泄露,保障网站的安全与可用性。

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

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

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

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

2、应用架构

1.2负载均衡集群:

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

为了解决负载均衡以及网络扩容瓶颈,我们改用云上SLB负载均衡。阿里云的SLB负责均衡提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡服务。四层采用开源软件LVS实现负载均衡,并根据云计算需求对其进行了个性化定制。七层采用Tengine实现负载均衡。Tengine是由淘宝网发起的Web服务器项目,它在Nginx的基础上,针对有大访问量的网站需求,添加了很多高级功能。更多关于阿里云负载均衡介绍请详见文章附录第2.2小结。

图片 3

负载均衡实例规格选型:

1.1 数据流介绍

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

数据采集:

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

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

图片 4

数据处理:

1.3应用服务器集群:

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

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

数据分析:

Java环境:采用Centos7 + JDK1.7 + Tomcat7

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

PHP环境:采用Centos7 + PHP5.6.11

数据展示:

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

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

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

1.2 应用架构介绍

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

防火墙:

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

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

图片 5

负载均衡集群:

产品选型

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

ECS产品根据业务场景和使用场景,ECS实例可以分为多种规格族。同一业务场景下,还可以选择新旧多种规格族。同一个规格族里,根据CPU和内存的配置,可以分为多种不同的规格。ECS实例规格定义了实例的CPU和内存的配置(包括CPU型号、主频等)这两个基本属性。根据此前车联网行业特性来看,前端web应用推荐ecs.c5.xlarge(4核8G)规格实例,而后端应用推荐ecs.g5.xlarge(4核16G)规格实例。

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

图片 6

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

图片 7

应用服务器集群:

1.4分布式服务集群:

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

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

Java环境:采用Centos7 + JDK1.7 + Tomcat7

1.5缓存集群:

PHP环境:采用Centos7 + PHP5.6.11

缓存集群采用阿里云数据库Redis版,传统自建Redis数据库通常存在集群节点扩容复杂,管理维护难等问题。所以我们改用云上数据库
Redis
版来替代,它具有性能卓越,弹性扩容,数据安全性高,可用性高,秒级监控,简单易用等优势。云数据库Redis版支持按量付费和包年包月两种模式,按量付费可转为包年包月模式,反之则不可以。可根据自己的需求自主选择更多关于云数据库Redis介绍请详见文章附录第3.2小结。

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

1.6消息队列集群:

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

消息队列采用阿里云的消息队列kafka服务,因为之前开源的kafka消息队列也经常遇到各种问题,也没有相应的能力去修复bug,选择阿里云的消息队列服务之后就不用担心这些问题,因为阿里云有一支专家团队在维护它的日常稳定运行,如出现官方bug他们有能力第一时间修复bug。更多关于阿里云消息队列kafka介绍请详见文章附录第8.2小结。

分布式服务集群:

1.7流计算集群:

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

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

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

图片 8

缓存集群:

1.8数据存储集群:

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

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

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

阿里云数据库 MySQL 版是基于 Alibaba 的 MySQL 源码分支,经过双 11
高并发、大数据量的考验,拥有优良的性能和吞吐量。除此之外,阿里云数据库
MySQL 版还拥有经过优化的读写分离、数据压缩、智能调优等高级功能。当前 RDS
for MySQL 支持 5.5、5.6 和 5.7 版本。请详见文章附录第3.1小结。

消息队列集群:

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

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

综合性能对比

这个消息队列的痛点也是刻骨铭心,kafka是开源软件,曾经遇到几次故障都是跟kafka有关系,在0.8.1,遇到kafka删除topic的功能存在bug,随后升级到09版本,不巧又遇到09版本kafka
client的BUG,这个bug导致多分区多consumer时rebalancing可能会导致某个分区阻塞。后来升级kafka10版本,但是10版本的消费方式和08版本有差别,没办法又对消费程序进行改造。总之在我们使用kafka过程中遇到太多kafka的bug而导致的故障了。而我们中小企业技术能力有限没有能力第一时间修复这种开源软件的bug,处于非常被动和无奈的局面。

![20180831141508]()

流计算集群:

成本对比

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

![1]()

数据存储集群:

图片 9

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

HBase集群:采用的是阿里云数据库HBase版

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

传统架构中的MongoDBS用来存储车辆上报的原始数据的,这些数据通常情况下写多读少,原始数据的保存可以有利于特殊情况对问题的追溯。或者是数据丢失的情况下可以用原始数据来进行弥补。原来MongoDB集群在达到一定规模之后性能出现断崖下降,因为对MongoDB掌握不够深,没有正确使MongoDB导致。这里改用云上数据库HBase版来替换原来的MongoDB集群。HBase的高并发大数据量等特性非常适合海量数据存储,业务大屏,安全风控,搜索等场景。

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

HBase主要优势有两点:1)扩展性要强,HBase是专门的列式数据库,具有高并发,低时延的处理能力,支持数据从200G~10PB都适合。数据存储在HDFS,默认具备多副本可靠性和自动扩展能力。2)HBase是天生的hadoop生态系统中的组件,选择HBase,就是选择整个Hadoop生态。云HBase自带的Phoneix组件,支持SQL能力,二级索引等,非常适合IoT实时业务,并且支持带少量更新的TP操作。HBase和MapReduce,spark天然的结合,同一份数据,支持实时业务的同时,可以完成大数据的分析,以及还有时序组件OpenTSDB等。更多关于云数据库HBase介绍请详见文章附录第3.4小结。

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

为什么我们不自建HBase而选择云数据库HBase呢?云HBase和自建图片 10

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

自建和服务更多的对比 ,可以参考以下文章:

NFS分布式文件系统:

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

Elasticsearch集群:采用阿里云的Elasticsearch

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

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

运维管控集群:

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

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

 分布式的实时分析搜索引擎

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

 商业版X-pack插件,提供企业级权限管控、实时系统监控等强大服务

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

 可弹性扩展到上百台服务器规模,处理PB级结构化或非结构化数据

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

 支持IK analyzer插件

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

 Elastic官方技术支持团队7*24小时技术支持

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

1.9文件存储集群:

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

文件存储:采用阿里云对象存储OSS

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

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

1.3 传统IDC架构痛点

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

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

阿里云对象存储服务(Object Storage Service,简称
OSS),是阿里云提供的海量、安全、低成本、高可靠的云存储服务。它具有与平台无关的RESTful
API接口,能够提供99.999999999%(11个9)的数据可靠性和99.99%的服务可用性。可以使用阿里云提供的API/SDK接口或者OSS迁移工具轻松地将海量数据移入或移出阿里云OSS。数据存储到阿里云OSS以后,推荐选择标准类型(Standard)的阿里云OSS服务作为移动应用、大型网站、图片分享或热点音视频的主要存储方式,也可以选择成本更低、存储期限更长的低频访问类型(Infrequent
Access)和归档类型(Archive)的阿里云OSS服务作为不经常访问数据的备份和归档。更多关于阿里云对象存储服务OSS介绍请详见文章附录第4小结。

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

1.10 大数据计算平台

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

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

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

智能车联网平台每天会采集海量车行驶数据,例如车辆发动机状态,驾驶行为,油耗,公里数,行驶轨迹等等,我们需要对这些海量数据进行加工和分析。例如用户每天行驶里程统计,油耗统计,用户驾驶行为月报告等等。因初期数据量相对较小,使用Kettle进行抽取数据等工作,ETL的工作大部分在MySQL数据仓库中完成。多种数据源使用Presto(集群)作为查询中间键进行相应的数据分析。但随着业务的疯狂增长,数据表单表达到数亿后,磁盘容量达几百GB时,数据要求的复杂度逐步提升,使用MySQL作为基础数据仓库的基石已经不足以应付,常出现查询响应时间等待过长,甚至内存崩溃导致执行失败的情况,极大的影响了工作效率。所以云上我们改用阿里云MaxCompute大数据计算服务来构建我们公司大数据开发和分析平台。MaxCompute能够为我们提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决海量数据计算问题,有效帮助我们公司降低成本,并保障数据安全。Dataworks则提供了一站式的数据同步,数据开发,数据管理和数据运维等功能。更多关于阿里云大数据计算服务介绍请详见文章附录第6.2小结。

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

1.11运维管控集群:

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

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

我们公司的运维管控软件绝大部分是以开源为主的运维软件,种类繁多,例如开源跳板机Jumpserver,zabbix监控系统,持续集成Jenkins,自动化运维Ansible等等,这些软件都需要配置独立的登录账号。导致账号繁多,管理非常不方便,运维人员需要操作和熟悉很多开源软件。例如zabbix监控在规模不大的时候基本能应付日常的监控告警,但是随着服务器的增加导致监控项的急剧增加之后,数据库性能跟不上,告警延迟或者误报的情况非常多。一些定制监控需求和监控项目仍需要单独开发。所以运维工具种类繁多也直接导致运维工作的复杂繁琐。

日志管理:采用阿里云日志服务解决日志收集,日志分析,日志搜索等问题。