“这个平台真的稳定吗？”​

云服务厂商的IoT解决方案“廉价、高效、安全”，但当谷歌发出公告将要关闭IoT Core时，任何在享受其服务的人都需要问问这个问题。

当然，我不仅仅是在说谷歌。公共云的供应商是很苛刻的，他们以低价提供额余功能来吸引客户，使其股价大涨；但当经济不景气的时候，他们又会扔掉这种对于他们来说“纯烧钱”的服务。此时客户就会突然意识到：他们的物联网设备需要一个“新家”。他们的处境宛如“被房东赶出出租公寓的租客”。

有没有一种既能享受这些优质服务，又不担心“搬家”窘状的办法呢？没错，我们有这个办法。

Shifu

是的，Shifu是一个新的IoT平台。

Shifu拥有Google IoT Core的一切功能，而且平台之间的转换快速便捷，只需“按一下开关”就能轻松实现。

1. 设备管理和控制：Shifu提供了一个HTTP接口，用户可以通过REST API与设备进行交互。Shifu与现有协议都是兼容的，因此你不用记住所有协议。
2. 安全：Shifu可以完全在本地使用高度安全的用户认证系统。如果你不太信任互联网，那么你可以在不联网的情况下使用Shifu！
3. 遥测收集：这是Shifu的旗舰功能之一。通过该功能你可以指定任何你想收集的东西。只要告诉Shifu遥测的名字和数据输出的目的地，然后就可以坐等了。

好了，这些理由已经能够证明为什么Shifu能成为Google IoT Core的一个很好替代品。我知道这还不够，这些功能只能让它成为又一个新的物联网平台。但以下特点就能使得Shifu成为超越谷歌的新一代IoT平台了：

4. 数字孪生：每个设备实际上都是运行在Shifu中的容器化服务。因此，Shifu是世界上最分离的物联网平台——从来没有单点故障，每个设备都是独立的，就像现实生活中一样。
5. 灵活性和可扩展性：Shifu利用Kubernetes来确保所有系统资源都得到有效管理，并随时可扩展。
6. 最容易安装：Shifu是世界上最容易使用的物联网平台。你不需要注册帐户（但如果你愿意，也可以注册）就可以使用Shifu。一切都已经被容器化了。你只需要一个简单的动作就可以让一切运行起来；如果你不喜欢写一行命令，有一个功能齐全的Web UI等着你去玩。
7. 多重云：除了可以享受企业内部的Shifu框架，Multiple Clouds还拥有Cloud功能（如果你也喜欢）。Shifu Cloud与公共云无关——没有任何一个云提供商会是Shifu的单点故障。

Shifu在使你“重返自由”的同时，仍然拥有着“无痛、易用、on-prem和安全”等特性。在Shifu消除了所有迷雾过后，你对物联网星球的看法将会像你在那些浪漫电影中,特别是像那些在新西兰拍摄的电影里看到的湖泊一样清晰。

作为物联网爱好者，你曾使用过数以百万计的设备管理工具。 虽然它们在设备管理这方面都做的很好，但与此同时，你也“饱受折磨”——它们使用起来太复杂了！

这种“方便与折磨”并存其实是合理的。 因为一个典型的物联网环境会有成吨的设备，与之相随的就是容易混乱的记忆和容易打乱的线程，这就是巨石诅咒（curse of a monolith）。最好能将这两者分开，但分开又会使编码变得困难，所以程序员们需要在易于编码和易于使用之间进行权衡。当然，程序员可不会让自己的生活不好过。

那么就应该让用户来背负重担吗？在此之前，答案可能是肯定的，因为这个问题还没有很好的解决方案。但现在有了Shifu，再也不用在两者之间权衡了——我们能够鱼和熊掌兼得。

把你的设备装进pod里​

你可能已经明白了——Shifu 使用的是 Kubernetes。K8s 是一个很棒的 devops 工具，用于跨多个 pod 管理系统资源和需求。通过大规模云我们已经知道了，K8s 非常适合解耦——凭借其强大的容器支持，现在每个 pod 完全分离，但仍然能够协调，所以非常适合物联网的管理。

