12 要素应用程序_关于十二要素应用程序的评论

12 要素应用程序

十二要素应用程序是一种用于编写希望变得越来越流行的Web应用程序的最新方法（和/或宣言）。 尽管我不同意100％的建议，但我将快速浏览所有12个因素，并根据Java生态系统进行讨论，并提及绝对的“麻烦”和我不同意的观点。 有关更多信息，请访问12factor.net网站 。

1. 代码库–一个代码库，多个部署。 这意味着您不能为各种版本使用各种代码库。 分支可以，但不同的存储库则不可以。 我什至会更进一步，不建议使用Subversion。 不是因为它不好，而是因为git和mercurial做了同样的事情甚至更多。 您可以像使用SVN一样使用git / mercurial，但不能相反。 DVCS的工具（例如SourceTree）已经相当不错了
2. 依赖性 –显然，您必须在清单（例如pom.xml）中放置尽可能多的依赖性。 声明建议不要依赖预装的软件，例如ImageMagick或Pandoc，但是我没有那么严格。 如果您的部署是自动化的，并且可以保证使用给定的工具，那么您不应该花几天时间尝试将其包装在您的工作语言库中。 如果将可执行脚本放到jar文件中然后将其解压缩一样简单，那很好。 但是，如果需要安装，而您确实需要它（ImageMagick确实是一个很好的例子），那么我认为期望它被安装并没有错。 只需检查启动是否存在，否则就快速失败。
3. 配置 -这里最重要的规则是-切勿在源代码存储库中提交特定于环境的配置（最重要的是：密码）。 否则，您的生产系统可能容易受到攻击，因为至少有三分之一的这些wordpress部署是这样 （是的，mysql可能不允许外部连接，但我敢打赌，没有人对此进行过验证）。
   但是从那以后，我认为它不同于12因子应用程序之一。 不，您不应该在配置中使用环境变量。 因为当您有15个变量时，如果将它们放在单个文件中，则对它们的管理将变得更加容易。 您可以使用一些shell脚本来设置它们，但是这与操作系统的独立性背道而驰。 我认为，拥有一个键值.properties文件（Java对其提供本机支持），并且仅将绝对路径作为环境变量（或JVM参数）传递给该文件是一种更好的方法。 我之前已经讨论过了 。 例如，在启动时加载的CONFIG_PATH = / var / conf / app.properties。在应用程序中，您可以保留空白的app.example.properties，其中包含要配置的所有属性的列表–数据库凭据，密钥和用于外部系统等（无任何值）。 这样，您就可以将所有属性都放在一个位置，并且很容易发现在给定场景中可能需要添加/重新配置的内容。 如果使用环境变量，则必须在txt文件中包含它们的列表，以使它们“可发现”，或者让开发人员深入研究代码以找出可用的属性。最后，同样重要的是，当我说您不应该将属性文件提交到源代码管理时，有一个非常特殊的例外。 您可以选择对环境配置进行版本控制。 它必须是私有仓库，具有有限的访问权限，但是（Dev）Ops可以在一个地方保留每个环境的属性和其他详细信息。 使用属性文件更容易做到这一点（使用env变量并非不可能，但是再次需要shell脚本）。包含12个要素的应用作者警告环境爆炸。 如果每个环境都有一个属性文件，这些文件可能会增加。 但是他们不必这样做。 您可以完全按照管理环境变量的方式来更改属性文件中的值。
