Skip to main content

Li Zheng flyskywhy@gmail.com

IPFS 技术应用在消息类型物联网项目中相对于传统后端服务器加数据库方式的优势

这里以一个智能路灯项目为例，分享一下我理解的 IPFS 为客户带来的产品售后优势，技术人员带来的技术架构优势，以及为管理人员带来的项目进度优势和为市场人员带来的能力广告优势。

我曾花几个月时间开发了用后端服务器同步蓝牙灯配置的蓝牙灯前后端代码项目，然后又花几个月开发了用二维码同步而无需后端服务器的蓝牙灯前端代码项目，在这个过程中我发现，基于纯粹数据网络同步需求业务或者说消息类型的物联网项目，用轻量级的 IPFS 技术就足够了，根本用不到很重的服务器外加数据库。

IPFS 目前已成为分布式文件系统事实上的标准，它能为路灯项目带来的优势对比如下所示：

为甲方公司位于世界任何角落的路灯运营客户带来的好处​

传统后端服务器加数据库加前端开发方式：

  1. 使用甲方的服务器的话，则客户购买的整套产品的生命周期依赖于甲方公司的存续时间，稳定性依赖于阿里云的稳定性；
  2. 客户自购服务器的话，依赖于甲方公司在服务器软件维护上的技术支持；
  3. 客户需要支付每年计费的服务器费用。

内含 ipfs 技术的纯前端 APP 开发方式：

  1. 依赖于客户自己对密钥的管理；
  2. 依赖于客户自己对密钥的管理；
  3. 客户需要一次性支付路灯网关为了支持 ipfs 而需要的支持操作系统的嵌入式电路比无操作系统多出的费用。

基于上述好处，估计客户会一次性多购买一些网关和路灯 mesh 节点以便甲方公司不存在的情况下自己修理。

为我们的客户甲方公司带来的好处​

传统后端服务器加数据库加前端开发方式：

  1. 不使用之前与甲方谈的我们新做的 mesh 节点硬件的话，那我们只是用 JS 在 6 个月内重写一遍他们已经离职的一位前后端加数据库人员在过去一年所写的 JAVA 逻辑而已，另外，原 JAVA 代码在一年前也是由某个大学师生所开发的原型转过来的，所以甲方不见得会认为我们这样重写一遍就能解决之前存在的延时较大等问题，他们可能宁愿另外招人再去改进 JAVA 代码；
  2. 派出 FAE 去客户指定的地方安装客户自己的服务器；
  3. 现在及 6 个月后，相对于竞争对手公司的产品的竞争里没有提升。

内含 ipfs 技术的纯前端 APP 开发方式：

  1. mesh 节点硬件是旧的，但是软件工作方式是全新的，甲方可能还对解决之前 JAVA 版本的问题对我们抱有期望；
  2. 无需派出 FAE 。
  3. 由于上面提到的为客户带来的好处， 6 个月后甲方的智能路灯解决方案相对于竞争对手更能吸引客户采用。

为我们的技术人员带来的好处​

传统后端服务器加数据库加前端开发方式：

  1. 需要开发人员为数据库建模及持续重构；
  2. 需要象之前的 JAVA 代码那样，服务器上运行 2 个服务进程，然后比如前端界面通过 1 个服务进程向数据库写入路灯开关策略，网关上的嵌入式程序通过另 1 个服务进程从服务器读取路灯开关策略来控制路灯的开关；
  3. 客户帐号、管理员等帐号的管理需求开发；
  4. 故障等短信功能开发，还要考虑到不同国家短信的不同开发方式，以及解决一些之前 JAVA 开发中碰到的有些国家短信收不到的 BUG ；
  5. 需要解决之前 JAVA 开发中碰到的客户所在时区、服务器所在时区、路灯所在时区三者不同时的头痛 BUG ；
  6. 之前 JAVA 服务用的是 http ，估计甲方/客户更愿意加密的 https ；

内含 ipfs 技术的纯前端 APP 开发方式：

  1. 很简单，创建及持续重构 JSON 数据结构只是日常编程工作的一部分而已，比数据库简单太多太多了，也因此减少了 BUG 的出现概率；
  2. 很简单，只是路灯开关策略、路灯状态灯信息的同步而已，需要数据库颠来倒去搞得那么复杂？在 ipfs 网络上传输的 JSON 数据结构就可以满足这些数据的同步需求——比如 APP 代码只要往手机上的 ipfs 服务进程中写路灯开关策略，网关代码只要从网关上的 ipfs 服务进程中读路灯开关策略就可以了；
  3. 很简单，客户自己管理好 ipfs 的密钥对即可；
  4. 较简单，使用 ipfs 网络上传输的数据就可以开发 APP 通知功能；
  5. 较简单，只要处理好客户所在时区与路灯所在时区的转换即可；
  6. 无需开发，因为 textiot （见下面的介绍）已经做好了通讯加密

开源维护长期性及优势：

  • ipfs 行星际文件系统

ipfs.io 开发社区已存在好几年了，还在继续开发，且基于 IPFS 的应用/框架一直在持续增加。另外， ipfs 不仅仅只是一个分布式文件系统，在它上面也有做到 pub/sub 即消息发布/订阅功能，也许可以之提升之前 JAVA 开发的路灯项目延时较大的问题（如果发现还没有解决的话）。

  • textiot A framework for building web and native (IoT) Dapps on the IPFS network

该框架除了将 ipfs 的 go 语言代码包装为 RN 组件并包含在内，还已经解决好了 ipfs 服务进程在手机上运行时的耗电问题，我们只需参考摸索好该框架及掌握一些 ipfs 知识，就可以开发路灯项目真正的业务了——开关策略、地图画点、故障状态报告。

为我们的管理人员带来的好处​

传统后端服务器加数据库加前端开发方式：

  1. 由于不可能另外开发一个网关 mesh 节点的模拟程序，所以在项目初期就要让后端开发人员与 mesh 节点开发人员交互等待配合开发后端与 mesh 节点的连接代码，然后才能开始真正的业务开发，过程中也是交互等待配合，这些基本都是串行开发，而且该后端开发人员还要兼职数据库和前端开发，效率更低，因此 6 个月的项目进度几乎无法保证。

内含 ipfs 技术的纯前端 APP 开发方式：

  1. 在项目初期，就比如说前 3 个月吧， APP 开发人员把电脑当作一个网关 mesh 节点进行模拟，以路灯项目真正的业务——路灯开关策略举例， APP 的开发就围绕着如何在手机上生成一个 JSON 文件并通过 ipfs 网络自动同步到电脑上，并行的，在前 3 个月内， mesh 节点开发人员的开发就围绕如何处理一个手动写在网关操作系统中的 JSON 文件。也就是说，这个 JSON 文件就是两位开发人员之间的接口，他们的开发基本互不干扰。接着后 3 个月，此时应该已经为能跑操作系统的网关选型好嵌入式电路，此时就是继续进行其它一些路灯项目真正的业务了。

为我们的市场人员带来的好处​

由于 textiot 底层的技术之一是区块链技术，所以如果我们有项目采用过 textiot 的话，则后续市场人员去外面接单时可以宣称我们是一家区块链物联网公司了:P

简单总结​

使用 ipfs 技术后，由于不用再开发/解决一些 Use Case 和 BUG ，所以预计能减少开发成本（Use Case）、运行成本（管理服务器）、维护成本（解 BUG）、人力成本，加快项目进度。