设备管理是设备和管理的结合。 因为你已经有了设备，所以现在你只需要管理，而 K8s 就是为管理而生的。你只需要告诉 K8s：“小伙子，你需要管理的就是那些东西，你可以开工了！” 那么如何才能通知K8s呢？ 答案是——用Shifu！

Shifu 让 K8s 成为了物联网原生平台。你只需要告诉 Shifu 要管理的设备是什么、使用的协议名称、以及它支持的操作列表，将这三种类型的信息写入一个简单的配置文件中，你的任务就完成了，剩余的事情就交给 Shifu。Shifu会自动读取配置、构建支持的驱动程序、生成容器、创建 pod 并让告知 K8s。 所以 K8s 并不知道它在管理是什么——它们仍然是 pod，但 Shifu 知道每个 pod 实际上是一个虚拟设备，与真实设备绑定在一起。

在你经历了这么多不同的“高级设备管理工具”之后，这种开箱即用的体验是你应得的。通过Pod，你能够轻松高效地管理好你的设备。

引言​

看到MQTT，你可能认为是“MQ Telemetry Transport”的缩写。 这个说法放在以前可能是对的，但现在就有待商榷了。**目前的MQTT不是任何单词的缩写，就单指MQTT。**请注意，MQ也不是首字母缩写词，而是IBM旗下一产品的名称，并不代表“Message Queue”。 背后的原因是该协议的应用已经不限于遥测传输。MQTT现在已经将目光放在了整个物联网领域。在成为物联网通信领域黄金标准的道路上，MQTT正吸引着全球越来越多用户的关注。然而，目前只有少数在线资源可以为我们提供该协议的完整指南，这也是作者撰写本系列文章的目的——为任何想深入了解IoT星球的人提供MQTT的详细介绍：

1. 概述
2. Pub/Sub的工作原理
3. 保证QoS
4. 将MQTT连接到Kafka
5. 使用MQTT与真实设备进行交互

本文是MQTT简介系列的第一篇。通过本文，我们将快速浏览MQTT的一些基本术语。

MQTT工作原理简介​

假设有如下设置：

• 发布者：我们房间里的一支温度计，发布带有“room1”标签的“温度”话题。
• 订阅者：我们房间里的一台笔记本电脑，订阅带有标签“room1”的“温度”话题。
• 中间人：在我们房间的服务器上运行。
• 话题：“温度”。 在“温度”话题下标记：“room1”。

温度消息的完整路径是：

1. 温度计向中间人发布话题“温度”和标签“room1”的温度消息。
2. 中间人检查谁订阅了话题和标签，然后将消息路由到笔记本电脑。
3. 笔记本电脑收到消息。

Pub/Sub​

在典型的客户端 - 服务器模式下，客户端和服务器需要相互了解，是强耦合系统示例。可问题是，服务器本身需要维护客户端注册表，这使得它变得复杂、容易出错并且不知何故会出现单点故障。

MQTT则使用Pub/Sub模式来解耦这个系统。

高级架构由三个组件组成：发布者——中间人——订阅者。发布者发布话题，订阅者订阅话题，而中间人则介于两者之间，主要负责过滤消息并确保订阅者只得到它想要的消息。我们也称MQTT中间人的发布者和订阅者为“客户”，表示他们都是中间人的客户； 因此，在此定义中，“服务器”是中间人。 中间人通过话题和话题下的标签过滤消息。话题是可用于对消息进行分组的“类型”或“类”，标签是话题的“子类型”或“子类”。 一旦发布者在话题和/或标签下向中间人发布消息，只有订阅相同话题和/或标签的订阅者才能从中间人获取消息。在这种情况下，发布者和订阅者都需要知道他们正在处理的话题和/或标签。

消息队列​

MQTT可以被视为完全为物联网消息传递量身定制的消息队列。与Kafka等分布式系统中的传统消息队列系统相比，MQTT在空间和时间上都具有轻量级和更快速的特点。 MQTT更倾向于使用内存来存储吞吐量非常低的消息，并要求任何实现都支持动态添加/删除话题，以实现超低延迟和高灵活性。 你始终可以将MQTT与其他消息队列（如 Kafka）连接起来使用。

服务质量 (QoS)​

