传统企业以烟囱形式交付软件。这些软件都是由各部门的各自需求产生的。软件的开发和采购都在这个有限的需求范围内展开。另一方面，面向客户的业务流程通常跨越多个部门。这两种需求之间缺乏一致性会导致工作重复，以及在每个解决方案中丢失或产生不准确的信息。后者是企业集成的主要目标。服务的概念是将面向客户的业务流程视为解决方案的要求演变而来的。 IT部门可以灵活地响应变化，从而满足变更现有流程或发明全新流程的需求。服务不是开发或采购传统意义上的“软件”，而是可以解决业务流程的自动化需求。

车辆路线问题（Vehicle Routing Problem,VRP）是一类问题的总称。它是指一定数量的客户，各自有不同数量的货物需求，配送中心向客户提供货物，由一个车队负责分送货物，组织适当的行车路线，目标是使得客户的需求得到满足，并能在一定的约束下，达到诸如路程最短、成本最小、耗费时间最少等目的。

上一篇中我们已经实现了物联网平台的一些基础功能，并通过REST API为这些功能增加了开放接口。在本篇中，我们将修改MQTT代理的配置并使其发挥出更大作用：了解WebSocket和MQTT之间的区别；为什么使用WebSocket；将WebSocket功能添加到代理中并进行测试；添加访问级别控制等安全策略

我们开始了物联网平台建设的旅程，并确定了最终目标：也就是我们首先设想了我们自己的物联网平台是什么样的以及它的高级需求内容。到目前为止，我们已经构建了一个功能齐全的服务器及基础软件。本篇文章我们将：创建时序数据库、用NODE-RED创建核心业务、创建数据库监听、构建基于REST API的消息发布和检索功能。

MQTT是一个客户端-服务器的发布/订阅消息传输协议。它是轻量级的、开放的、简单的，并且易于实现。这些特性使其非常适合在许多情况下使用，包括受限的环境，例如在机器-机器(M2M)和物联网(IoT)环境中进行通信，在这些情况下需要较小的代码占用空间和/或网络带宽非常昂贵。MQTT是一种非常轻量级的二进制类型协议，由于包开销最小，因此很容易在受限的设备上实现。这使得它成为物联网设备的理想选择。

在UBI产品的第一阶段，只借助外部静态数据及直接采集的里程等动态数据即可完成产品闭环，但如果要实施UBI产品的第二及第三阶段，则需要建立在动态数据的建模及分析之上，依据行驶时间，急加速次数，夜间行驶比例等多位数据设计UBI的定价因子，最后用年出险次数来检验输出（独立U/W因子）的可靠性，达到千人千费动态保险费率结果。

UBI(Usage Based Insurance)根据驾驶员对汽车的使用情况来设计汽车保险或者(User Behavior Insurance)根据驾驶员的驾驶行为习惯的差异来设计车险产品。UBI的原理其实很简单，即通过采集到的车辆状态数据，分析出驾驶者的驾驶习惯，划定风险等级和客户质量等级，进而提供不同的服务和保费。保费应该综合考量驾驶里程、驾驶时间、驾驶环境、驾驶方式等客观指标。

有了前文的需求列表和对物联网平台架构的详细了解，现在可以动手了。本篇涉及到：云主机配置要求；安装相关软件；创建和配置一个时序数据库。

WEB应用系统面临的挑战之一是实时通信的能力。同步通信很常见，我们可以通过HTTP请求来实现，但是使用相同的技术来实现异步通信很困难的。物联网平台的实时连接和通信是物联网解决方案和应用的关键需求。这就是我们需要使用消息代理并实现类似发布/订阅机制的地方。消息代理通常是中间件系统，通过发布/订阅机制为所有连接的应用和设备提供异步通信能力。

针对物联网铺天盖地的宣传，影响了人们对其工作原理的理解。就像1000个读者心中有1000个哈姆雷特，如果你问1000个人物联网是如何工作的，你会得到1000个不同的答案。这些答案可能太片面或者只针对某解决方案，而不是物联网本身的运作方式。让我们首先讨论一些常用的术语。物联网解决方案和物联网应用系统之间存在差异。物联网解决方案通常指端到端的产品、服务或两者的混合；而物联网应用系统通常指IT软件或移动应用程序，或两者的组合。显然，物联网解决方案比物联网系统包含更多的内容。很多业务环境、客户环境都会影响物联网解决方案。