数百万辆汽车的最强大脑——云端车联网架构实战

简介:

截止2015年底,全国机动车保有量达到了2.79亿辆,庞大的汽车市场催生出一个新行业——车联网。元征是国内车联网领域中首屈一指的领军企业,凭借青云QingCloud云平台的完整性、可靠性、灵活性,元征的IT部门有力地保障了公司车联网战略的顺利实施,省却了后顾之忧。

说起开车,很多人可能是既爱又恨。这几年,路上的车明显多了很多,尤其是在各种小长假、大长假时全国高速都变成了停车场,其中滋味只有司机才能体会。有人可能要问了,现在中国到底有多少辆车呢?这里有一组数据可以回答:截止2015年底,全国机动车保有量达到了2.79亿辆,其中私家车达到1.24亿辆。这意味着全国平均每百户家庭就有31辆私家车!

庞大的汽车保有量也造就了一个巨大的市场,除了整车制造与销售外,还有零部件销售、汽车维修、车险、洗车、保养、汽车美容、导航、行车记录、车载娱乐系统、二手车交易等后服务行业。如果可以将人、车(成千上万的零部件与实时的状态)、地点、生活、娱乐、维修与保养服务、公共交通服务、商业、金融、保险……全部连接起来,海量的数据将给人以无限的想象空间。但是目前汽车上除了驾驶以外最常用的功能居然还是最原始的广播电台,即便涌现了大量O2O的后服务,维修保养理赔仍然还是耗时耗力的事情,这简直没有天理。 

车联网的生态发展变迁

车联网的出现让我们看到了这种人、车、地点、商业互联与数据共享的可能。车联网其实并不算一项很新鲜的技术和产品概念,早在2010年时就已经出现了在百度关键词中。早期有一些车企为了提高车主的驾驶体验推出了一些平台化服务,如上汽和丰田雷克萨斯的安吉星、G-BOOK,虽然是通过电话来连接,并没有连接到互联网,但这还是被视作车联网的雏形。在车联网的生态圈中车企又被称作前装系。 

但是车企做的系统通常是由各品牌厂商自家生产的,比较封闭。这时候以一大批互联网厂商为代表的第三方也推出了类似服务,他们在车联网生态中被称作后装系,主要提供导航仪、车载MP3等服务。虽然比起前装系更加灵活,终于不限车型和品牌了,但是也仅仅限于娱乐。

车联网当然不应该仅仅是车载互联网和娱乐设备,还应该将安保技术、车辆控制技术都利用互联网有机结合起来,从而为车主提供全面的服务保障。能够提供这类服务的企业在车联网生态环境中被称作服务系,服务系的出现标志着车联网迈出了重要的一步。元征科技就属于这一类,他们希望把车里的数据和车上人的数据整合到一起,提供给车主和需要的部门、团队或公司,创造出新的价值。

为什么要讲元征科技的故事?

如果不是对车极度着迷的车友的话,可能你从来都没有听过元征科技这家公司。但在车联网领域,元征早已成为中国首屈一指的领军企业。元征科技早在1993年就成立了,是国内最早致力于汽车诊断、检测、养护产品研发、生产和销售的高科技企业。

早期的元征一直在做一些特别专业的汽车诊断设备,例如读码卡。这个设备是干什么的呢?搜索了一下发现:现在很多汽车制造企业都会在其生产的汽车上配备OBD(On-BoardDiagnostic 车载诊断系统),这个系统可以帮助我们将车子出现的问题检测出来。但特别需要强调的是,我们从OBD读取到的车辆信息都是加密的。例如奔驰车必须有奔驰的检测仪才能在不解体的条件下查明故障部位及原因,而且这个设备要十多万一个!

为了破解这些信息,元征就提供了一种叫做“读码卡”的诊断设备,目前读码卡可以检测2,800种车辆的故障。

从老大到小学生 元征的车联网之路

很快元征就在读码器市场做到了行业第一,但并不满足于此,而是将目光瞄向了价值5,000亿的车联网市场,勇于从行业老大跨越到新的行业中当起了小学生。目前元征的车联网服务主要基于两个方向:第一是车辆的安全,第二是车辆的娱乐系统。

