web应用程序的方法

是最近的一种编写web应用程序的方法(和/或宣言),有望变得非常流行。虽然我不完全同意这些建议，但我会快速浏览所有12个因素，并根据Java生态系统来讨论它们，提到绝对的“必须”和我不同意的地方。欲了解更多信息，请

1. 代码库–一个代码库，多个部署。这意味着你不能有不同版本的不同代码库。分支没问题，不同的回购就不行。我甚至会更进一步，不推荐Subversion。不是因为它不好，而是因为git和mercurial做得一样多。您可以像使用SVN一样使用git/mercurial，但不能反过来。DVCS的工具(例如SourceTree)已经很好了
2. 属国–显然，您必须在清单中放置尽可能多的依赖项(例如pom.xml)。宣言建议不要依赖预装软件，例如ImageMagick或Pandoc，但我不会那么严格。如果您的部署是自动化的，并且您保证了给定工具的存在，那么您就不应该花费几天的时间来试图将它包装在您的工作语言库中。如果像把一个可执行的脚本放在一个jar文件中，然后提取它那样简单，那就很好。但是如果它需要安装，并且你确实需要它(ImageMagick确实是一个很好的例子)，我认为期望它被安装并没有错。只需在启动时检查它是否存在，如果不存在，则快速失败。
3. 配置–这里最重要的规则是–永远不要在源代码报告中提交特定于环境的配置(最重要的是:密码)。否则，您的生产系统可能会很脆弱，至少有三分之的，mysql可能不允许外部连接，但我打赌没有人证实这一点)。

   但是从那以后，我的观点与12因素应用程序的观点不同。不，您不应该在配置中使用环境变量。因为当你有15个变量时，如果它们在一个文件中，管理起来会容易得多。你可以用一些shell脚本来设置它们，但是这违背了操作系统的独立性。有键值的。属性文件(Java对其有本机支持)，我认为只将该文件的绝对路径作为环境变量(或JVM参数)传递是一种更好的方法。我。例如，CONFIG _ PATH =/var/conf/app . properties，它在启动时加载。

   在您的应用程序中，您可以保留一个空白的app.example.properties，它包含所有要配置的属性的列表——数据库凭证、外部系统的密钥和机密等。(没有任何值)。这样，您可以在一个地方拥有所有属性，并且很容易发现在给定的场景中您可能需要添加/重新配置什么。如果您使用环境变量，您必须在一个txt文件中有一个它们的列表，以便使它们“可被发现”，或者让开发人员深入代码以找出哪些属性是可用的。

   最后，但同样重要的是，当我说您不应该将属性文件提交给源代码控制时，有一个非常具体的例外。您可以选择对环境配置进行版本控制。它必须是一个私有的回购协议，具有有限的访问权限，但(开发)运营可以有一个地方来保存每个环境的属性和其他细节，并进行版本控制。使用属性文件更容易做到这一点(使用env变量也不是不可能，但是同样需要一个shell脚本)。

   12因素应用程序作者警告环境爆炸。如果每个环境都有一个属性文件，这些文件可能会增加。但是他们不需要。您可以像管理环境变量一样更改属性文件中的值。

https://weibo.com/ttarticle/p/show?id=2309404784613099962989

1. 后勤服务–这是关于平等地对待您的应用程序所依赖的外部服务，无论它们是由您管理还是由另一方管理。从应用程序的角度来看，这并不重要。我在这里可以补充的是，你要尽量把这个最小化。如果内存中的队列可以，那么不要部署单独的MQ。如果内存缓存可以，就不要部署redis实例。如果嵌入式数据库可以，不要管理DB安装(例如neo4j提供了一个嵌入式变体)。诸如此类。但是，如果您确实需要全功能的外部服务，请将它的路径/凭证设置为可配置的，就像它是外部的一样(而不是，例如，默认情况下指向localhost)。
2. 构建、发布、运行–描述得这样的生命周期是很棒的。但是设置它需要时间和资源。根据您的限制，您可能没有完整的管道，并且有些阶段可能比理想状态下更加手动和流畅。有时，例如在启动的早期阶段，能够在运行的产品服务器上交换类文件或网页可能是有益的，而不是经历一个完整的发布过程(您没有时间完全自动化)。我知道这听起来像异端邪说，人们应该努力实现完全自动化和分离的过程，但在实现之前，不要完全放弃在生产中手动删除固定文件的选项。只要您不总是这样做，并且您不会以一个您不知道运行哪个版本的代码库的生产环境而告终。
3. .

   但是，有一点我不同意。打包资产的12因素首选方式是在构建期间(例如，将所有css文件合并为一个)。这有几个缺点——你不能动态地组合资产，例如，如果你有6个脚本，在一个页面上你需要4个，在另一个页面上你需要第一个页面上使用的2个，另外2个，那么你必须事先构建所有这些排列。这很好，也很有效，但是为什么需要它呢？没有明显的好处。根据您使用的工具，如果您动态生成包，使用CDN可能会更容易。

   另一个可以给出更多Java相关细节的是“粘性会话”。拥有它们并不是一个好主意，但是请注意，您可以使用会话在内存中存储关于用户的数据。您只需配置您的servlet容器(或应用服务器)来共享该状态。基本上，它仍然使用分布式缓存，如memcached或ehcache(我猜您也可以使用会话集群的redis实现)。这对开发人员来说是透明的，他仍然可以使用会话存储。