![](https://i-blog.csdnimg.cn/blog_migrate/ed48a0fd67adf872e127d2434a2817cf.jpeg)
前言:
今年,北京的秋雨似乎来的有点早,以至于我早已忘记自己心在何处。于是期盼着,奢望着,十一终于来了,带着亲朋好友,承载着满心的喜悦,游山玩水,远离城市的繁华,宣泄,急躁,走进了自然的宁静,淳朴,归真…… 那一刻我就在想,人世间的生老病死,喜怒哀乐,如何去记录呢,每个人作为世界上的唯一,又有何物才能与你的孤独共鸣,如何让大千世界里的花花草草,乃至于万物河洛星辰能够理解我们的情感呢?情不自禁的想起了,武则天与洛阳牡丹的神话故事,只可惜我们每个人都不是女皇,那么如何让没有生命力的物件产生生命力….看着火车上那菇凉戴的iWatch,顿时间脑海里闪过一些名词:机器人,智能设备,物联网,云计算,大数据,指纹,虹膜……..
菜单品种:
前言说的太主观了,文邹邹的像一个刚谈恋爱的姑娘,那我们接下来会为大家开小杜,这些菜品不是仅仅针对Azure的小伙伴的哈,菜单如下:物联网概括,物联网块分析,物联网现状,Azure 物联网大数据架构。
笔者,是这么认为的,接下来的菜有点苦涩。如果读者是一位刚认识物联网的同志前两道菜就够了,如果读者是物联网行业决策者这四道菜也许不怎么够,但是如果读者是一位Azure平台IoT的解决方案设计者菜品应该是够的。同样的,笔者一直认为笔者技术不怎么OK,希望读者能够来信指正。
物联网概括:
所谓“Internet of things”(IoT:物联网)并不是多新的技术。近20年前,麻省理工学院的教授对其是这样描述的:世界里“Things”(设备或传感器)连接并能共享数据。从这些设备和传感器得到的数据能给我们提供以前的遥不可及的业务洞察力。通过利用和分析这些连接设备上的数据并能给我们提供宝贵的见解,进而来阐释什么是物联网。
今天,物联网,正处于一个拐点。尽管技术专家几十年来预期数十亿智能连接设备的世界,多重因素近期融合,加快在类似我们这样的企业通过物联网做解决方案。那么物联网的架构如何呢?接下来我们先从传统的IoT架构谈起。
传统的物联网架构:
一个控制台应用程序(设备端),它可以将用户活动信息和日志送入云端服务器同样的在实时仪表板呈现。因此,它的主要部分在于遥测,我们今天将要重点讨论。
使用Kafka(Azure: EventHubs)在HDInsight存储通过流分析(Storm算法逻辑)建立物联网信息筛选管道,进而存到存储账户(磁盘)
例如:记录每台服务器的分析,抢遥测数据等
采用这样架构我们有三大优势:
1)提高效率 – 因为了解不同Online业务的资产和设备的运行状况可能是一个挑战。我们能够轻松地连接和监控这些资产和设备,我们可以跟踪它们随时间的状态和性能。我们可以制定规则和警报通知的团队或部门在您的业务需要的时候采取行动,这样你就可以改善业务流程,提高效率。
2)创新性 – “互联网+”喊了这么多年,想转型的企业也是进入新行业一个机遇进而适应社会继续蓬勃发展。不是我们看到的趋势,只是因为她们的出现。预见,才能遇见!我们将能够更好地应对机遇和威胁。通过监测和实时从多个来源的分析数据,可以让我们的企业进行创新,分析哪一部分部分出了状况。
3)转变我们的业务 - 数据是唯一性的,DT时代,每个人都知道,直到我们把它变成见解和对业务的影响。当我们从资产监控利用数据,并使用先进的数据分析,以提高决策和创新,同样我们可以看到潜在的创建通过数据洞察新的业务模式和收入来源,以实现业务转型时,才知道我们拥有数据的重要性。
物联网块分析:
-
设备端:
Note:笔者在今年9月份参加MS的IoT实验,参加宾客有北邮研究IoT的学者还有行业践行者翼动科技等,大家一起深入的交流,受益匪浅。上图是Ivan当时Share的PPT,今天我只是一个传递者,把这些Share给大家。
设备端是数据的采集源,在IoT场景流里最前端的,能够给我们看到的,能够展现的事物,通常包括基于(蓝牙,红外,Zigbee)近场通讯的设备:传感器,智能穿戴设备等以及基于IP的远场通讯设备:手机,电脑,WIFI设备等。一般情况下近场通讯设备底层控制都是C写的,高级一点的可以通过Python去控制。例如:Pebble(智能手表类似于iWatch)漂亮的表盘,以及心跳数据,户外运动数据都是通关C做控制传感器实现的。例如:其通过蓝牙与手机相连实现数据共享,手机来电第一时间在手表呈现。这些我们今天不做过深的讨论,我们只讨论大概不准备涉入太深的技术细节。
-
网关:
目标设备的连接,以及实现异构设备的通讯都是通过网关实现的。
AllJoyn这个开源的项目给IoT设备端互联带来了新的机遇,我也相信好多厂商是基于AllJoyn做了好多解决方案,做了好多产品。这里呢,主要是有一个云网关,另一个是现场网关。
如果大家后端不用云的话,那么云网关也没有什么大的意义。接下我们说下这几个网关的概念,以及在Azure上前端设备如何通过云连接的。
上图是4种场景,4种方式实现Device到云端的连接,虽然上图是Microsoft Azure的,但是是通用的,无论后端是AWS,阿里云也好,腾讯云,或者是华为云也罢,都绕不过去前端这一块。理论上逻辑都是一样的无论用哪一家云,都会面临前面的这几种方式。
我们先搞清楚这些逻辑哈,因为设备数据的安全性以及权限性是客户最最关心的问题。所以呢,IoT Client有一个很大的作用是保证安全性的,例如2和4的对比,4有VPN做安全保证,那么Filed Gateway(现场网关),Cloud Gateway(云网关),Custom Cloud Gateway(自定义云网关)是什么作用呢?
FiledGateway(现场网关):
现场网关是一个专门的设备,器具或通用软件,作为一个通信控制者,作为本地设备控制系统和设备的数据处理中心。现场网关可以执行向目标设备本地处理和控制功能;在另一侧它可以过滤或聚集设备遥测,从而减少被转移到云后端的数据量。
现场网关的范围包括外地网关本身及其连接的所有设备。顾名思义,现场网关充当外部专用的数据处理设备,并且通常与设备并行的。
现场网关不仅仅是一个单纯的路由器,同样在于它具有在管理访问和信息流的作用。它是一个应用程序处理的实体和网络连接或会话端子。例如,在这种情况下的网关可辅助设备配置,数据滤波,配料和聚集,数据的缓冲,协议翻译和事件的规则处理。 NAT设备或防火墙,与此相反,没有资格作为现场网关,因为它们是不明确的连接或会话端子,而是通过它们可以建立的连接或(拒绝)会话。
CloudGateway(云网关):
云网关是基于云的架构,可实现远程通讯功能,并从设备或现场网关,云网关通常提供混合通信模型。遥测和从设备之外的消息被输入到云和消息交换就是通过云网关实现的,其实云网关再云端就是几台VM,只是里面有不同的Role罢了。
CustomCloud Gateway(自定义云网关)
自定义的云网关主要实现协议适配和一般到达云网关通信端点之前,此外,最大的作用是定制加工消息,例如消息转换或压缩/解压缩,
同样的自定义云网关可以实现自定义身份验证或依靠云网关的认证和授权功能。它也可以在是在云端,以Azure为例:就像是Cloud Service下面的Web Role(VM),把现场设备接过来的消息接过来,压缩存储在Blob里。
-
数据接收与处理及展现
数据接收和处理一般都是基于云平台的,
数据接收:
例如:Azure上有一个类似于Kafka的产品Event hub,IoT Hub(Event hub加强版对于设备管理有优势),可以高并发的处理设备端的消息,消息格式一般为Json,每条消息最好不要超过256KB,消息分类可以通过不同的Event hub来区分,如果业务不大可以使用前段的静态哈希函数F(x),通过分区键来放到不同的分区,分区有容错机制我们几乎不用担心信息的缺失性。IoT Hub我们就不做讨论了,对于消息的处理机制和Event Hub是一样的,多了更多的Devices的管理,还支持信息的双向性,例如:指令下发。
数据的处理:
前端数据我们已经采集到位,如何去处理呢?给谁去处理?谁要做处理?先从拿数据作为探讨起点:以Event Hub为例:后端我们建立消费组,不通的业务部门用不同的Event hub消费组,这样做的目的是,其一避免信息打架,提高效率,另一方面是负载的作用,因为每一个消费组对应是Event hub的所有的分区,是一对多的关系,比放到一个消费组要好许多。消费组:做解决方案一定要用起来,后端很总要的一技术个概念。
数据已经取出来了,如何处理呢?如何分类呢?传统的我们可以用Storm写一些业务逻辑来处理,但是呢,Azure平台上有一个类似的流分析,能对数据实时做处理,其业务逻辑,一般是类SQL的语句,但是呢?那么问题来了,如果Event hub接收的消息不是很规范的Json的话,或者比较复杂,那么不建议使用流分析,还是建议使用Storm。
数据呈现:
数据的呈现,无非是图形化的方式,这里就不做深入探讨了,可以用PowerBI,当然也可以自己开发Portal然后把数据传到SQL里然后通过Portal实时呈现。这里不是重点。
物联网现状:
今天,物联网,正处于一个拐点。在我们身边,无处不在,智能穿戴设备等等。其它就不说了,主要在这几大块中: 设备端,数据采集端,云平台分析处理端。一个严峻的问题我们能做什么,我也相信就像微信就是一个第三方的物联网平台,以后还可以做的很多很多,
大家更喜欢习惯性的选择微信平台作为入口….那么Azure能做什么呢?我是一直这么认为的:Azure是一个平台,它给我们提供柴米油盐酱醋,至于能做什么全靠厨师了,嘿嘿,不要说Azure有个味道坑太酸,最后发现是自己盐醋放的太多,嘿嘿。同样的我们自己在物联网行业能做什么?我觉得合作共赢才是最好的决策。
Azure物联网大数据架构比较复杂,后期我会更新的。谢谢你能阅读到这里。
技术参考文献:
Azure
https://www.azure.cn/documentation
TCP
http://tools.ietf.org/html/rfc793
UDP
http://tools.ietf.org/html/rfc768
AMQP
http://www.amqp.org/
AMQP Core
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html
MQTT
http://mqtt.org/ http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
CoAP
http://en.wikipedia.org/wiki/Constrained_Application_Protocol
Alljoyn
https://zh.wikipedia.org/wiki/AllJoyn
OPC Foundation
https://opcfoundation.org/ http://en.wikipedia.org/wiki/OPC_Foundation
WebSockets
http://en.wikipedia.org/wiki/WebSockets
TLS
http://tools.ietf.org/html/rfc5246
http://tools.ietf.org/html/rfc4279
Azure VPN
http://azure.microsoft.com/en-us/services/virtual-network/
ExpressRoute
http://azure.microsoft.com/en-us/services/expressroute/
Azure API applications
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Azure Search
https://azure.microsoft.com/en-us/documentation/articles/search-what-is-azure-search/
Bing Maps
http://msdn.microsoft.com/en-us/library/ff428643.aspx
Service Fabric
http://azure.microsoft.com/en-us/campaigns/service-fabric/
Akka
http://akka.io/
Akka.Net
http://getakka.net/
MapReduce
http://en.wikipedia.org/wiki/MapReduce
Pig
http://en.wikipedia.org/wiki/Pig_(programming_tool)
Apache Storm
http://storm.incubator.apache.org/
Apache Spark
http://spark.apache.org/
Apache HBase
http://hbase.apache.org/
Apache Hadoop
http://hadoop.apache.org/
Apache Hive
http://hive.apache.org/
Apache Mahout
http://mahout.apache.org/
CAP Theorem
https://en.wikipedia.org/wiki/CAP_theorem
Azure Business Continuity TechnicalGuidance
https://msdn.microsoft.com/library/azure/hh873027.aspx
HADR for Azure applications
https://msdn.microsoft.com/library/azure/dn251004.aspx
Securing your Internet of Things from theground up
http://download.microsoft.com/download/8/C/4/8C4DEF9B-041B-47F3-AD7F-52F391B1D0AB/Securing_your_Internet_of_Things_from_the_ground_up_white_paper_EN_US.pdf