元征科技为此开发了GOLO车联网盒子、GOLO车手机、GOLO手环、GOLO技师等产品,丰富了车联网的前端、后端等所有支持车联网运转的组件。 

GOLO 车联网盒子是元征首款车联网智能硬件,以前是通过GPS模块、OBD得到很多汽车的数据,但是这些数据拿出来不能直接用,需要一个平台分析处理这些数据。GOLO就可以获取车辆的即时数据,为用户提供实时远程诊断、车辆专业体检、车辆维修指导、车辆报警等服务。同时,还可以嫁接车主生活社区、地图定位、行车记录等服务。

GOLO车手机除了基本的诊断功能外,还具有娱乐和GPS功能,在汽车没有发生故障的时候承担车载娱乐总管家的功能,增强用户粘性。而一旦发生故障,GPS与原有的诊断功能结合,就能够及时读取故障码、通过远程协助或车主选择附近快修店,为汽车保驾护航。

元征的车联网云

元征的野心不止于此,为了将GOLO、解码器、读码卡等产品获取的车辆信息同步到云端,元征推出了LAUNCH-CLOUD。一旦车辆出现什么问题,就会有后端的专业人员为车主提供服务支撑。元征在GOLO的基础上,构建了一个以车主、维修技师、维修企业、第三方服务商为主的汽车维修及车主生活服务平台。

有一组数字可以说明元征这个云端车联网的规模,目前元征拥有三类生态产品,即维修厂B端(可实时上传数据的X-431平板等诊断仪);服务C端(免费赠送给技师的GOLO技师盒子)和消费C端(需要车主购买的GOLO 车联网盒子)。截止到2015年,维修厂的设备达到20万套、免费赠送的技师盒子30万套、GOLO车联网盒子达到百万级用户量。元征的云平台每日可收到诊断报告50,000多份。

如此大的数据量如果在传统的IDC模式下,无疑将会遭遇许多挑战:

首先是服务器扩展性差,假如元征现在有一个新需求,需满足50万用户上线,并要求在两天内搭建好应用,这在传统IDC模式下根本无法实现。 

第二是运维不灵活,现在元征大概有几百台服务器,运营人员增加了10倍,21世纪最贵的是什么?人才!这人力成本可不是小数。

第三是信息安全无法保障,人员越多、机房越多,安全隐患也就会越多。

第四是车辆行驶的场景对动态网络要求较高,传统IDC无法实时支持对网络的动态调整。

元征科技与云服务的一见钟情

什么样的IT服务可以应对上述挑战?答案当然是安全可靠、敏捷响应、弹性可扩展的云服务,而QingCloud正是把性能、可靠、敏捷与弹性做到极致,同时完全的按量计费和灵活的自动伸缩在保障业务稳定运行的同时,帮助企业实现最大的经济性。

上图是元征GOLO的平台架构图,现在用的是LAMP架构,所有的数据接入都在服务器端,中间是应用层,上面有MySQL、MongoDB等数据库。此架构承担了监控、生产环境、开发和对外运营四个功能。这就是现在元征支撑一百万用户的平台,元征科技在做过详细比较后,选择了QingCloud。

凭借QingCloud平台的完整性、可靠性、灵活性,元征的IT部门有力地保障了公司车联网战略的顺利实施,省却了后顾之忧。 

QingCloud灵活的按秒计费、计量方式为元征节省了大量运营成本,QingCloud的自动伸缩(AutoScaling)功能帮助用户基于资源的监控告警规则动态调节配置或集群规模,比如调整带宽上限,扩容关系型数据库的存储空间,增加或减少负载均衡器后端数量等。基于这项功能,元征就可以在业务高峰时段按需开启服务,其它时段关闭限制服务器以节省成本。 

使用QingCloud同样有效降低了元征的运维成本,随着元征的业务发展快速增长,现在服务器数量与初期服务器数量相比增加了好几倍,但是运维人员并不需要增加。从前管理100台服务器需要10个运维工程师,现在管理100台服务器只需要1个工程师,其中的人力成本差别简单明了。

