美女与IT兽 | 汽车那么多，产生的上亿车联网访问数据怎么玩儿？

· 本文内容分为：语音版+图文版（戳这里可以了解什么是【美女与IT兽】）

· 应用场景：人工智能、物联网如何在行业中落地，产生商业价值？

· 收听/阅读时间：10分钟

· 掌握难度：★★★★★

上上上上周，“美女”为“IT”兽们准备的系列剧——《物联网&人工智能解决方案》开播。

今天的【美女与IT兽】就来放送第三集：车！联！网！

 ☟ 点开语音，用耳朵先和美女“联”起来！ ☟

-------- 我是文字版分割线 --------

各位亲爱的软友们，我是今天没有那么多前缀形容词但是可爱任性依旧的主持人Grace。

你们已经知道了，我们今天要讲的是车 联 网。

有过买车经验的人，对车联网都不陌生：除了汽车制造及销售外，还有零部件销售、汽车维修、车险、洗车、汽车美容、导航、行车记录等等服务。

庞大的汽车保有量，造就了一个巨大的车联网市场。

2013年，中国车联网业务规模大概在320亿人民币左右；

2020年，中国车联网规模预计达到1300多亿，汽车保有量大概在4500万辆左右。

车联网带动的产业价值巨大，那车联网由内部产生的上亿级别规模数据访问，我们该如何处理？

如何处理车联网产生的庞大数据量？

回答这个问题，就涉及到了车联网数据的高并发、高可用以及海量数据的计算和存储~

所以今天，我们专程请来了志玲姐姐，哦不对，是志玲GG！

微软合作伙伴灵雀云的陈志玲，来分享他们是怎么在微软云Azure上用容器技术帮助车联网企业更好地把注意力集中在自身业务上的。      

接下来我就变身志玲GG（姐姐），咱们直接拿一个客车公司的案例开8：

该客车公司：

车联网平台已接入3.8万辆客车

日均在线车辆1.7万辆

每秒请求数QPS高达6700

日均产生130GB数据

随着企业的发展，集团制定了IT三年战略规划，要求：

① 积极拥抱互联网；② 深入做好各项核心IT技术平台的搭建；③ 云计算技术平台的建设也刻不容缓！

>>>>

公司车联网现状

· IT体系多样化，IT应用（包括车联网云端产品应用）主要是以单体的烟囱式应用为主，程序包体量较大

· 面向资源交付的传统交付模式，需求确认到交付一般需要1~2天时间

· 生产、测试环境基本靠手工搭建

· 采用底层虚拟化工具进行虚拟化资源管理

>>>>

单体式的烟囱架构

单体式的烟囱架构是在原来的汽车行业IT部门比较常用的一个IT架构，这种架构主要是有几个体现：

第一，兼容性较差

车联网带来的进程比较复杂，光汽车制造厂商就有若干，每一家都有不同的电子架构、通讯协议以及数据保护等问题。

每一家汽车制造厂商的通讯协议都不一样，没有办法进行相互之间的通信。

原有的单体式架构如果要做车联网的话，整合起来的复杂程度可以想象会有多大！

第二，单体式架构代码交付效率较低

以前的汽车行业开发部门，大概1~2个月之间会做一次软件版本的更新；但因为现在车联网的到来，业务爆炸式增长，车联网所要用到的一些应用及服务大概一个星期就会做一次版本更新！

使用单体架构，他们从一个项目立项到整体环境及应用搭建，整个过程差不多要1~3周时间，对于频繁发布的需求，这种实验效率就不能满足~

第三，资源利用率较低

以前我们做一个软件工程，会新建一台虚拟机，然后会用虚拟机的方式去搭建应用。

当项目完成后，因为没有自动化，所以会忘记把资源进行回收，导致资源上的浪费。

第四，不够灵活

对应用程序来说，做任何细微的修改，整个应用都需要重新构建、重新部署！

需要等到整个应用程序完成，看到变化以后——多个开发人员再针对一个应用程序去进行开发。

