2019 年 9月底，由于公司业务原因从 Rokid 离职，十月份则到处跑找工作，因此也接触到一些公司和创始人，期间碰到一家做 IoT + 编程教育的初创公司，对于他们的业务目标目前他们没有足够的相关经验来搭建，并且他们也比较认可我所描述的一套 IoT 业务流程，聊过之后发现有合作的可能，因此尝试为他们设计整体业务的架构方案。

本文是我针对他们的业务场景给出的架构设计方案描述以及我个人的一些对 IoT、社区生态方面的思考。

公司及业务背景

对方是一家初创公司，创始人来自中国移动杭州研发中心，据他描述目前团队成员3人左右，创业方向为面向小学阶段的 IoT + 教育培训，简单来说就是在传统的编程教育基础上加入 IoT 元素。

关于业务模式和架构主要分为两种：一种是纯粹面向IoT设备编程，考虑采用 Python（因为据说目前中小学比较普及 Python 这种语言），具体 IoT 设备会包括高端的比如天猫精灵、米家等各种设备，以及也会包括一些更低端的小设备比如 Arduino 及相关小型组件、树莓派等，让学生通过简单编程实现对设备的控制（简单思考下来觉得这跟传统的少儿编程模式比还是有一些优势的，毕竟少儿编程教育主要为激发学生兴趣和思维，这种带有实实在在设备的模式对于小孩子来说可能会更有吸引力），这个过程需要平台对设备的封装管理和虚拟化；

另一种模式则涉及到一种图形化编程工具平台：Scratch，这种模式其实也算是对第一种模式的更深层次抽象，或者说将采用 Python 语言编程的模式改为图形化编程操作，其他基本不变，这可能是更容易让幼儿阶段的孩子接受的培训方式，这也涉及到他们一直提的概念：软件积木，目前他们手上有一些教育资源和培训机构合作关系，且初步的少儿编程教育业务已经在开展，下一步就是真正实现 IoT + 编程培训。关于 Scratch 的对接方式他们目前已经有一些技术基础，两种模式下业务架构上对 IoT 设备的管理和虚拟化也基本一致，因此这个方案主要是为业务中用到的各种设备建立管理和控制平台。

整体方案概览

架构图

设计方案简介

一、总体服务分为三层：用户层、服务层、设备层

1、用户层：提供统一的对外服务，包括管理员界面、用户（学生）编程控制界面及教学工具、数据工具等

2、服务层（分为三部分）：

​ 2.1、自有 IoT 服务：将所有设备进行虚拟化控制与管理，并承担与三方 IoT 云服务对接的功能。

​ 2.2、三方 IoT 服务：三方厂商的 IoT 云服务，如米家云服务，这部分无需研发，需要做的主要工作为协议对接。

​ 2.3、API：将自有 IoT 服务与三方 IoT 服务的对外功能与数据通道进行统一封装并对外提供一致的服务，实现业务与应用之间的解耦。

3、设备层（整合业务中需要用到的所有设备，并将所有设备按来源与管理方式分为三类）：

​ 3.1、自定义设备：需要自主编程控制并直接通过自有 IoT 服务管理的设备，如 Arduino、树莓派及其相关子设备等。

​ 3.2、三方设备：来自于第三方厂商，需要间接通过第三方 IoT 服务进行管理与控制，如米家设备等。

​ 3.3、虚拟设备：由于在服务层已经将所有设备进行虚拟化，因此在某些业务场景下可以创建虚拟设备而无需提供真实的物理设备，这种设备除了没有物理机身外其他管理和控制的流程都与上述自定义设备一致。

二、本方案中主要业务流程为设备管理、设备查询、设备控制、数据通道，网络协议采用MQTT。

1、设备管理

业务中需要用到的各种设备都需要系统管理员通过管理界面进行管理，包括设备的添加与删除，IoT服务端会维护一个可供管理和控制的设备列表。对于一些三方设备如米家设备通信时会涉及驱动，这里的驱动将常驻于云端并与三方厂商云端进行云云对接，由于这里的场景下设备的添加删除操作不频繁，因此暂不考虑驱动按需安装和卸载的场景。驱动的主要功能是作为本地系统与三方云厂商进行协议对接的代理，其中会涉及鉴权流程，需根据不同平台进行对接。