顾名思义，QoS定义了中间人为客户（发布者和订阅者）服务的工作质量。客户端在与中间人通信时需要告诉中间人QoS的级别。

QoS共有3个级别：

0. 或“最多一次”——消息可以传递，也可不传递，但不应有重复：

• 发布者的消息应该传递给中间人一次或零次；
• 订阅者将从中间人那里收到消息一次或零次；

1. 或“至少一次”——必须传递消息，但可以重复：

• 发布者的消息应该传递给中间人一次或多次；
• 订阅者将从中间人那里收到一次或多次消息；

2. 或“刚好一次”——必须传递消息，并且只能传递一次：

• 发布者的消息必须传递给中间人一次；
• 订阅者必须从中间人那里获得一次消息。

**“异步”是Pub/Sub模式的核心。**Pub/Sub机制将消息发送者和接收者（订阅者）分离，实现了非等待的性质：每项服务现在只需要做自己的工作。这恰好也是对科技公司、金融机构、政府部门、足球队等多人团体中人际关系的完美解释。

发布（Pub）​

代理（Broker）并不关心数据的具体内容（即有效载荷），只要其中包含主题(Topic)，这样代理就可以将其转发给订阅者。

发布消息​

一个典型的MQTT 发布消息需要包括以下字段：

packetId：数据包的标识符。当消息被设置为发送时（即Qos>0），代理需要用这个标识符来定位要重新发送的消息。

topicName：主题名，其格式类似于Linux文件系统的目录。例如，我们可以将主题名设置为“shimokitazawa/beast/tadokoro”。

Qos：发布消息的服务质量等级。Qos通常有三个等级：至多一次 (0)；至少一次 (1)；只有一次 (2)。

retainFlag：当被设置为true时，代理将缓存上条主题消息；当有新订阅者出现时，代理会自动将该消息发送给他。

payload：消息的内容主体，格式不限。

dupFlag：当被设置为true时，则表示该消息是重复发送的。当Qos大于0时，代理会使用该标识符。

代理的工作内容​

代理的工作很简单：代理收到消息后，开始读取Qos等级，并根据Qos将消息发送给订阅者。请注意，当消息被送到代理那里后，发布者的工作就完成了，任何剩余的工作都与发布者无关。

订阅（Sub）​

订阅者的工作就更简单了。订阅者告诉代理：“嘿，伙计，我订阅了这个主题，如果你收到这个主题的消息，就把它发给我”。

订阅消息​

一个典型的MQTT 订阅消息需要包括以下字段：

packetId：它还是消息包的标识符。

以及一个主题和Qos组合列表：

qos_n：发给订阅者的预期主题Qos，该Qos作为订阅者接受该主题的最大Qos。例如，如果消息的Qos=2，但subscriber_a中主题的最大Qos=1，那么消息将以Qos=1的方式发送给该订阅者。

topic_n：订阅者所订阅的主题。

代理的工作内容​

在收到订阅消息后，代理将向订阅者返回一条SUBACK消息，其中包括订阅者的元数据（即最大QOS）。一旦订阅者收到SUBACK信息，他们之间的通信就建立了。

取消订阅​

要想退订主题，订阅者只需发送一条UNSUBSCRIBE消息，并注明要退订的主题（当然，UNSUBSCRIBE消息还是需要一个packetId），代理也将返回一条UNSUBACK消息给订阅者。

结论​

以上就是MQTT发布者、代理和订阅者在Pub/Sub模式下的工作方式。因为MQTT只是一个协议，我们需要定义代理如何识别订阅者——你可以只维护内存表来做，也可以选择用更复杂的方式来做，比如用多个ECC内存来处理一个受分布式锁定机制保护的复制容器化服务，从而来维护内存表。

相信你已经对MQTT的QoS（Quality of Service，服务质量）有了个大概印象——用于指示如何传递消息；共有3个QoS级别和2种类型的消息。

快速回顾

3个QoS级别： 0-最多一次 1-至少一次 2-正好一次

2种交付方式：

1. 发布者对中间人
2. 中间人对订阅者

此外，在上一篇文章中，我们已经讨论了从订阅者发送至中间人的订阅消息；它定义了用户可以接受的最大QoS级别，任何具有更高级别的消息都将被降低至订阅该级别用户能承受的最大级别。