此外,元征在规划云的时候选择的是混合云模式,QingCloud的私有云和公有云具有统一的管理平台,可以节省大量的人力、物力成本。在元征的这个架构中,要求从运维、应用的搭建、业务的选择、架构的选择,都要是可选的、可变的和灵活的。一旦需要做业务迁移的时候,不用将业务停掉就能够实现架构的灵活变更。QingCloud混合云解决方案一举解决了元征在混合云架构方面的困境。 

元征技术部总监阎其治用四个字来形容QingCloud的服务:“QingCloud的特点就是“多快好省”——多就是机器多;快就是架构简单非常快;好是服务好;省就是省钱。”






原文发布时间为:2016年7月20日 
本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。
目录
相关文章
|
1天前
|
弹性计算 Java 数据库
Web应用上云经典架构实战
本课程详细介绍了Web应用上云的经典架构实战,涵盖前期准备、配置ALB、创建服务器组和监听、验证ECS公网能力、环境配置(JDK、Maven、Node、Git)、下载并运行若依框架、操作第二台ECS以及验证高可用性。通过具体步骤和命令,帮助学员快速掌握云上部署的全流程。
|
1天前
|
弹性计算 负载均衡 安全
云端问道-Web应用上云经典架构方案教学
本文介绍了企业业务上云的经典架构设计,涵盖用户业务现状及挑战、阿里云业务托管架构设计、方案选型配置及业务初期低门槛使用等内容。通过详细分析现有架构的问题,提出了高可用、安全、可扩展的解决方案,并提供了按量付费的低成本选项,帮助企业在业务初期顺利上云。
|
26天前
|
消息中间件 Java Kafka
实时数仓Kappa架构:从入门到实战
【11月更文挑战第24天】随着大数据技术的不断发展,企业对实时数据处理和分析的需求日益增长。实时数仓(Real-Time Data Warehouse, RTDW)应运而生,其中Kappa架构作为一种简化的数据处理架构,通过统一的流处理框架,解决了传统Lambda架构中批处理和实时处理的复杂性。本文将深入探讨Kappa架构的历史背景、业务场景、功能点、优缺点、解决的问题以及底层原理,并详细介绍如何使用Java语言快速搭建一套实时数仓。
132 4
|
2月前
|
Kubernetes Cloud Native 持续交付
云端新纪元:云原生技术重塑IT架构####
【10月更文挑战第20天】 本文深入探讨了云原生技术的兴起背景、核心理念、关键技术组件以及它如何引领现代IT架构迈向更高效、灵活与可扩展的新阶段。通过剖析Kubernetes、微服务、Docker等核心技术,本文揭示了云原生架构如何优化资源利用、加速应用开发与部署流程,并促进企业数字化转型的深度实践。 ####
|
1月前
|
运维 NoSQL Java
后端架构演进:微服务架构的优缺点与实战案例分析
【10月更文挑战第28天】本文探讨了微服务架构与单体架构的优缺点,并通过实战案例分析了微服务架构在实际应用中的表现。微服务架构具有高内聚、低耦合、独立部署等优势,但也面临分布式系统的复杂性和较高的运维成本。通过某电商平台的实际案例,展示了微服务架构在提升系统性能和团队协作效率方面的显著效果,同时也指出了其带来的挑战。
82 4
|
2月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
3月前
|
运维 持续交付 API
深入理解并实践微服务架构:从理论到实战
深入理解并实践微服务架构:从理论到实战
149 3
|
3月前
|
存储 缓存 负载均衡
亿级流量架构理论+秒杀实战系列(二)
亿级流量架构理论+秒杀实战系列(二)
|
3月前
|
运维 监控 持续交付
深入浅出:微服务架构的设计与实战
微服务,一个在软件开发领域如雷贯耳的名词,它代表着一种现代软件架构的风格。本文将通过浅显易懂的语言,带领读者从零开始了解微服务的概念、设计原则及其在实际项目中的运用。我们将一起探讨如何将一个庞大的单体应用拆分为灵活、独立、可扩展的微服务,并分享一些实践中的经验和技巧。无论你是初学者还是有一定经验的开发者,这篇文章都将为你提供新的视角和深入的理解。
87 3
|
3月前
|
SQL 缓存 运维
亿级流量架构理论+秒杀实战系列(一)
亿级流量架构理论+秒杀实战系列(一)
下一篇
DataWorks