摘要： 最近两年车联网发展受到政府部门、科研院以及各大互联网巨头的广泛关注和积极推动。从应用来看，主要包括两种模式：一是前装模式（即车辆出厂前安装），是乘用车厂主导或者与有相关能力的公司合作，例如上汽和阿里巴巴的合作。
一、车联网行业特性讲解
最近两年车联网发展受到政府部门、科研院以及各大互联网巨头的广泛关注和积极推动。从应用来看，主要包括两种模式：一是前装模式（即车辆出厂前安装），是乘用车厂主导或者与有相关能力的公司合作，例如上汽和阿里巴巴的合作。另一种就是后装模式（通常是将车机设备安装在汽车的OBD接口上例如各类汽车盒子等等。原理是利用智能终端（即车机）采集汽车OBD接口CAN总线上的所有原始数据进行诊断，数据分析，记录行车信息，并将数据解析出其具体意义（汽车内部电控系统的各项传感器数值）后通过串口输出，供用户读取、解析、开发等使用。将读取到的汽车内部运行数据通过手机APP软件直观展现。
首先大致梳理下车联网行业的特性有哪些：
1、 月活非常高，在线时间长
车联网行业用户的月活是非常高的，这个很好理解，因为汽车现在人们出行的必备交通工具，基本上只要一出门就会用车，一用车设备就上线并采集数据上报到平台；每天3小时的平均在线时长，因城市拥堵程度不同而不同。
2、 早晚出行高峰比较固定
车联网行业一个比较有规律的特点是早晚出行高峰比较集中。早高峰集中在早上6点至9点3个小时，晚高峰集中在17点至20点的3个小时里。这样会导致每天必须有6个小时左右的流量高峰。如何以较低成本应对早晚高峰是个比较现实的问题。
3、 节假日高峰流量难预测
现在国家法定节假日期间，由于高速公路在此期间免费的政策，导致越来越多的人们开始选择驾车出行或出游，所以每当节假日来临时必然导致车联网用户暴增，这个洪峰流量来临的时间和流量是不确定的。如何能准确做好每次节假日出行高峰预测是个问题。
4、 高并发，高容量，场景复杂
车联网行业的用户月活很高，早晚高峰比较集中的特性导致用户并发非常高，每天平均长达3小时的车辆在线时长会导致采集数据量非常大，这也直接导致在数据采集场景下基本都是写多读少，但在群组社交，朋友圈，用车报告等场景下是写少读多的。这样复杂的应用场景对应用架构有很高要求。
5、 汽车技术更新频率快
如今汽车技术更新越来越快，汽车厂商越来越多，厂商发布的新车型的频率也越来越高，车联网企业对这汽车行业的新技术必须保持非常高度关注，必须加快版本迭代，提高研发效率才能及时应对汽车市场的变化，才能在第一时间解决和满足市场和用户的需求。
目前创业公司一开始就选择了自建IDC机房，起初用户不多，只用几台服务器，后来随着产品越做越好，用户高速增长，不到2年用户规模达到了百万级别，IDC机房的服务器也达到了几百台物理机，几千台虚拟机的规模。但是问题随之也就越来越多。研究规划下一代应用架构和基础设施成了迫在眉睫的事情了，新的应用架构必须满足快速增长的用户量和爆发式的流量访问，用户体验要好；并且基础设施要做到可靠性高，稳定性高，安全性高，成本要低。传统自建IDC方案是很难做到，即便做到成本也是非常的昂贵的。相比之下云计算的各方面能力比较适合用来解决这些问题，所以上云便是最佳选择了。但是云计算厂商有很多，国内有阿里云，腾讯云，金山云等等，国外的有亚马逊，微软，谷歌等。如何选择适合自己业务场景的云计算厂家呢？ 我们做了大量的调查分析和对比，最终选择了阿里云。近几年阿里云的发展势头很猛，口碑也越来越好，产品功能丰富性在国内甚至是亚洲是最强的。上云就上阿里云，感觉很接地气。
如果有对如何选择云计算厂家感兴趣的朋友可以参考下面这篇文章，我觉得写的不错很客观。文章链接：https://blog.csdn.net/mll999888/article/details/72851464#commentBox
言归正传公司决定选择阿里云作为基础设施，下一步就是如何将业务迁到云上，于是有了这篇文章。该文章篇幅较长，部分引用可能忘记标出来源。
二、传统IDC架构介绍及技术详解
俗话说知己知彼百战不殆，我们要上云首先要充分了解自己业务和应用架构。然后在充分了解云上产品的特性，看看哪些产品可以直接被我们使用，哪些是需要我们的应用或架构做出调整的。下面我们来分析下智能车联网平台的相关架构。
1、 业务架构
下图为公司业务架构图。分为三大业务平台，其中核心是车联网平台，其次是能力资源平台和第三方合作平台。
车联网核心平台：主要包含应用层、支持层、物理层等功能，其中应用层包含功能有用户注册，用户登录，导航功能，车友功能，车辆检测功能，轨迹查询功能以及其他娱乐功能。这些是APP的核心功能。其次是支持层的功能，例如运营管理系统，用户管理系统，车辆管理系统等辅助运营和运维的系统和工具。
能力资源平台：是指的公司具备向外界提供的资源和能力，可以利用开放平台将我们的能力提供给外部需要客户和合作伙伴。例如车队服务，数据应用，位置服务等等。
第三方合作平台：是指通过调用第三方平台接口来完成为用户提供部分功能，例如保险服务，违章查询功能，停车位查找功能，4S店服务等功能。
2、应用架构
下图为应用架构，主要分为客户端接入层，负载均衡集群，应用服务器集群，缓存集群，消息队列集群，分布式服务集群，数据存储集群，运维管控集群等。
1.1 数据流介绍
数据采集：
首先通过车载智能终端设备收集汽车相关行驶数据，然后通过物联网卡（即sim卡）上报到平台，平台经过协议解析服务将数据转换成可读的数据并进行存储下来，并且需要把原始数据也保存一份。
数据处理：
将解析后的数据放到消息队列中，后端的各种应用服务开始处理不同的数据，例如轨迹服务会去消息队列中取×××迹数据进行分析和处理。从而生成用户的行驶轨迹等功能；再例如故障检测服务，通过订阅消息队列中有关汽车传感器数值进行分析和判断该车辆是否存在故障。
数据分析：
部分行车数据经过各个模块的处理最终保存在数据库中，通过利用大数据分析进行特定场景的离线分析，例如驾驶行为分析服务通过分析用户每天驾驶行为（例如急加速，急减速，急转弯等行为）来判断用户的驾驶行为是否良好,等等。
数据展示：
用户通过下载并安装手机APP，注册登录App后用户可以在APP 上查看自己车辆的位置，轨迹查询，油耗，车辆故障以及交友，娱乐等功能。
1.2 应用架构介绍
防火墙：
当前在传统IDC机房中应用的最前端是一台防火墙，用来防御一些常见的×××和访问控制的操作。因为防火墙并不是什么高端防火墙所以防御能力有限。因公司业务快速发展，期间已经更换过2次防火墙，分别是用户规模在10万和100万的时候。每次更换防火墙对业务都会造成不同程度的停服时间。用户体验很不好，但是没办法因为业务刚开始的时候用户不多，系统设计之初为10万级别，用户从0到10万规模用了1年左右时间。但是从10万到100万用户规模只有了7个月时间，用户增非常快，无奈又更换防火墙到能支撑到500万用户规模。再这么发展下去就不敢想象了。一是硬件设备成本越来越贵，往往投入几十万但是因为业务发展超出预期，刚买来的设备使用不到1年，又面临瓶颈又得换，真是费钱又费力。二是防火墙是所有业务的入口，如果防火墙出问题业务必然会挂，更换会导致业务停服，不更换防火墙会挂还是会停服。
负载均衡集群：
四层负载均衡集群采用LVS服务器，主要为后端的协议解析和数据处理服务提供负载均衡功能，因为单台协议解析服务最大每秒只能处理10000台车，所以lvs下挂了很多台数据采集服务器。这样可以满足每秒海量车辆同时在线。
七层负载均衡集群采用Nginx服务器，主要为后端web应用服务器提供负载均衡和反向代理功能，此外Nginx支持正则表达式和其他功能。
这一块我们目前遇到瓶颈是在IDC网络带宽扩容上，目前我们IDC机房如果对需要对网络带宽扩容需要提申请报备，内部走流程做完在到运营商那里走流程，时间往往比较长，最快也要1-2天，无法及对网络带宽做到快速扩容，当然也就无法应对突发流量增长。如果长期购买大量闲置带宽，本身是一种资源的浪费。毕竟目前国内优质的网络带宽资源成本还是相当高的。作为公司的运维同学，如何为公司开源节流，把每一分钱用在刀刃上是责任是义务更是一种能力。
应用服务器集群:
应用服务器操作系统统一采用Centos7，运行环境主要为JAVA环境和PHP环境，还有少部分Node.js环境
Java环境：采用Centos7 + JDK1.7 + Tomcat7
PHP环境:采用Centos7 + PHP5.6.11
Node.js环境：采用Centos7 + Node8.9.3
目前我们的应用开发语言有java 有php 有Python，web环境有tomcat，nginx，Node.js等环境，应用发布自动化程度不够高，大多还是脚本方式进行应用升级发布。通常应用发布升级工作都在半夜进行，加班非常严重。运维重复工作量非常大，导致运维成就感很低。大部分时间不是在解决问题就是在升级发布过程中。没有时间提升自身能力。运维人员开始陷入迷茫找不到方向，运维人员流失率逐渐增高，如果不得到有效解决，必将陷入恶性循环。
分布式服务集群：
分布式服务集群，采用Dubbo + ZooKeeper搭建的分布式服务框架。其中zookeeper的服务器需要保持奇数目的是便于选举。
Dubbo也是比较流行的JAVA应用的分布式服务框架，它是阿里开源的分布式服务框架。但是在使用过程中也发现由于没有一个比较好用的Dubbo监控软件，导致应用出现故障时排查故障很费力，如果有一套比较强大的链路跟踪监控系统对于那分布式应用来说是锦上添花了。
缓存集群：
缓存集群采用的Redis3.0 Cluster集群模式，该架构中有10套Redis缓存集群，每个集群的内存从60G-300G不等。缓存服务器是典型的内存型主机，对CPU开销不大，如果要做持久化，对磁盘IO要求较高，磁盘建议使用SSD。
对于缓存最大痛点在于运维，经常出现因磁盘IO瓶颈导致的redis集群故障，以及因用户快速增长需要经常对Redis集群进行在线扩容等。而且Redis运维都是只能是手动运维，工作量大，且容易误操作。因Redis集群而导致的故障不计其数。当然也跟当时的应用强依赖相关，Redis集群故障就导致整个应用也挂了，这是应用系统设计的缺陷。
消息队列集群：
由于在高并发环境下，系统来不及同步处理，请求往往会发生堵塞，比如说，大量的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，处于非常被动和无奈的局面。
流计算集群：
流计算采用的阿里巴巴开源的Jstorm，利用流计算平台可以对实时数据进行处理和分析。该架构中使用2套流计算集群，每个流计算集群规模在8台高性能服务器。并且每个集群中包括2个supervisor管控节点，一主一备实现流计算高可用。流计算主要用于车辆告警，行驶轨迹等一些实时计算场景。
数据存储集群：
数据存储集群包含数据库集群和分布式文件系统。
数据库集群又包含多种数据库，例如MySQL数据库集群，MongoDB集群，Elasticsearch集群。
MySQL集群：公司目前拥有几十套大大小小的数据库集群，有的采用一主2从的高可用架构，有的是双主架构，这些MySQL数据库主要用于业务数据库。随着公司业务快速发展以及用户规模的快速增长，对数据库的性能要求也越来越高，从原来的高配虚拟机到后来的高配物理机，后来物理机的本地磁盘IO也满足不了要求，接着就开始上给数据库服务上SSD硬盘。现在勉强能维持着，在不久的将来，即便是目前最高配置的单台数据库服务器性能也不能满足的时候，我们怎么办？数据库团队需要提前掌握和了解未来的解决方案是什么，比如说分布式关系型数据库？
MongoDB集群：公司目前有3套MongoDB集群，主要用来存储车辆上报的原始数据，和解析后的车辆状态、点火、告警、轨迹等数据。采用的是副本集，通常由只是3个节点组成。其中一个是主节点，负责处理客户端请求，其余都是从节点，负责复制主节点上的数据。
Elasticsearch集群：ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。该架构中ES集群采用3个节点，这个3个节点都是候选主节点。这里我们主要用于轨迹查询，信息检索、日志系统等场景。
NFS分布式文件系统：
因为有大量的各类应用图片和用户上传的图片需要保存，所有需要一个高性能的文件存储，这里采用自建NFS分布式文件系统。
但是自建NFS分布式文件系统由于公司投入硬件设备有限，导致本身的扩展性是相当差的，而且需要停机相当影响业务。访问速度因客户端增加而变慢。这是个很影响用户体验的痛点，必须改造。
运维管控集群：
在复杂的系统架构和海量的服务器环境中，需要合适的运维管控软件来提升运维的工作效率。
监控：采用的是Zabbix开源监控系统；
代码管理：采用gitlab进行代码托管；
堡垒机：采用的是Jumpserver开源堡垒机，用于运维人员的操作审计和提升用户登录的安全性；
日志查询和管理：采用ELK，开源日志系统；
持续集成：我们采用的是Jenkins，它是一款开源持续集成工具，利用Jenkins可以实现代码构建，自动部署，自动测试等持续部署。
配置管理系统：提供应用的集中式配置管理，是基于java开发的配置管理。
虽然当前的运维体系还算比较规范，但是大多数运维工具都是开源的产品，只能满足部分功能需求。随着运维管控需求的增加，需要的熟悉的开源产品也越多。运维管理不够统一，运维人员通常需要熟悉和掌握很多运维系统，导致新手很难入手。
1.3 传统IDC架构痛点
随着用户规模与日俱增，慢慢的这套架构也暴露出很多问题来。
痛点1：运维自动化程度低，运维工作繁重且无意义
我们公司运维大部分时间还是处于人肉运维，脚本运维时代，运维自动化程度低，原因一是公司业务发展太快，运维人员每天大部分时间不是在处理应用升级就是在解决系统故障，根本没有时间去做运维自动的工作。其次运维开发方向的人才比较难招，也可能是开的薪水没有竞争力。总之各种原因导致我们公司在运维自动化进程上比较慢，有恶性循环的趋势。
痛点2：没有弹性扩容缩容能力，应对流量高峰代价高
因为车联网行业的一个特点就是早晚高峰和节假日期间车辆在线率飙升，然后进入平稳期。一天24小时有6个小时是早晚高峰，其余18个小时是正常流量，通常高峰期流量是平常的3-5倍。传统IDC通常需要几天时间才能完成一次线上扩容，根本不可能应对突发性的流量暴涨的情况。我们为了保障系统稳定性以及保障用户体验，只能是投入比平时多几倍的资源，整体资源利用率不到30%，产生巨大资源浪费。
痛点3：运维工具零散、运维工作复杂繁琐
我们公司的运维管控软件绝大部分是以开源为主的运维软件，种类繁多，例如开源跳板机Jumpserver，zabbix监控系统，持续集成Jenkins，自动化运维Ansible等等，这些软件都需要配置独立的登录账号。导致账号繁多，管理非常不方便，运维人员需要操作和熟悉很多开源软件。例如zabbix监控在规模不大的时候基本能应付日常的监控告警，但是随着服务器的增加导致监控项的急剧增加之后，数据库性能跟不上，告警延迟或者误报的情况非常多。一些定制监控需求和监控项目仍需要单独开发。所以运维工具种类繁多也直接导致运维工作的复杂繁琐。
痛点4： 硬件设备采购周期长，成本高，扩展性差
我们公司应用刚上线的时候系统各方面的设计比较简单，横向扩展能力不强，随着业务爆发式增长，因为我们很多资源无法及时扩展，导致系统故障，用户体验降低。例如文件存储，刚开始的时候我们是自建的NFS文件存储，用于存放用户头像，驾驶证，朋友圈等图片文件。由于各方面原因当初没有投入足够的资源建设，导致一段时间之后存储就不够用，读写性能下降，用户访问延迟等等。最痛的一点是硬件设备的扩展周期长，从提出采购需求到最后的实施硬件扩展，往往需要5-10天甚至更长，因为这期间需要经历采购审批流程，物流发货，到货验收，机房上架等。
痛点5：基础设施可靠性差，故障频发
传统IDC底层基础设施通常都是企业自己搭建的，这里会有很多原因导致底座基础设施不稳定的因素。例如企业一开始对硬件投入不重视，使用廉价的设备；再例如工程师技术能力有限，搭建的基础设施架构稳定性差强人意；例如遇到运营商网络质量不稳定，也没有BGP接入，这个时候也只能干瞪眼了。另外我们的IDC机房一年当中遇到过3次意外断电，导致大面积系统瘫痪。所以说底层基础设施不稳定会导致后续应用经常出现莫名其妙的故障，而且无法及时定位，找不到原因。随时会出现意想不到的问题，每天都是提心吊胆的。
痛点6：安全防护能力弱，易受×××
随着公司快速发展和用户规模的增长的同时，很容易被别有用心的人盯上，记得有一天下午3点左右，突然遭受到大量DDOS×××，我们的防火墙一下就被打垮了，系统瞬间就瘫痪了，没有办法，什么都做不了，防火墙已经跪了，登不上去了，一直持续几个小时，业务也瘫痪了几个小时，一点办法没有。我们的安全防护能力真的很弱，也跟成本有关，高端的防火墙买不起，还有运营商的带宽也很贵。
本文为云栖社区原创内容，未经允许不得转载。
原文地址：http://blog.51cto.com/13952056/2173440