0-最多一次​

我们常能通过事物的名字来判断它是做什么的。因此，如果你的QoS级别为0，则消息要么被传递一次，要么不传递——只尝试一次，并且不重试。发了就算完。哇，非常异步。

1-至少一次​

假设我要传递某条信息，则会疯狂地进行重试。发送消息的人将继续重复发送消息，直到它从接收者那里收到PUBACK（由packetId组成，仅此而已）。

还记得我们在发布消息中的dupFlag字段吗？下面就来看看如何使用——在初次尝试后的每次重试中，这个dupFlag都会被设置为true，以此来通知收件人这可能是一条重复消息。

2-刚好一次​

确保消息被传递，并且确保只传递一次。这是最慢也是最复杂的QoS级别。以下为QoS 2消息发送的整个生命周期：

首先，发送方（发布者或中间人）将发布消息发送给接收方（中间人或订阅者）。“咚咚！”

其次，一旦接收者收到发布消息，它就向发送者发送PUBREC消息，表示“我认出了这个消息，是QoS 2，以此句话为证，不要再发了！”在接收PUBREC之前，发送方仍然会不断重试向接收方发送带有dupFlag==true的发布消息。

再次，在收到PUBREC后，发送方便得知消息已经被传递。因为它知道QoS消息是正好一次，所以它将丢弃该消息并停止疯狂重试行为，然后将PUBREL发送给接收者，说“我保证我不会再发这条信息了。”

最后，当PUBREL到达时，接收方将PUBCOMP发送回发送方，生命周期结束。

这与我们在TCP中的握手方式非常相似——使用一些额外的步骤来确保所有相关方都了解当前的状态。

如果无法访问接收方，发送方会将消息保存在本地队列中，以便在接收方在线时发送消息。

本篇文章，我们将直接讨论主题的结构以及怎样定义主题。

主题的定义

主题可以看作是一个字符串，其格式类似Linux文件系统的命名方式。平时，我们会从左到右、从高到低地描述一个主题的多个层次，就像下面这样：“earth/antarctica/elderthings/shoggoth”。其中，“earth”、 “antarctica”、 “elderthings”和 “shoggoth” 分别是上述主题的四个层次。

订阅

订阅者需要告诉代理自己订阅的主题是什么，而MQTT让我们可以自由地使用通配符来同时匹配多个主题。

+：单层通配符 #: 单层和多层通配符 (该通配符只能放在主题末尾)

假如我们有下面五个主题：

• “earth/antarctica/elderthing/shoggoth”
• “earth/antarctica/worker/shoggoth”
• “earth/antarctica/migo”
• “earth/antarctica/cthulhu/starspawn”
• “yith/greatrace”

如果订阅者A订阅了 “earth/antarctica/+/shoggoth”，那么他可以收到来自 “earth/antarctica/elderthing/shoggoth ”和 “earth/antarctica/worker/shoggoth ”的信息。

如果订阅者B订阅了 “earth/antarctica/#”，那么他可以收到 “earth/antarctica ”下所有四个主题的信息。

如果订阅者C订阅了 “#”，那么他就可以收到上述五个主题的信息。

$SYS

“$SYS”是一个特殊的主题，用于代理跟踪和维护系统统计数据。除了代理，其他人都不能向该主题发布信息。

记住，确保MQTT服务与上述标准兼容，这是MQTT协议使用者的工作。默认情况下，MQTT几乎允许我们在主题字符串中使用任何东西，包括非ASCII字符。

RTSP经典且高效，因此世界上大多数的摄像机都在使用。那为什么TikTok却在用RTMP来传输实时视频呢？这是因为RTMP的开发者是Abode，因此这项协议也主要是为推流方（主播）服务。

今天，我们将深入了解RTSP的定义及其作用。首先，大家都应该知道，要想流式传输视频，除了需要RTSP协议外，RTP和RTCP协议也很重要。

RTSP：实时流传输协议

RTSP的作用类似于HTTP，主要用于处理客户机和服务器之间的请求和请求确认。

发送请求格式如下：

