【CSDN 编者按】随着物联网的迅速发展，场景联动越来越普遍，那么敲门砖的连接服务该如何实现呢？本文作者作为360 IoT 云连接服务技术负责人，他从结合自身的实际开发经验，详解连接服务的设计方案，以及连接服务里多机房多 *** 的落地实践。

作者 | 张超

责编 | 伍杏玲

出品 | CSDN（ID：CSDNnews）

黑客教你3分钟盗微信号

连接服务的产生是为了解决云端和终端的数据通信问题。不同的业务场景对通信的实时性、可用性和可靠性的要求都不一样，也就使得连接服务要适应各种各样的场景。

有些场景对实时性要求相对较高，对可靠性要求不是很严格，如对实时交通路 况的推送消息，该消息就要求在一定时间内送达，没有按时送达的消息，就没有推送的意义了。

而对于常见的IM场景就刚好相反的策略，用户希望接收到消息，尽管消息投递时用户不在线，这种情况下就对消息的可靠性要求提出更高的要求。

从以上常见场景出发，结合物联网的特殊性：既有业务对数据的实时性要求较高，又有设备对数据的可靠性有苛刻的要求，所以连接服务会结合不同的应用场景做出不同的应对策略。

连接服务的设计目标

根据上述的背景，我们总结了以下相关的服务设计目标：

1、实时性

满足云端能及时地将数据传达给设备，进而达到云端能够实时控制设备的目的。

2、低功耗

在一些物联网受限的设备上，功耗也是一个重要的考量标准，所以要针对功耗要求严格的设备，进行特殊的处理以满足功耗的要求。

3、多协议的支持

物联网设备类型繁多，不同的厂商、不同类型的设备可能采用不同的传输协议，所以连接服务要能够处理不同的协议，做到多协议的互通。

4、多 *** 运营商

作为和终端的接入点，保证不同 *** 运营商的用户都能正常，高效的接入服务，也是服务设计的一个重要指标，如果 *** 都不能介入的话，其它都将无从谈起。

5、多机房的部署

因为连接服务的定位是面向大量的物联网设备，而高可用性应放在一个非常重要的位置上，所以要求服务能够支持异地多机房的部署。

说到多机房的方案必须要跟具体的业务相结合才有意义，连接服务之所以能够相对较简单的实现跟我们的服务本身定位有直接关系，服务没有持久化的消息数据，只是作为一个传输通道。

另一方面，这个层面达到了多机房，但是如果具体的业务线不能达到多机房的部署（这个又是非常困难的，具体业务一般都有持久化的数据），对最终的终端来说依然是不能够达到机房宕机完全无影响的效果。

假如每个点都提高一点高可用性，整体的可用性就会越来越好。

6、多业务线

由于各业务线的重要程度不同，对数据服务质量的要求也是不同的，所以要针对不同的业务线做不同的处理，并且要做好不同业务线之间的隔离。

且不同的业务线的技术栈的不同，业务回调的实时性要求不同，也决定了我们需要采用不同的业务数据回调方式。

7、数据安全性

物联网设备的数据都是直接和硬件相关的信息，所以对数据的安全性要求比传统的互联网模式下的要求要高。

服务架构设计：

部署结构

多机房数据同步

多机房多 *** 的部署方案

由于整体服务涉及的点相对较多，不能在一篇文章中一一道来，后续有机会可以继续跟大家一起探讨其中的细节，本文侧重详解多机房多 *** 的部署方案。

为何如此设计呢？

多机房、多 *** 的部署解决了不同运营商的介入问题，以及单机房的整体宕机问题。

多运营商 *** 的问题的解决方案

问题的症结所在是不同的运营商之间有可能存在 *** 不通的情况，而这又不能通过运营商解决，所以 *** 的打通是通过云服务商购买的 *** 专线，将两个不同运营商的对外出口进行打通。

硬件上 *** 打通之后，软件上只需要在不同的出口位置部署上相应的入口点就可 以了，最简单的解决 *** 就是部署相应的 *** 转发就可以了。

公司内部使用的LVS作为 *** 的 *** ，对于外面的云服务器提供商也都有对应的 *** *** 服务。该方案解决 *** 的联通性已经完全够用了，这是业界使用的比较多的方式。我们现在对于一些流量较少的运营商，或者服务没有特殊需求，也是采用这种 *** *** 的方式。

多机房解决多活的问题

多活问题之前最有印象还是的支付宝的挖断光钎的事情。服务非常重视可用性，也将该问题提到了比较高的层面上。我们服务主题采用的是MQTT的开源协议，多机房之前采用的多MQTT 集群的桥接方式进行打通。达到预期的效果，我们需要解决以下几点问题：

1. 检查服务是否有全局的数据需求

服务的核心任务是传输消息，本身的定位是通道性质，上行数据是直接通过写入到Kafka队列中或者是通过用户提供的回调接口进行处理的。

如果失败的情况会写入到文件日志中，由于后台服务可以进行汇总收集，即使各个机房的数据传输到各个机房单独的位置。

当然也可以进行收集，所以上行数据方面是没有问题。

再看看数据的下行：云服务往设备发送数据的时候，如果发送错了机房，设备就不能正常的接收数据了，所以下行是对多机房敏感的。

2. 如何解决下行数据

根据上面的分析，下行的难点主要是解决如何给终端所在的集群发送消息，解决这个问题，现在比较常规的做法就是在用户上线的时候，将用户所在的位置记录到一个多个机房都能访问到的数据库，这样的话就能每次投递之前查询一下，就可以投递到准确的位置了。

这样的设计是 *** 情况较好的情况下是没有问题，我们的每个机房的多机器组成的集群就是采用这种结构，但是在多机房 *** 的不稳定性，现在的主流数据库基本采用主从模式的，甚至有些是不支持多机房的主从模式。

这种情况下，数据库就成为单机房单点问题了，如果业务自己做数据的同步，这样又回到了起点，解决多机房的数据问题同步问题。

基于我们的业务模型相对简单，所以我们直接采用的是信息扩散的方式，即我们收到云服务的下行指令的时候会在所有的机房进行扩散，这样就能保证终端一定能收到相应的数据，但是会存在一定的浪费操作，但是基于查询是否是本集群有效的数据，然后就丢弃是相对高效的操作， 所以目前而言扩散带来的压力，相比维护多机房的数据要容易的多。

上行和下行都打通了之后，整体的主流程就通了，下面是两层集群结构：

连接服务虽然业务简单，但是对服务稳定性和高性能有着特殊的需求，基本涉及了服务端开发的各个点，本文介绍了一下其在多机房方案下的设计和实践。

作者简介：张超，360 IoT 云连接服务技术负责人，毕业于南京大学。曾从事过游戏开发、IM 服务端开发，目前从事物联网接入层相关工作。

本文是CSDN物联网公开课《360 物联网接入层连接服务入门实践》的节选，完整视频课程观看可戳：https://t.csdnimg.cn