物联网架构演进和微信智能设备平台开发

 

本文从场景和技术的角度去理解物联网技术和方案的演进，纯粹是个人观点，可能与主流定义稍有偏差。

 

一、物联网与物联设备

本人对物联网的理解是物联设备组成的网络，因此物联网需要两个要素，一是设备能够互联，另一个是能够组网。物联网往往又跟智能硬件概念相结合，当今物联网产品形态往往又带有无线连接的特点（有线最主要的弊端就是布线麻烦）。因此能够支持互联、组网、无线三个特点的物联设备技术就是常见的蓝牙和wifi了。蓝牙是近距离通信，穿墙能力差；而wifi距离远，可穿墙，但是功耗比较高。ZigBee其实通信距离比蓝牙远，功耗也比wifi低，看起来是比较理想的物联技术，但是ZigBee的组网能力比较差，带宽低，传输慢。ZigBee更多用在工业控制领域。

 

手机是现代社会每个人不可或缺的产品，蓝牙和wifi是手机的必备模块，所以手机是最大的物联智能设备。另外，由于人是物联网的直接使用者，因此几乎所有的物联解决方案都是围绕手机用户展开。

二、物联场景演进

1.手机直接控制物联设备架构

下图是wifi物联架构示意图：

手机连接并控制物联设备是物联技术的基础，第一种方式是手机和硬件控制设备都以client的方式连接路由器，这样手机和硬件控制设备都能获得一个动态的IP，这样手机可以通过socket通信方式来控制硬件控制设备。第二种方式是硬件控制设备带有wifi AP热点功能，手机以wifi client连接上AP，AP的IP是固定的，因此手机也能够对硬件控制设备进行控制。

 

这种物联方式一般只是演示的模型，实际应用很少。因为它的缺点显而易见，我们都知道socket通信需要知道通信对方的IP，因此手机上的APP控制硬件设备时需要填入设备的IP。第一种方式的IP是动态的，需要通过路由器的web控制页面（一般电脑连接后浏览器输入192.168.1.1）获得，这在商用应用中不可能存在。第二种方式也需要手机APP输入固定的IP，控制不同的设备就得输入不同的IP，用户体验不好。而且这种物联跟遥控没有本质的区别，不利于获取用户的信息。而获取用户的信息并提供优质服务才是物联网的核心要素。

 

2.基于独立后台服务的物联架构

下图是wifi物联架构示意图：

这种物联架构中的独立服务器是以域名的方式存在，这样可以直接解决动态IP不固定的问题。另外，这种物联架构中手机和硬件控制都需要以用户名注册和登陆的方式来访问独立服务器，并由服务器通过心跳技术来确认手机和硬件控制设备的在线状态。手机和硬件控制在服务器看来都是普通的物联设备，它们在服务器看来都具有唯一的用户ID，物联设备登陆服务器时服务器会获取到用户ID所在设备的IP地址。而手机APP控制硬件设备是以用户ID为依据进行控制，其先将用户ID送往服务器即可获取到对应的IP地址。后续控制可以通过服务器，也可以绕过服务器直接进行。

 

类似web互联架构在互联网应用广泛存在，如QQ。每台手机都以QQ账号和密码进行登录，登录后，QQ后台服务器会获知每个用户所在手机的IP地址。两个QQ用户通信时会先通过账号来获取对方的IP，并进行下一步通信。这些访问细节都已经封装在QQ客户端程序中，QQ使用者并不需要理会。用户间的通信可能会经过QQ服务器，也可能绕过服务器进行。如文字信息一般会送往QQ服务器进行信息过滤再送到对方，而QQ视频应该是双方直接通过IP进行通信。

 

这种架构在物联领域曾经是主流的架构，但是其固有的缺点也约束了它的发展壮大。这种架构中，独立服务器一般是由硬件控制设备的销售厂商开发维护的，另外其还需要向购买硬件设备的用户提供手机APP，以让用户能够进行远端的硬件控制。如小孩监护摄像头，厂商需要开发手机监护APP给用户安装使用。可以想到，用户每购买一种物联设备，都需要安装一个不同的APP。这直接影响了用户体验。用户一般是不情愿安装很多的手机APP的，不仅安全无法保障，手机布满控制APP时，要找到哪款设备对应的APP还要花时间。另外，独立服务器的厂商受限于自己的技术储备和运维能力，难以兼容支持第三方厂商的物联设备。

3.基于统一后台服务的物联架构

由第2点，我们自然可以想到，如果有一家实力超雄的厂商能够提供统一的后台服务，并被广大手机用户使用者认可愿意使用，而物联设备厂商按照统一后台服务拟定的协议进行设备生产并接入到统一的后台服务，那大一统的物联网大平台将成为可能。

 

微信公众号和微信硬件平台得益于腾讯QQ的超大用户量，很自然就承载了这种平台的实现。完全可以预见，微信将是未来物联网的重要支撑平台之一，而小米在手机、智能家居和相关行业的布局也是物联网重要支撑平台的竞争者。微信拟定统一开发的协议，让社会上不同的第三方硬件设备公司接入并获得唯一的用户ID，而小米不仅是统一后台的开发维护者，也是小米不同硬件设备的生产者，两者走的路并不一致。但两者的共同点是后台服务是统一的，两者的隶属公司都是超大体量型企业。

 

在移动互联网领域，用户基础是非常核心的要素，涉及平台相关的服务，没有超大型体量的企业很难快速构建，顶多只能在垂直领域有所作为。事实上，在微信智能硬件平台出现之前，也有一些企业构建了统一的后台服务，让第三方设备厂商接入。但受限于用户的支持，这些平台都未能为人熟知（也许是我涉猎这方面知识较少，之前有了解过一个平台，后来忘记了）。

 

这种架构的示意图如下，以微信和蓝牙设备控制为例：

微信公众平台的最核心作用就是给各种不同的外设提供接入并分配唯一的设备ID。微信智能硬件平台的设备ID分配策略包括外设厂商编码和设备编码两个部分。设备编码在统一厂商里面是唯一的。

 

手机需要关注外设厂商运维的微信公众号，才能通过该公众号的页面发出设备控制指令消息。控制消息会通过微信公众号服务器发往外设厂商独立运维的后台服务器，并由后台服务器作出处理后向外设发出控制消息，该消息会通过微信公众号服务器到手机的微信客户端，而微信控制端调用蓝牙JSAPI来控制蓝牙外设。手机微信要控制外设需要先开启蓝牙并连接上蓝牙外设。连接协议由微信硬件平台制定，称为airsys协议。

 

微信公众平台是开放平台，支持第三方服务接入，同时提供微信支付、客户接口、用户管理等九大接口供第三方服务调用。微信公众号支持开发者模式，开启后即可以接入第三方的服务。所谓微信开发即是在调用微信提供的接口的基础上完成业务逻辑开发，支持的语言是php，asp等等。如何构建第三方服务器和如何进行微信接口开发另文再述。蓝牙和wifi由于功耗的差异，其互联微信的架构也有差异，在日后的技术实现分享中会详细进行比较。

 

 

三、native APP & light APP

在第2种架构，手机要控制外设需要安装外设厂商开发的APP，是原生APP（native APP）；而在第3种架构，手机控制外设只需要关注外设厂商运维的微信公众号，微信是手机的原生APP，而每个外设厂商通过微信公众号提供的服务称为轻应用（light APP）。微信是智能手机的首选APP，用户量超大，因此基于微信统一后台服务的物联平台是未来物联网的重要支撑。