<method> <url> <version>
CSeq: <seq>
<content>

例如，你可以这样写：

DESCRIBE rtsp://114.514.19.19:810 RTSP/1.0
CSeq: 2
Accept: application/sdp

回复格式如下：

<version> <code>
CSeq: <seq>
<content>

例如，你会收到：

RTSP/1.0 200 OK
CSeq: 2
Content-Length: 155
Content-Type: application/sdp
....

在上面的例子中，我们向RTSP服务器发送了一个描述请求，要求提供服务器上所有流的说明，而服务器则通过一个SDP文件来进行反馈。该SDP文件描述了我们刚才的请求。反馈信息包括所有流的描述列表，如地址、类型、通信协议、编码等。我们将在本系列文章的后续内容中讨论SDP文件。

关于每种方法的完整版，请参考官方文件：https://www.rfc-editor.org/rfc/rfc2326#page-29.

注意，RTSP本身与传输视频无关，它只是告诉参与方， “我要传输视频”。 视频的传输工作实际上是由RTP和RTCP来完成。

RTP：实时传输协议

RTP负责传输视频数据。RTP默认使用UDP（针对实时数据），将视频数据（视频和音频）打包并传输。

RTP的Header如下所示：

哇，好多新术语! 但你只需要知道，它是RTP的一个典型的Header，用来识别正在传输的数据。我们将在本系列关于RTP的后续文章中进行详细介绍。

RTCP：实时传输控制协议

RTCP负责同步。RTP传输视频时，RTCP会发送RTP所传输数据的状态或元数据。我们用它来监控视频质量、控制负载、节流等。

RTCP 协议规范定义了五种类型的 RTCP包，分别是接收方报告（RR）、发送方报告（SR）、源描述（SDES）、成员管理（BYE）和应用程序定义（APP）。这些都是缩写，但意思不言而喻。BYE用于说明传输终止，而APP则可以认为是 “定制的”，因为它告诉我们这个格式和类型没有被注册，只是实验性的。所以从技术上讲，你并不需要它。

我们将在本系列关于RTCP的下一篇文章详细讨论每种类型的RTCP包。

大家肯定会有各种各样的疑问。例如，SDP是什么东西？RR消息是什么样的？我究竟怎样才能建立一个RTSP服务器？我可以用流媒体玩元神吗？关于上述问题，请期待我的下一篇文章……

