EdgeX Foundry（八）：FAQ 常见问题和解答

 

EdgeX Foundry 在下面将统一简称为 EdgeX。

 

Q：我刚刚接触 EdgeX，应该使用哪个版本比较合适？
A：

• 我们建议，你应该使用最近发布的版本，可以根据版本号，比如：v2.3, v3.0；也可以根据版本代号，比如：Levski, Minnesota；
• 如果你在尝试对 EdgeX 二次开发，选择 main branch 是最为合适的了，但是，要紧跟社区的 commit ;

 

Q：EdgeX 二次开发的难度高么？需要什么技能才能掌握？
A：

• 坦白说，难度非常大(不是危言耸听)，EdgeX 设计架构相对而言来说是很复杂，从另一个方面来说也是非常结构化/模块化，具体看你对架构和代码的理解程度；
• 作为中文母语的开发人员而言，全英文的资料还是有点阻碍，还好，老外和先前的开发者在文档和代码写的还是非常详细；
• 如果仅仅是开发南向设备层或北向用层，其实还是比较容易了，根据官方文档，有开发基础（golang, iot, network, web, api等）上手不难，但是需要时间；

 

Q：为什么 EdgeX 看上去那么复杂？
A：

坦白说：因为你接触时间太短了，还没有吃透里面的内容。

• 自2017年来，EdgeX 已经迭代了 12 个大版本（社区的计划是每年 2 次大版本更新，分别是：上半年5-6月份一次，下半年11-12月份一次）；
• 模块化打散，基础模块多，全微服务化，等，这些特性就已经够开发者思索一番，不是一个简单的小程序架构；
• EdgeX 设计思路超前，与时俱进，所采用的技术都是非常前沿和高端，所以，开发者需要具备更多的知识才能驾驭；
• 如果条件允许，可以组件一个背景经验丰富的开发者团队，仔细研究其文档和代码，或许半年后可以掌握技巧（笔者公司，从接触到基本掌握开发技巧花了2年多时间）；

 

Q：关于 EdgeX 文档、开发有什么建议？
A：

• 文档很详细，但是内容很多，每个点都写得很详细，需要花很多时间来研究；
• 除了官方文档网站： docs.edgexfoundry.org，还可以访问官方 Wiki 网站：wiki.edgexfoundry.org；
  • 官方文档网站：这里最主要的是系统介绍、手册、参考、案例等，针对使用者和初级开发者；
  • Wiki 网站：这里主要内容是社区管理、底层设计、事件、技术预研等，针对开源社区贡献者和高级开发者；
• 自 2023年11月开始，沟通渠道 Slack 已经被社区废止，需要与社区进行对话，只有 GitHub Discusion，当然也可以通过邮件进行沟通；
• 熟读源码太重要了，当然，也会非常吃力，这个没有弯路也没有捷径，只能花精力去做；
• 要想驾驭 EdgeX 开发，完成设备采集和业务对接，需要很多经验，很简单的方法，就是去搜一下：边缘计算，这个关键词；

 

Q：EdgeX Foundry 性能如何？
A：

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

• 非要给个答案的话，那就是：EdgeX 性能完全取决于你的硬件配置。

 

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

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

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

 

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

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

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

 

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

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

• Golang SDK
• 符合官方的统一开发语言；
• 开发更简单；
• C SDK
• 嵌入式设备上，或需要调用 C 库函数的情况下；
• 需要开启 C 编译环境，尤其是 docker 相关，生成 docker image 需要更多依赖；

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

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

这个问题，是由一个国人在 GitHub 上提出来的，他的提法是否支持 I2C。
我的回答：不必要！
原因有如下：

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

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

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

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

 

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

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

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

Q：EdgeX 运行太占资源
A：

资源占用，跟业务要求有关系：

• 传感器数量：比如，接 10 个传感器和接1000个传感器，完全不一样的资源使用率；
• 采集频率：5秒采集一次数据比较正常，假如你调整到 500ms 一次采集，又是另一番景象；
• 设备类型：业务简单的话 1-2 种设备类型，复杂环境下几十上百种都可以，资源占用那是天壤之别；

 

Q：软硬件要求高
A：

官方有最低资源要求，如果你的硬件低于这个要求，建议要么 别上 EdgeX，要么升级硬件：

• 硬件：
  • 内存：最小 1GB，操作系统用掉一些，其他就是看你运行的容器数量，1GB 只适合测试验证，不适合商业用途；
  • 存储：最小 3GB，操作系统占用多一些，docker image 占用不多，剩下的就是 container 运行过程中产生的日志，这个需要在 docker compose 中定义参数，回滚日志文件；
  • CPU：没有特定限制（X86，ARM32需要自己编译 ，ARM64都可以），具体看业务处理量，做好观测，最大 CPU 负载不要超过 50%，保持一定的缓冲；
• 软件：
  • 操作系统：宿主主机，虽然可以支持常见的 Windows、Linux、macOS，但是，生产环境还是应该以 Linux 为主（推荐 Ubuntu 系列）；
  • 软件环境：
    • 开发：采用开发工具包（包含：编译器，各种函数库），docker runtime；
    • 生产：docker runtime 即可；

 

Q：关于竞争
A：

这个问题比较宽泛，不能一概而论，可以从以下几个方面考虑：

• 摆正位置：要充分理解 EdgeX 在边缘计算领域所处的层次结构，你到底是做数据采集还是边缘计算？不要把传统的DTU和RTU称之为边缘计算就算是明白人了
• 竞争对象：如果用预装 EdgeX 的产品去跟其他单一功能的采集器相比，完全没必要，不是一个量级；
• 竞争场景：这个具体看你的市场策略和业务需要，你愿意用低价换取市场占有率，另当别论；

 

