EdgeX Foundry 性能如何？

这个问题由一位外国开发者在 GitHub 上提出来，坦率地说，这个问题范围太广了，不好完整的回答。

• 非要给个答案的话，那就是：

  EdgeX 性能完全取决于你的硬件配置。

单个实例能承载多少设备？

接着上一个大的问题，这是其中一个分支问题，假如计算资源足够的话，应该可以承受几十万设备。

• 笔者所在公司，采用 4核心，8G内存，可以跑 virtual device 50000-80000个，丝毫没有什么影响；
• 把几万，几十万设备承载在一个实例中，其实并不是一个好的选择，要考虑到如果发生单点故障，应该如何应急处理；

一次性能采集多少设备数据？

测试中有多少个命令以及命令间隔是多少？并且，您应该关注许多选项，例如：数据持久性、南向设备协议种类多少。

• 单协议采集，数量非常多的情况下，就看每个采集设备的测点数量，不会出现什么大问题，注意观察宿主机器上的资源利用率情况，及时作出调整；
• 多协议采集，这样的情况下需要启动多个不同的设备服务微服务来运行，资源占用比单协议采集要多很多，需要更多的资源进行配合；

如何开发一个新的 Device Service 设备驱动？

其实，这个应该不是一个问答能解决的事情，需要一个章节或一个课题来解决。官方给出了很完整的开发手册，具备一些基础能力后，一步一步来，很容易开发出新的设备驱动。

• Golang SDK
• 符合官方的统一开发语言；

• 开发更简单；

• C SDK

• 嵌入式设备上，或需要调用 C 库函数的情况下；
• 需要开启 C 编译环境，尤其是 docker 相关，生成 docker image 需要更多依赖；

总的来说，开发一个设备驱动，是一件很复杂且繁琐的工作，要测试的内容很多，稳定性/可靠性都是需要很多经验配合。

EdgeX 如何支持 I2C, SPI, UART 接口数据采集？

这个问题，是由一个国人在 GitHub 上提出来的，他的提法是否支持 I2C。

我的回答：不必要！

原因有如下： - EdgeX 更加偏向于计算，而不是针对一些串口协议进行解析； - 这些传感器协议，也不适合接在边缘计算网关之上，太过于底层的协议，应该由 MCU + 实时操作系统来完成； - 将这些协议转换成 ModBus RTU，我想这是更加合适的选择；

通用协议：ModBus，MQTT，REST，ONVIF 分别是什么情况？

这些协议，大部分都由社区开发完成，并且经过多轮迭代，稳定可靠，完全可以用在商业环境下。

• ModBus: RTU/TCP 两个版本都支持的很好；
• MQTT: 跟随主版本一起发布，效果很好；
• REST: 跟随主版本一起发布，效果很好；
• ONVIF: 跟随主版本一起发布；
  • v3.0 之前的版本隐性 bug 比较多，慢慢的完善了很多；
  • 还需要一个流媒体服务器配合使用，毕竟 EdgeX 只是做了 ONVIF 协议适配；

工业场景协议：S7，OPC-UA，BACnet 分别是什么情况？

工业场景下，稳定性要求高，性能要求也很高，那么，需要更多的时间来完成开发和测试。

• Siemens S7: 官方还没有完整的开源子项目，笔者公司贡献了第一套代码，目前（11月12日）还在 review 中，详见：https://github.com/edgexfoundry-holding/device-s7
• OPC-UA: 由社区完成了贡献，不过，也不是标准的 EdgeX 组件，需要自己编译和测试，并且用到项目中；
• BACnet: 官方有一个 C 版本的，也跟随主版本一起发布；