物联网物模型_选择正确的模型来维护和增强您的物联网项目

物联网物模型

在物联网（IoT）驱动的当今互联嵌入式设备市场中，开发中的很大一部分设备都基于一种形式或另一种形式的Linux。 低成本板卡和现成的Linux发行版的普及是其中的主要推动力。 获取硬件，构建自定义代码，将设备连接到其他硬件外围设备和Internet以及使用商业云提供商的设备管理从未如此简单。 开发人员或开发团队可以快速开发新应用程序的原型，并将设备移交给潜在用户。 这是一件好事，并导致许多有趣的新应用程序以及许多可疑的应用程序。

当规划超出原型阶段的系统设计时，事情会变得有些复杂。 在本文中，我们想考虑用于开发和维护基本操作系统（OS）映像的机制 。 有很多工具可以帮助您解决此问题，但我们不会讨论单个工具。 这里有趣的是维护和增强此图像的基本模型，以及它如何使您的生活变得更好或更糟。

生成这些图像有两个主要模型：

1. 集中金大师
2. 分布式构建系统

这些类别反映了源代码管理（SCM）系统的驱动模型，并且在讨论OS映像时，有关集中式与分布式的许多争论都适用。

集中金大师

业余爱好者和制造者项目主要使用创建和维护应用程序映像的中央黄金大师方法。 这一事实为该模型带来了速度和熟悉性的好处，使开发人员可以快速设置这种系统并使之运行。 速度来自许多设备制造商为其现成的硬件提供罐装图像的事实。 例如，来自BeagleBone和Raspberry Pi之类的主板提供了现成的OS映像和刷新功能 。 依靠这些映像意味着只需单击几下鼠标即可启动系统并运行。 熟悉是由于这些映像通常基于许多设备开发人员已经使用的桌面发行版，例如Debian 。 多年使用Linux之后，可以直接转移到嵌入式设计中，包括包装实用程序基本保持不变的事实，并且设计人员可以轻松获得所需的额外软件包。

这种方法有一些缺点。 首先， 黄金主映像通常是一个瓶颈，因为在原型制作阶段之后，开发人员会失去生产力，因为每个人都必须等待轮流访问最新的映像并进行更改。 在SCM领域中，这种做法等效于具有单个文件锁定功能的集中式系统。 只有具有锁定功能的开发人员才能处理任何给定的文件。

这种方法的第二个缺点是图像可再现性。 通常可以通过手动登录目标系统，使用本机软件包管理器安装软件包，配置应用程序和点文件，然后在适当位置修改系统配置文件来解决此问题。 完成此过程后，将使用dd实用程序或等效程序对磁盘进行映像，然后进行分发。

同样，这种方法创建了潜在问题的雷区。 例如，基于网络的软件包提要可能会不复存在，并且卖方映像提供的基本软件可能会更改。 脚本编写可以帮助减轻这些问题。 但是，当对配置文件格式或供应商的基本软件包进行更改时，这些脚本往往很脆弱且容易损坏。

这种发展模式最终产生的问题是对第三方的依赖。 如果硬件供应商的映像更改不适用于您的设计，则可能需要花费大量时间进行调整。 如前所述，使事情变得更加复杂的是，硬件供应商通常将其映像基于Debian或Ubuntu等上游项目。 这种情况会引入更多可能影响您设计的第三方。

分布式构建系统

这种为应用程序创建和维护映像的方法依赖于与目标硬件分离的目标映像的生成。 这里的开发人员工作流程类似于使用SCM系统进行标准软件开发。 该图像可以通过工具完全构建，并且每个开发人员都可以独立工作。 通过编辑元数据文件（脚本，配方，配置文件等）对系统进行更改，然后重新运行该工具以生成更新的图像。 然后，使用SCM系统管理这些元数据文件。 各个开发人员可以将最新的更改合并到其工作副本中，以生成其开发映像。 在这种情况下，不需要黄金的主映像，并且开发人员可以避免相关的瓶颈。

然后由构建系统使用标准SCM技术生成发布映像，以从所有开发人员那里获取更改。

以这种方式工作可以在不降低单个开发人员生产力的情况下增加开发团队的规模。 所有工程师都可以独立工作。 此外，此构建设置可确保可以复制您的构建。 使用标准的SCM工作流程可以确保在将来的任何时候，即使上游提供商不再可用，您也可以重新生成特定的内部版本以进行长期维护。 但是，与使用分布式SCM工具类似，还需要制定其他策略来启用可重现的发布候选图像。 各个开发人员都有自己的源代码副本，并且可以构建自己的测试映像，但是为了进行适当的发布工程工作，开发团队将需要建立合并和分支标准，并确保最终针对发布的所有更改都合并到一个定义明确的文件中科。 许多上游项目已经为这种发布策略定义了明确的流程（例如，使用* -stable和* -next分支）。

这种方法的主要缺点是缺乏了解。 例如，将软件包添加到映像通常需要创建某种配方，然后更新定义，以使软件包二进制文件包含在映像中。 这与登录到正在运行的系统时运行apt的方式非常不同。 这些系统的学习曲线可能令人生畏，但结果更可预测和可扩展，并且在考虑将要批量生产的产品的设计时可能是更好的选择。

专用的构建系统（如OpenEmbedded和Buildroot）使用此模型，而诸如debootstrap和multistrap之类的发行打包工具也使用此模型。 诸如Isar ， debos和ELBE之类的较新工具也使用此基本模型。 选择比比皆是，为您的设计学习一个或多个这些软件包是值得投资的。 这些系统的长期可维护性和可再现性允许您生成可再现的内部版本，跟踪所有源代码并消除对第三方提供商的依赖，从而降低了设计风险。

结论

需要明确的是，分布式模型确实遇到了与黄金大师模型相同的问题。 特别是对第三方的依赖。 这是使用他人设计的系统的结果，除非您选择完全自行开发的方法，否则这将是无法避免的，这会在开发和维护上带来巨大的成本。

对于原型设计和概念验证级别的设计以及仅由几个开发人员组成的团队，考虑到在此开发阶段出现的时间和预算限制，Golden Master Model可能是正确的选择。 对于小批量，高触摸设计，这可能是生产使用中可以接受的折衷方案。

对于一般的生产用途，团队规模可伸缩性，图像可再现性和开发人员生产率方面的收益大大超过了学习曲线和实施分布式模型的系统的开销。 这些系统中还广泛提供了板卡和芯片供应商的支持，从而降低了与它们一起开发的前期成本。 对于您的下一个产品，强烈建议您在开始设计时认真考虑用于生成基本OS映像的模型。 如果您选择使用黄金主模型进行原型设计以迁移到分布式模型，请确保在计划中预留足够的时间进行此工作； 根据您选择的特定工具，要求的范围以及代码所依赖的软件包的即用型可用性，估计值将有很大不同。

翻译自: https://opensource.com/article/19/5/model-choose-embedded-iot-development

物联网物模型