All Posts

从TDengine的开源说起技术选型

如果一艘快艇足够承载下你的所有货物到达彼岸,那么你不需要使用一艘轮船出行。产品设计和技术选型也是一样,我们经常会说:“我需要一个能够处理百万规模并发读写操作的,低延时,高可用的系统。” 如果按照这样的需求去设计系统,你可能得到的是一个设计复杂,代价昂贵的通用方案。但是如果仔细分析一下需求,你可能省略了需求背后的一些前提条件,比如真实的需求可能是这样的:“我需要一个能够处理百万规模的并发(只是理论峰值,平均情况小于10万并发)读写操作(读写比例1:9,只有追加写,没有修改操作)的低延时,高可用的(可以接受一定程度数据不一致性的)系统。” 那么你可能可以为这个特定的需求设计一个简单的,高效又低成本的系统。 做技术选型时,我们不会单纯的说A方案比B方案好,只是在解决特定的问题上,A方案比B方案更合适,选择了A方案的同时也意味着接受A方案里那些不如B方案的地方。在特定领域问题上的优化和定制方案往往能够取胜于解决更多领域问题的通用方案。最近涛思数据开源的TDengine也是这样一个针对专用领域的优化方案,TDengine的官方介绍如下: “TDengine是一个针对物联网,车联网和工业物联网领域优化的开源大数据平台。除了是一个速度快10倍的时序数据库,它还提供了缓存,流式计算,消息队列和其他以减少开发和运维的复杂度和成本的功能。” 在TDengine的官网文档上我们可以了解到这是一个针对IOT领域数据特性优化的强大的大数据计算平台。最近花了一些时间去熟悉这个开源项目的文档和代码,聊聊在做IOT时序数据库这方面的技术选型时使用TDengine或者其他产品一些可能需要考虑的点。 版本的选择 TDengine提供了三个版本的产品:社区版,企业版以及云版本。 其中社区版是本次开源的 单机版本 ,根据官方的介绍社区版拥有TDengine的大部分核心功能,是 处理中小规模数据 的理想平台。 企业版 在社区版的基础上新增了 高可用、横行扩展 等集群功能,内置 异地副本复制 功能,可用性达运营商级服务等级,提供 更强大的运维管理工具 。 而云版本则为运行在AWS/阿里云上托管的企业版,按月付费省掉了你自己部署和系统运维的工作。 类似的,行业里另一个比较流行的开源时序数据库InfluxDB也同样提供了三个版本的选择: 开源的单机版,商业的集群版以及云版本,功能对比如下图。 开源协议的考虑 TDengine的社区版本 基于AGPL 3.

停车场寻车难?蓝牙5.1提供的新思路

生活中我们常常有这样的体验,开车到了一个商场停车场停车之后,由于在忙其他的事情,常常导致“短暂性失忆”而忘记了车停在了哪里。对于不少缺乏“路感”的朋友,停车场对于他们来说是一个大迷宫,找车浪费个半小时是家常便饭的事情。 传统的通过车钥匙控制鸣笛的方式可以在较短距离寻车,车钥匙通过RFID的方式发送指令到车,信号较好的感应区间是在10多米左右(空旷场地可以稍远)。 进入智能网联汽车时代,为了给车主提供更好的便利性,避免人肉记住停车位的麻烦,越来越多的寻车方式被挖掘——懒惰是科技进步的驱动力。 一方面联网后的汽车可以将自己的GPS位置信息上传至云端,以便用户在手机APP上查看自己的车辆位置。另一方面,基于远程控制的鸣笛闪灯功能解除了车钥匙鸣笛在距离方面的局限性。 然而,基于卫星定位的GPS只适合车辆在室外的场景,到了封闭的室内停车场只能提供车辆的大致位置,误差可达数百米。而对于一些地下停车场,由于没有蜂窝网络信号的覆盖,远程鸣笛控制功能则可能处于失效状态。 现在也有部分大型的商场停车场安装上了基于摄像头的车辆位置识别方案。比如北京朝阳大悦城,微信关注商场公众号并绑定车牌信息,车辆在停车场停车后,停车场的摄像头识别到车牌信息便会给你的微信推送一条停车位置的信息,便于你稍后寻车。 在不依赖于停车场建设的通用寻车方案方面,部分智能行车记录仪产品提供了基于摄像头的远程实时查看功能方便寻车,然而这同样也较大依赖于蜂窝网络的信号覆盖。 蓝牙5标准的发布以及今年一月份新发布的蓝牙5.

端与云的融合

