如何将12 Factor App应用于Linux驱动程序开发？

问题描述

我是一名工程师，目前正在开发Linux内核模式驱动程序和用户模式驱动程序。当我遇到12 Factor App的理论时，脑中回荡着 strong 的声音，“这就是发展的未来！”。

我一直想知道如何将这种方法应用于Linux KMD和UMD设计和开发，因为该理论太基于Web应用程序了（我是兼职开源Web开发人员）。

当前开发语言：C

当前的测试自动化：定制实现的Python测试框架（基于进度，没有单元测试）

请给我一些建议。谢谢，谢谢。

解决方法

与大多数开发指南一样，该指南与执行之间也存在差距。

例如，在您的“ 12因素应用程序”方法中，因素之一是：

1. 代码库-在修订控制中跟踪一个代码库，许多部署

听起来不错，而且确实可以简化事情。直到您了解实用程序库为止。您会发现，当您发现要在多个项目中重用代码时，您可能想要：

• 多个项目的独立构建和发布链。

这可能意味着两个代码库，但是上面陈述了一个代码库（也许每个项目一个，也许每个公司一个。我们先假设每个公司一个，这很容易被认为是不理想的；因为，您将提交不相关的代码好，每个项目一个，更明智；但是，如果项目需要共享代码该怎么办？像格式化通信并控制发送/接收协议的库一样，我们可以创建第三个“协议库”，以便我们对该协议进行修订；但是，这违反了“一个代码库（每个项目）”，因为现在您有两个代码库组成一个可发布的项目。

这里的决定并不简单。另一种方法是将协议代码复制到两个项目中，并通过其他方式使其保持同步。

1. 依赖关系-明确声明和隔离依赖关系

一个好主意；并且，它在许多方面使开发变得更加容易。再一次，只是为了说明一个好主意在没有清晰的实现思路的指导下会遭受什么痛苦，当您使用一个不试图隔离该库使用的依赖项的库时，您会怎么做？许多更复杂的库本身依赖于其他库，通常，它们清楚地声明了它们的依赖关系，这些库所使用的库也是如此。但是，有时多个项目（日志记录，配置等）使用的基础，核心库最终会在不同的发行版中使用。隔离是按库进行的，而不是按项目进行的。您可以修复它，只要您想要（或可以）分叉并克隆这些库，对它们进行重组以适当地隔离它们的依赖关系以进行版本号的整体协调；但是，通常来说，您将没有时间从事其他人的项目。

通常，“ 12要素应用”方法下的建议是好的；但是，您可以自行完成将准则转换为开发协议的工作。这样，执行就变成了相互纠缠的问题，而强制执行的手段（以及相互干扰）就落在您身上。

有些准则过于简单地被视为危险：

1. 并发-通过流程模型进行扩展

虽然这是一种更简单的方法，但并不是任何一个高性能Web服务器如何工作。它们都使用线程，线程池和其他更复杂的构造来避免进程切换。这些构造（公认更难使用）是专门由于传统过程模型的限制而创建的。毕竟，在每个Web请求中启动一个进程并不常见，通常也不会通过在同一台计算机上启动第二个副本来“调整程序以获得更好的性能”。当然，有些架构可以解决这个问题。但是，到目前为止，这些架构还没有超越竞争对手。

在机器之间，我完全同意。在分散的环境中，过程标定是唯一的方法。但是，这种方法论中很少涉及分布式算法，甚至分布式计算方法。因此，这又是实现者要做的另一件事。

最后，对于编写命令行工具，他们的过程注释似乎真的过时了。守护进程的推动对于微服务确实非常有效。但是，您甚至不能将微服务带离客户。最终，由于开始执行和结束执行而没有始终在线的服务，最终您将不得不编写不受“ systemd管理”的内容。

因此，这是一个很好的框架，即使在很多方面都很出色，也可能不适用于某些事物。但是我认为，实施该工具的工具必须由使用该工具的组织来构建，因为一个组织可能做出的解释可能与另一组织有所不同。