4. 支持服务 –这是关于平等对待您的应用程序所依赖的外部服务的，无论您是否管理它们，或是否由另一方管理它们。 从应用程序的角度来看，这无关紧要。 我可以在这里添加的是，您应该尽量减少这种情况。 如果有内存队列，则不要部署单独的MQ。 如果可以使用内存缓存，请不要部署Redis实例。 如果可以使用嵌入式数据库，则不要管理数据库安装（例如neo4j提供了嵌入式版本）。 等等。 但是，如果您确实需要功能齐全的外部服务，则使其路径/凭据可配置为好像是外部的（而不是例如默认情况下指向localhost）。
5. 构建，发布，运行 - 在页面上有详细介绍。 拥有这样的生命周期真是太好了。 但是设置它需要时间和资源。 根据您的约束，您可能没有完整的流水线，并且某些阶段可能比理想的更加手动和流畅。 有时，例如，在启动的早期阶段，能够在正在运行的生产服务器上交换类文件或网页而不是经过完整的发布过程（您没有时间来完成）可能是有益的。完全自动化）。 我知道这听起来像是异端，应该努力实现完全自动化和分离的过程，但是在到达那里之前，不要完全放弃手动将固定文件放入生产环境的选项。 只要您一直不这样做，就不会遇到无法运行哪个版本的代码库的生产环境。
6. 进程 –这是无状态的，并且还不依赖于内存或文件系统中存在的任何状态。 实际上， 状态不属于代码 。
   但是，有些事情我不同意。 打包资产的12个因素的首选方法是在构建期间（例如，将所有css文件合并为一个）。 这有几个缺点–您无法动态组合资产，例如，如果您有6个脚本，并且在一页上需要4个脚本，在另一页上则需要第一页中使用的2个脚本，而另外2个，则需要预先构建所有这些排列。 哪个很好并且可行，但是为什么需要它呢？ 没有明显的好处。 并且，根据您使用的工具，如果您动态生成捆绑软件，使用CDN可能会更容易。另一种可以提供与Java有关的详细信息的东西是“粘性会话”。 拥有它们不是一个好主意，但是请注意，您可以使用会话将有关用户的数据存储在内存中。 您只需要配置servlet容器（或应用程序服务器）以共享该状态。 基本上，它仍然使用像memcached或ehcache这样的分布式缓存（我想您也可以使用会话集群的redis实现）。 这对开发人员来说是透明的，他仍然可以使用会话存储。
7. 端口绑定 –这是关于使您的应用程序独立运行，而不是依赖于您在其中部署的应用程序服务器的运行实例。 尽管这似乎更容易管理，但事实并非如此。 启动servlet容器并推动部署同样容易。 但是为了使您的应用程序绑定到端口，您需要具有用于该端口的工具。 他们提到了码头，还有tomcat的嵌入式版本和spring-boot（两者都包含在内）。 虽然我不反对端口绑定，但我想反过来也一样。 容器配置同样容易完成，无论您是丢弃特定于环境的xml文件，还是以编程方式进行操作，并从第3点中提到的文件中加载属性。这一点是–没关系–进行任何更容易的操作您。 更不用说您可能需要一些apache / nginx功能。
8. 并发 –这是关于使用本机进程的。 我认为，这与Java运行时不太相关，Java运行时在后台使用线程并隐藏了Unix进程。 顺便说一句，另一个显式引用unix（而不是保持与操作系统无关）。
9. 一次性性 –这就是拥抱失败。 即使一个或多个应用程序实例死亡，您的系统也必须运行良好。 这势必会发生，尤其是在“云中” 。 他们提到SIGTERM，这是* nix专用信号，而12因子应用程序的一般想法是与操作系统无关。 显然倾向于Linux，但这很好。
10. 开发/产品对等 –您的开发环境应与生产环境几乎相同（例如，避免出现某些“在我的机器上工作”的问题）。 但是，这并不意味着您的操作系统必须是在生产环境中运行的操作系统。 例如，您可以运行Windows，并在本地虚拟机（ 如我的安装程序 ）上运行数据库，MQ等。 这也强调了应用程序的操作系统独立性。 只要记住要保持版本相同即可。
11. 日志 –具有12个要素的应用程序建议将所有日志信息写入系统。 Java开发人员当然会不同意。 使用loggack / slf4j之类的工具，您可以在应用程序中管理日志记录方面，而无需依靠第三方工具来完成。 例如，日志轮换和清除，或发送到集中式日志记录设备 。 配置graylog或splunk适配器比让另一个进程从系统中收集并推送它要容易得多。 可以有特定于环境的日志配置，它还是与app.properties捆绑在一起的一个文件）。 如果这看起来很复杂，请考虑设置任何要捕获输出的复杂情况。
12. 管理员流程 –普遍同意，但我想说最好是在部署或启动时执行迁移，而不是手动进行，并且最好通过capistrano之类的方式手动更改生产中的“内容”，以确保它是在所有实例上都相同。

总体而言，考虑到以上评论，这是一整套很好的建议和构建我建议的应用程序的方法。

翻译自: https://www.javacodegeeks.com/2015/08/comments-on-the-twelve-factor-app.html

12 要素应用程序