并且他们这种开发是一对一式的，不能多个人针对同一款程序进行开发。

除此外，单体的应用大，单个的虚拟机大概会占用上百GB的空间，长时间的构建、部署之后，整个虚拟机的包会越来越大...越大...大…

当虚拟机需要去做迁移及一些交互的时候，因为这个包非常大，所以整个上线时间也会拖得很长...很长...长…

>>>>

基于容器技术的车联网解决方案

针对该客车公司的现状，灵雀云提供了一套围绕着容器环境的自动化平台、开发测试平台以及容器编排工具的PaaS平台解决方案。

通常，我们会用容器编排去兼容底层不同的物理机以及虚拟化环境。

比如一个企业：想用物理机环境，又想用微软Azure云；就可以使用灵雀云的这套容器编排工具，把多种不同的底层环境做整合~

同时，也可以再结合企业现有的物理网络以及存储，通过这种编排工具达到融合。

>>>>

结合该PaaS平台，为企业做微服务改造

结合这套PaaS平台，我们可以为企业做一些微服务改造，也就是现在比较流行的敏捷开发以及CSCD这一块，都可以通过这套PaaS平台去实现。

Grace乱入：比如下面这张看起来很有道理，但其实我不懂只有志铃才懂的图！

☟ ☟ ☟

好时间交回给志玲，来为我们详细818这张图是何方神圣！

上面没有提到，使用单体架构开发车联网应用，还面临一个问题——技术债务。

在整个开发过程中投入很多的开发人员，很可能会有一些开发人员中途会离职，遗留了一些技术的问题并且没有文档记录。

当部署一个新应用的时候，这里面会形成一个技术债务而导致它们的整个上线时间会拖延。

所以，在单体架构不利于车联网发展的情况下，他们考虑做一个微服务改造。

首先，可以看到下图就是他们当时采用的一个单体架构：

这个单体架构里面，他们最重的是这个EAP部分。

EAP部分是他们的一个单体式的结构应用程序，这个应用程序较大，包括一些安全、轮胎以及预防预测、燃料...等等模块，这些模块会读取下面的这个Oracle以及HBase的数据库。然后提供一些报表信息给到高层查看。

所以在这种EAP比较大的情况下，他们需要先对EAP进行解耦，然后变形，变成这种微服务的架构：

那EAP他们在改造之后会把这些模块：轮胎以及安全服务，还有预防预测进行解耦拆分，之后会用一个微服务的框架去打包。

整个平台做了改造之后，原本四个分开的组建，形成了直接使用统一一套PaaS平台去进行区域管理。

在这种内部的微服务部署里，他们会把每一个内部的微服务在任意一个区域里面去部署一个集群。

这个集群之间可以相互之间进行调用，并且也可以通过DMZ这个区域，对其他三个区域进行管理：

通过这样的微服务改造，让整个业务部门变动及开发变得更加灵活、弹性，也加快了协作效率。

微服务改造后，我们帮他做了一个内部流程梳理，梳理出来大概是这种方式：一个开发部门、一个测试部门还有运维部门，每个部门之间会通过一条流水线串起来，就像下面这图一样：

具体我就不一个节点一个节点描述了，核心是原来我们做不到的自动化环境、迭代和的交付变成可能。

最后，变身回Grace，忍不住多提一句——微软跟车厂愉快玩耍也不是一天两天了：

今天就不展开说了~

☞ 想进行拓展阅读的，直接戳这里！

别忘了，还有好玩儿哒~

最后的最后，记得吗？

上上周，我找了个地方来专门和你们一起探讨——物联网和人工智能如何落地！

来啊~继续啊~

反正有，大把时光！

☟ 长按识别以下二维码，网红在这里等你聊天！ ☟

☟  戳蓝字回顾『美女与IT兽』前十期：

第一期：美女与IT兽 | 如果能说句话、挥挥手就能把事情办了，我们为什么还要做App？

第二期：美女与IT兽 | 人类想象力的极限在哪里？

第三期：美女与IT兽 | 物联网，千万别从头做起！