设备管理案例（添加设备）流程图：

2、设备查询

设备查询主要用于在管理员界面显示当前系统支持管理控制的所有设备以及为用户（学生）提供可视化的操作界面。

3、设备控制

设备控制流程与普通IoT设备的控制流程基本一致，但指令的输入方式不一样，主要为用户（学生）在预先设定好的操作界面上通过点击、拖动的方式来进行设备的控制，控制指令由用户界面上传至云端，云端会根据协议内容选择对应的设备下发指令由设备执行，控制结果由设备上报至云端，再由云端反馈给用户端。

4、数据通道

此功能用于聚合所有用户（学生）在教学和使用过程中产生的操作和控制数据，为后期教学和运营提供数据依据。

业务流程举例

例如一块 Arduino 的板子 A 上连接了一个发光二极管 R 和一个蜂鸣器 F，R 和 F 皆可通过 A 控制。云端服务已事先定义好与 A 之间的通信协议。当 A 上的程序启动时，A 会与云端建立连接，此时系统管理员可通过管理界面请求将A添加到云端设备列表中，A 会反馈给云端其携带的各种子设备，云端确认后将 A 及 A 的子设备 R 和 F 添加至可控制的设备列表中，此时用户（学生）的界面中也能显示这些虚拟化的设备。当用户（学生）点击页面上的虚拟设备操控按钮时，页面将相应的操作指令上传至云端，由云端下发至设备上执行操作，操作完后设备向云端反馈操作结果，最终操作结果反馈至用户界面，并同时保留相应操作数据。

问题与思考

1、经过三次的交谈，从技术层面上考虑，除去 IoT 设计开发经验的缺乏，我认为他们目前也还是面临一些问题的，比如面向设备端（前期主要为 Arduino 和树莓派）编程的时候其实没有太多的选择，因此也曾向团队推荐使用 Rokid 自研的 YodaOS + ShadowNode 或 ShadowNode 来作为设备端的解决方案，在我整体的介绍之后，对方也认可这样能降低整体的开发难度和成本，提高研发效率，但总体来说采用的意愿却并不是很强。其中一个原因是对性能的担忧，还有一些未知的因素，我觉得这也是作为开源平台方需要思考的问题。

2、关于社会编程教育的思考，上述这一套 IoT + 编程教育模式细节不再多说，目前市面上面向少儿的编程教育目标与成人编程不同，前者主要是激发孩子兴趣和锻炼思维，对于受众来说没有特别清晰明确的教育目标，当然也会受普世的教育价值观导向比如高考的影响。成人编程教育则有更强烈的目标指引即就业。所以我觉得也许编程教育也会是 YodaOS 及其周边生态的一次机会，如果能将 YodaOS 生态引入课堂，从技术源头切实降低嵌入式开发的学习、实践和工程化门槛，再将这个优势导入市场，这势必也会成为 YodaOS 推广的基础。

3、这次我给的方案里面，设备端部分的开发因为业务流程不多所以难度较低，且他们自己也有一些积累，但 IoT 服务端的开发他们是没有任何经验的，在沟通方案的过程中对方也要求我在给方案的同时也要做好技术选型，最好是能找到满足大部分功能的开源项目并基于此进行二次开发，以此提高产品成型速度降低成本（但其实我觉得这个是困难的）。因此我也在 GitHub 上搜索过，也可能是我搜索的方式不对，目前没有找到很合适的开源项目。传统 Web 服务端开发经过长期的发展已经能为开发、测试等流程提供了大量的平台、框架、工具、规范和标准，但这在 IoT 领域还是比较缺乏。

4、关于谈判能力。从结果看这次合作其实并不成功，因此这里也只是简单叙述了整体设计思路和架构方案。不成功的原因我认为一部分在于对方其实也没有太大的决心来做这件事，并且团队还没完全组建，对于业务也缺乏深入思考和规划，且在沟通的过程中也没有表现出太多的诚意与决心。另一方面还归咎于我自身的谈判技巧与沟通方式，也许也是我自身急于求成且当时也确实面临找工作的压力，因此最终没有深入规划整件事情并与对方持续合作。但总体来说获益匪浅。