12factor 建议不要守护进程。这样做有什么缺点？
问问题
511 次
3 回答
7
他们关注的不是守护进程本身，而是管理该进程并确保其正常运行。他们引用了围绕守护进程构建的 kludgey 框架的实例，其中守护进程的编写并未着眼于管理，因此需要过多的资源来重新启动它、在它之后进行清理等。
他们指出并推荐使用系统管理工具软件，包括smf(Solaris)、upstart(Linux)、launchd(OSX)，甚至是古老的init和ttys（较旧的 Unix 版本和基于 BSD 的发行版）。他们没有提到systemd（也包括 Linux），但这可能是时机。他们也没有提到inetd或者xinetd也使基于网络的守护进程的管理和重新启动变得容易和简单。
所以他们并不是真的建议不要守护进程。他们建议在您发明了漂亮的守护程序服务流程之后，您不要围绕它重新发明管理框架。开发您的服务器时要了解它的管理方式，这可能会大大减少所涉及的总工作量。就目前而言，这是一种devops态度。
于 2014-11-03T01:43:48.000 回答
0
我将添加到主管列表中，不朽的 *nix 跨平台（与操作系统无关）主管，它简化了 12 个因素的做法。
时间戳
默认情况下，日志中的选项时间戳设置为 false，这有利于遵循 12 因素的应用程序，并且在日志结构为“JSON”的情况下，可以轻松解析它。
于 2017-09-07T19:22:51.757 回答
0
基本上，目的是从容器中删除服务管理逻辑，并将其作为基础设施的一部分
考虑服务崩溃的场景 - 基础设施可能决定在不同的服务器上重新启动它，而不是重新启动映像中的服务，这在服务器加载或发生故障的情况下可能无济于事
于 2017-11-25T21:53:49.297 回答