物联网应用开发及管理平台 Shifu (https://github.com/Edgenesis/shifu) 正式开源，进入开源协同迭代新阶段。开发者登录GitHub搜索 Shifu获取仓库信息，可以点击 star 支持项目或者 fork 项目。Shifu 为用户提供全场景设备托管与一体化软件开发的透明框架。开发者通过使用 Shifu，可以更简单地连接、监视和控制任何物联网设备。

Shifu 的创新优势是通过透明框架内的数字孪生技术，为设备赋予有思考能力的 “数字大脑” 。数字孪生将反映设备的实时状态，对其进行开发操作等同于操作设备本身。物联网设备接入到 Shifu 中便会生成标准化接口，实现互联网互动，通过平台层对场景内所有设备、机器进行北向数据收集和南向指令管控。

Shifu 提供了桥接式设备互联解决方案，微服务架构令设备能力模块可调用，可复用，目标是实现通过配置文件轻松接入各种异构设备。目前，Shifu 已经实现通过HTTP、MQTT、TCP Socket、RTSP、OPC UA等协议接入物联网设备，同时已将西门子S7、海康威视（HIKVISION）等通过私有协议通讯的设备进行了集成。

作为云原生框架，Shifu 通过Kubernetes的CRD功能延伸了K8s的资源，来实现高可用，静态域名，服务管理等功能，Shifu 可以支持对任何设备进行任何形式的配置。当连接物理设备时， Shifu 会识别并以一个K8s Pod的方式启动该设备的数字孪生 deviceShifu。开发者通过接入 deviceShifu 的接口，可以获取物联网设备的所有功能，同时编程定义设备原本不具备的功能。

云原生的 Shifu 将系统运维的难度大大降低，应用开发者可以通过一套Kubernetes基础架构进行运维管理。 Shifu 将推动Kubernetes成为物联网开发的底层架构标准，将容器编排技术带入物联网软件开发生态中。

Shifu 项目创始人陈永立表示，感谢国内外开源社区对 Shifu 开源的鼎力支持！我们希望将 Shifu 打造成IoT开发的通用开源底座，让IoT开发者也能通过 Shifu 享受到Android和iOS给移动开发带来的红利。我们已经迫不及待地要和 Shifu 的支持者们一起创造万物互联的时代了！

Apache Foundation Member，Mentor of Apache SeaTunnel PMC of Apache Dolphin Scheduler, ClickHouse中国社区创始人郭炜表示，云原生时代的到来，重构了所有企业的基础设施，Shifu 项目的开源帮助企业在IoT物联网管理上更进一步，希望 Shifu 项目越做做好。

LF Edge 董事会主席 Tina Tsou 表示，LF Edge密切关注全球范围内有潜力的边缘计算项目， Shifu 基于Kubernetes的云原生架构，非常具有创新性，将边缘设备的控制管理能力进一步释放，并为应用开发工程师提供了云边协同管理的统一底座，未来将持续关注 Shifu 的开源进程，期待 Shifu 能推动边缘计算技术走向高效率的场景落地。

CNCF大使，华为云云原生开源负责人 Kevin Wang 表示，边缘计算已经成为云原生发展的最关键方向之一。很高兴看到 Shifu 项目的开源，丰富了云原生和物联网的生态，也祝 Shifu 开源社区越来越好。

阿里云技术专家，OpenYurt初创成员何淋波表示，云原生边缘计算领域的发展势头方兴未艾，受到了越来越多的公司的青睐。 Shifu 以云原生为切入点，引入声明式API抽象IoT生命周期管理，优雅解决传统IoT行业的开发周期长，大规模部署复杂，运维成本高等痛点问题。同时 Shifu 以让IoT从业者体验到技术乐趣和软件定义世界为愿景。正值 Shifu 正式向业界开源的时点，强烈推荐云原生，边缘计算行业的从业者去体验和使用 Shifu 。祝福 Shifu 的贡献者、参与者在开源社区收获到开心，乐趣，满足。

微软物联网高级解决方案架构师赵鹏程表示，随着物联网，边缘计算，数字孪生等应用场景逐渐成熟，云原生技术在物联网相关解决方案中也产生了越来越重要的影响。 Shifu 就是这样一个基于Kubernetes技术的物联网边缘计算框架，并非常巧妙的将数字孪生概念和容器技术进行了融合，是一套在目前看来虽然略显青涩，但整体架构却非常灵活的平台。期待开源的 Shifu 不断拓宽影响力，加速代码与产品的迭代，深入场景，下沉行业。成为业界信赖的物联网开源解决方案。

全球领先的开源时序数据库TDengine创始人陶建辉祝贺 Shifu 正式开源，他表示，选择开源是中国基础软件与中间件建立行业领先地位的关键一招，也是面向全球市场勇敢的选择。开源意味着主动接受社区同仁的关注，同时接受开放带来的机遇，让技术真正地落地在现实场景中。 Shifu 的云原生架构，更加完美地支持容器化部署，期待未来与TDengine3.0一起在物联网场景中探索出更多的可能。

面向物联网现代数据基础设施提供商，全球 MQTT Broker 开源社区的领导者 EMQX 联合创始人金发华祝贺 Shifu 正式开源。 Shifu 通过云原生架构方式来支持 IoT 应用的开发和部署，为物联网的数字化转型提供一种新的创新可能。希望 Shifu 开源社区和 EMQ 的开源系列产品一起，可为社区用户构建出从云到边、面向分布式云原生的物联网解决方案。

在未来，Shifu 将逐步支持自动生成 deviceShifu、声明式API、高级的 Shifu 控制器、设备分组、多层封装等功能，期待开源贡献者为 Shifu 提供更多功能迭代方向与真实的场景需求。Shifu 创建的初衷是让每一个IoT设备都有一个 Shifu，让软件定义世界，解决好基础设施问题，让开发者和运维人员在物联网世界再次开心。Shifu 开源社区将与全球开发者一起，为更多的物联设备更好地服务人类而努力。