端、管、云,物联网系统的三个主要构成元素,各自技术在高速发展的同时也在不断的影响着现代物联网系统的设计。 端,我们指终端设备,包含手机,车辆,智能家居设备等与用户直接交互的设备; 管,我们指通讯管道,包含有线/无线网络等连接端与与云,端与端进行数据交换的通道; 云,我们指运行在各地数据中心的远程服务器集群及其提供的服务; 传统端与云在软件设计方面有不同的专注点,端软件设计的重点在于思考在受限的内存和算力下如何优化单机程序;云软件设计的重点是在于如何设计可扩展的分布式计算使用多机来处理大规模的服务请求。 物联网系统里数据的产生者是各式各样的传感器,包含音频,摄像头视频,加速度传感器,温湿度传感器等。这些每时每刻都在自动产生的传感器数据,相对于移动互联网应用中用户在APP上手动交互而产生的数据会大上几个数量级。庞大的传感器数据量使得将所有原始数据传回云端处理非常困难,对终端算力和通讯管道的提速提出了要求。 近几年来终端算力的提升,使得我们可以把更多的计算放在终端设备,只与云端交换处理后的中间或结果数据,减少与云端原始数据交换。一方面减少了服务响应延时,另一方面也可以规避一些隐私数据的传输。终端算力的提升,越来越多的云端技术可以被引入到终端中。现代汽车电子中,整车电子系统发展趋向于由娱乐域和驾驶域等若干高性能计算机构成,高性能计算机之间通过以太网通讯形成了一个车载的分布式系统,一些原来在云端被验证的分布式技术开始被应用到车内。 另一方面,通讯管道的发展,4G网络的普及和即将到来的超10Gbps的理论传输速度的5G网络使得端与云的分工也在不断发生着变化。管道的提速,端与云之间可以有更高频的近实时数据交互。 端云融合在车联网的场景下, 车作为一个高复杂度的终端,与云之间也有着不断融合的趋势。车载以太网主干和5G的发展促使车与云融合的过程中会产生了一些新的设计思路,这里讨论一种车联网的整车软件架构,我们称之为C/S/ES(Client-Server-EmbeddedServer)架构,如下图。 C/S/ES架构在传统的C/S(客户端/服务器)架构中在逻辑上引入了车内嵌入式服务器ES(Embedded Server)的模块,将车内的计算与人机交互界面分离,把原来一部分在车载客户端的计算逻辑移到了ES模块中。实际部署中 客户端软件和ES可以是运行在同一个硬件模块上也可以是运行在不同的硬件模块上 ,e.

聊起车联网技术时,我们可能想说什么

1981年世界上第一个车载导航系统被集成在Honda汽车上,30多年来,随着芯片、通信和互联网技术的快速发展,汽车软件发生着巨大的变化。 随着越来越多的传感器,摄像头,自动驾驶等新技术被集成进汽车,车辆每时每刻都在产生着大量的数据。基于CAN总线架构的汽车,一辆车每小时可以产生 1GB左右的车辆信号数据,随着信息娱乐系统的发展,用车过程中语音视频数据的增加,一辆车每小时产生的数据量会增长至 20GB。支持更大传输带宽的车载以太网架构技术被引入到的汽车中,今天的智能汽车,已经俨然成为了装在四个轮子上的数据中心。 车联网无缝地集成了车辆与环境周边系统,将车辆用户与数字世界连接在一起。1996年,通用汽车通过旗下OnStar产品发布了第一个车联网功能 E-Call - 当车辆碰撞或其他紧急情况发生时,自动帮助用户拨通 呼叫中心,并将车辆位置等信息传输到呼叫中心坐席系统以便及时对用户实施救援。 由于早期昂贵的技术成本,在很长的一段时间里,车联网功能在一些高端车辆中被作为可选的增值功能销售,用户量发展缓慢。近几年,随着电动车技术的发展,国家相关安全法规的实施,车联网功能逐渐成为了电动车的标配功能。随着Tesla 2012年推出第一款带有OTA (Over The Air) 功能的 Model S 电动车,新的功能特性可以通过OTA软件不断地发布给到用户,汽车不再是交付后便失去生命力的产品,汽车架构进入了软件定义汽车的时代。 今天我们聊起车联网技术时,我们发现大家处于一个非常好的时机。过去互联网及移动互联网的快速发展,大规模软件系统技术具备了较高的成熟度,越来越多的在互联网行业被大量验证过的技术被引入到车联网中来,赋能智能汽车。笔者最近尝试在整理车联网端到端涉及的软件技术脑图,从服务、云端、整车电子架构、通信技术、整车软件平台和自动驾驶等方面去看,当我们聊起车联网技术时,可能会想到的东西。  车联网服务 车联网服务包含交通安全,交通效率,经济效率,交互及便捷性,信息娱乐服务,移动数字生活等多个方面的服务。车联万物的场景正在逐步的成为现实。在不久的将来,你用车的场景会是在上车的瞬间,车上的智能助理已经从你的移动设备日历里同步了本次行程信息,预先设置好了用车环境和自动驾驶路线,行程中附近车辆及路侧设备发送过来的信息会被实时显示在抬头显示屏上,智能助理会给你播报你感兴趣的新闻,用车全过程就像在家里一样享用属于自己的私人生活空间。 车联网云 车联网服务在云端的技术栈与其他互联网业务的技术架构没有太大区别。微服务架构解耦了不同业务的复杂性,适用于车联网服务的场景。不同于移动互联网应用里主要由用户手动产生的数据,车联网中的数据是由车辆每时每刻在产生,这个特性对云端支持高并发连接数和高吞吐量提出了更高要求,比如连接着100万辆车的平台,假设每辆车以5秒的间隔向云端上报数据,那么意味着云端平均每秒需要处理20万个数据的写入请求。 整车电子架构、通信技术及软件平台 进入软件定义汽车的时代,车辆拥有的全部功能由车上的软件决定,并能通过OTA及App Store安装的方式实现增长。软件定义汽车的实现对整车的电子架构提出了更高的要求。整车电子架构不再是传统的特定ECU执行特定功能的“功能机”设计,而是转为面向通用计算的“智能机”设计:需要对整车平台抽象出若干计算电脑,并使得传感器、执行器等输入输出设备能够被计算电脑所访问。计算电脑作为汽车软件运行的基础需具备高可用、可扩展等特点。 高级辅助驾驶及自动驾驶 目前一些L2的高级辅助驾驶功能正在越来越多的商用车上得到应用,而L4的自动驾驶则在一些封闭区域(比如码头,园区)的特定场景下开始得到应用。L4及L5级别的自动驾驶在商用车上的广泛应用目前除了技术方面的改进外,还面临着其他方面的一些挑战需要时间来解决:成本方面、与非自动驾驶车辆的并存、法律责任界定、失业问题等。 以上是笔者在车联网领域学习过程中一些 初浅的 见解,欢迎有兴趣的同学一起交流。 文中提及的高清脑图下载请联系本公众号。 End