1

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

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

当前开发语言：C

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

请给我一些建议。提前感谢和赞赏。

4

1 回答 1

1

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

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

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

这听起来很棒，并且真的可以简化事情。直到您了解实用程序库。你看，当你发现你在多个项目中重用代码时，你可能想要：

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

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

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

  1. 依赖项 - 显式声明和隔离依赖项

这是个好主意；并且，在许多方面使开发更容易。再一次，为了说明一个伟大的想法在没有明确指导如何实现这个想法的情况下会受到影响，当你使用一个不尝试隔离库使用的依赖项的库时，你会怎么做？许多更复杂的库本身依赖于其他库，并且通常它们清楚地声明它们的依赖关系，这些库使用的库也是如此；但是，有时多个项目（日志记录、配置等）使用的基础核心库最终会在不同的发行版本中使用。隔离发生在每个图书馆的基础上，而不是在每个项目的基础上。你可以修复它，只要你想要（或可以）分叉和克隆库，重组它们以正确隔离它们的依赖关系，以实现版本号的整体协调；但是，通常你会没有时间处理其他人的项目。

一般来说，“12 因素应用”方法下的建议是好的；但是，它留给您执行将指南转换为开发协议的工作。然后，执行变成了干预的问题，执行的手段（以及干预）落在你的执行上。

一些指南看起来过于简单化了：

  1. 并发 - 通过流程模型横向扩展

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

在机器之间，我完全同意。流程扩展是进入分布式环境的唯一途径；但是，这种方法论中并没有太多讨论分布式算法，甚至是分布式计算方法；所以，这又是由实施者决定的另一件事。

最后，他们的过程评论似乎真的不适合编写命令行工具。推动事物守护进程对微服务非常有效；但是，即使是客户端，您也不能微服务。最终你将不得不写一些不是“由 systemd 管理”的东西，因为在没有永远在线的服务的情况下开始执行和结束执行。

所以，它是一个很好的框架，它可能不适用于某些事情，即使它对很多事情都很好；但是，在我看来，执行它的工具必须由使用它的组织构建，因为一个组织可能做出的解释可能与另一个组织不同。

于 2020-08-24T06:47:36.077 回答