Q：GitHub 社区经常出现一些奇怪又频繁的错误信息，贴出来问
A：

当然，你完全有这个权利和必要，毕竟遇到问题了，需要去解决它。

• 根据错误提示，去搜索引擎找找看，也许是一个通用的问题，或许并不是 EdgeX 本身；
• 可以到 GitHub issue 里面找，变换一些搜索关键字，也许被人也遇到过且已经被解决了；
• 各种开发基本能力，尤其是 docker，golang，物联网相关，保证能明白到底问题出在哪里，有时候并不是问题复杂，而是自己不熟悉整个过程；

提醒
官方已经发布 v3 版本，最新版本 v3.1（LTS 长期支持版本） 刚刚在 2023年11月15日 发布，已经解决了 v3 以来的绝大部分问题。
理论上来说，官方社区已经不会提供更早版本的技术支持：

1. 有 bug 不回修复；
2. 新特性不会增加；
3. 友善提醒更新到当前发布版本；

 

Q：有人提问：这么少的驱动支持数量，如何成为一个官方应用的边缘计算框架？
A：

建议，还是先读一读 EdgeX 官方文档：a vendor-neutral open source project（供应商中立的开源项目）
以目前 EdgeX 应用情况来说，已经成为很多行业和领域的事实规范，不需要质疑，也无需考证，就冲着——供应商中立的开源项目，已经征服了很多开源边缘计算框架的使用者。
老外比较直接又比较委婉，以笔者的措辞：难道把开源软件拿来主义，换个皮，改一下项目名称，改一下程序接口名，顺便让社区把所有你需要的都做好，开放给你，免费给你技术支持，……

• 参与开源，也可以奉献开源，你可以把你的驱动贡献给社区，也可以让社区帮你改改 bug 什么的；
• 可以提出你需要的驱动类型，参与社区讨论，帮助提高社区驱动支持的范围；

 

Q：如何集成 RBAC 到 EdgeX？
A：

这个问题是由老外在 GitHub 社区 discussions 里面提出来，他希望 EdgeX 能够集成第三方认证软件，比如 Keycloak，以便完成权限对接。

• RBAC，其实不适合 EdgeX，这只是一个边缘计算框架而已，不是一个完整的业务系统；
• EdgeX 本身有 token 机制来保证安全，控制中心与 EdgeX 交互是安全可靠的就好了，无需 RBAC；
• 当然，你也可以改造 EdgeX 使得其能够支持 RBAC，这个工作量社区无法作出评估；

 

Q：如何一次获取多个数据测点？
A：

当然可以，而且数量不限制。主要的问题就是每次 core-command 能承受的数据量需要手工进行调整，以达到你的数量请求。

• 定义一个 command，包含你所需要的 resource，即可进行绑定，EdgeX 会一次性获取完所有的数据，返回到 message bus 中；
• 修改 Service - MaxResultCount ，以便容纳你的 command；

 

Q：EdgeX 有 API Gateway 吗？
A：

GitHub 社区里，经常有人问关于 API Gateway 的事情，总的来说，基本都是没有好好读官方文档的人，不了解 EdgeX 的机制，所以不清楚。

• EdgeX API Gateway 使用 nginx 来实现，并且集成了 Secure 机制，从 v3 版本开始，微服务之间也需要 JWT 认证，这是为了防止有应用绕过 API Gateway；
• 也可以自行修改 API Gateway 配置，完成更多集成和扩展，就是 nginx 配置而已；
• kong 安全机制已经从 EdgeX 被移除，相对简单了很多；

 

Q：如何接入云或企业网络？
A：

这个问题，也是 GitHub 社区问的比较多的，尤其是那些不需要接入公有云服务的客户，他们有自己的云或企业网络，要接入进去。

• 用 eKuiper 规则引擎，可以通过简单的配置和命令完成简单的云对接，而且 eKuiper 已经内置了很多云服务的对接；
• eKuiper 除了一些云资源对接，也需要接入企业网络，比如数据库，时序数据库等，都可以完美支持；
• 自己开发一个 Application Service 来对接，官方提供了很多例子可以参考，主要是修改对接协议的数据格式皆可完成。

 

Q：EdgeX 使用和开发中出现了一些错误提示的解决方法
A：

这些问题是由用户在 GitHub 社区 discussions 里面提出来，希望社区给予解答。这里举几个例子来说明一下。

调用 API 返回错误

{
  "apiVersion" : "v2",
  "message" : "Failed to unmarshal request body as JSON.",
  "statusCode" : 400
}

很明显，这是一个基础性问题：JSON 不符合要求，也就是说 JSON 格式不对，如果是手工写的，可以先使用 JSON 格式化工具来验证一下。

 

Q：很多时候，一堆未知错误，不知道该怎么入手
A：

的确，大部分时候出现的问题并不是 EdgeX 系统本身的问题，而是不会使用造成的疑问，应该读一读 EdgeX 官方文档

 

Q：不要一开始就质疑 EdgeX 框架本身的问题
A：

罗马不是一天建成的，那么 EdgeX 也不是刚刚开源的，所以，应该从自身的角度去看待出现的问题。

• 熟读官方文档 - https://docs.edgexfoundry.org;
• 熟悉源代码 - https://github.com/edgexfoundry;
• 查询历史 issue - 每个仓库的 Issues;
• 灵活运用 GitHub Discussions;

靠谱推荐：Free Pos，微信JOCIHEZ