Golang 1.11版本引入了Go.mod作为官方的包管理工具。
Go.mod，也就是Module。Module是相关Go包的集合，是源代码交换和版本控制的单元。Modules替换旧的基于GOPATH的方法，来指定使用哪些源文件。
在引入go.mod之前，项目必须放在$GOPATH/src目录下，依赖要靠手动管理，并且依赖包没有版本一说，对开发造成了极大的困扰。之后的vendor部分解决了上述问题，但是依赖包需要全部下载到项目的vendor路径下。go.mod则将依赖包默认下载到$GOPATH/pkg/mod路径下，减少开发者对依赖的关心，只需关注个人代码，同时减轻了push/pull压力，也避免了他人随意修改依赖。
通过Hexo写博客已经有一段时间了，有时长久不更新后，容易忘记如何更新自己的博客，写这一篇方便记忆。
InfluxDB是一个开源的时序数据库，也是目前Github上最流行、性能最好的开源时序数据库之一。它由Go语言编写，用于存储和查询数据。相比于OpenTSDB，它部署相对简单，不需要额外的外部依赖。当前，influxDB分为1.x和2.x版本，而2.x版本又分为开源版本和企业版本。1.x版本是传统的开源版本，目前已经更新到了1.8.3；2.x开源版本当前还停留在rc（最终测试）版本。两者之间差距较大，本文专注于1.x版本。
在KubeEdge中，mapper组件是边缘设备与边缘节点之间的桥梁。Mapper从边缘设备中采集设备数据，并通过Mqtt的形式将数据传递给Mqtt Broker，并通过EventBus进入边缘节点。因此，对于不同的边缘设备，也需要不同的mapper进行数据采集。社区目前已经提供了两种比较通用的mapper组件，分别支持蓝牙协议和modbus协议，这都是边缘设备中比较常见的协议。本文将对支持蓝牙协议的mapper进行分析，并结合社区CC2560 Sensortag的例子加以说明。
注：由于BluetoothMapper和demo都有些时间没有维护了，笔者在实践过程中也有许多不解之处，如有疑问欢迎与我交流。
本文从消息流的角度总结KubeEdge云端的消息传输。
阅读本文前，建议先看《KubeEdge概念一览》中的beehive和ChannelContext部分。
DeviceController是KubeEdge云端部分比较重要的组件之一，主要负责接入和管理边缘设备、设备元数据云边协同。在开始之前，首先介绍一下两种资源：
经过对CloudCore源码的整体分析可知，云端各个组件的重点在于各自的Start()函数。于是，我们进入devicecontroller.go文件，查看DeviceController的Start()函数。