我一直在深入学习Erlang，在完成Joe Armstrong的“编程Erlang”之后，有一件事我不断回归 .
在我看来，Supervisor会为每个子处理程序生成一个进程 . 因此，每个声明的gen_server类型处理程序将作为单独的进程运行 .
如果您正在构建一个小型Web服务器，并且您希望每个请求都是自己的进程，会发生什么 . 你是否仍然遵循OTP原则并以某种方式使用gen_server（如何？），或者你是否创建了自己的行为？
Cowboy如何处理这个问题，例如 . ？它仍然使用gen_server吗？
2 回答
tl; dr：我发现试图找出“正确”的监督结构，项目的开始是一种过早优化的形式 .
设计监督树的“正确”方式取决于应用程序的工作部分正在做什么 . 在Web服务器的情况下，我可能会首先探索以下内容：
高级主管（单数）
数据服务主管（每种服务类型一个）
Worker 池（服务sup下的所有 Worker ）
客户端连接主管（一）
连接工作池（或每个连接一个，必须使用它来决定）
逻辑主管（视情况而定 - 此处存在大量差异，具体取决于问题域）
Worker 或主管（视情况而定 - 必须探索/了解问题域，以了解应该如何构建这个问题）
因此，在较低级别，每个主管类型的几个工作人员 . 我没有使用牛仔所以我不知道它是如何组织的 . 我要说的是，虽然处理服务于网页的数据服务的机制相对微不足道，但系统中实际执行核心问题解决工作的部分可能不是，这将决定一切有趣的事情 . 系统 .
将解决问题的位混合在与Web显示或连接处理位相同的模块中是一件坏事 . 理想情况下，您应该能够在本机应用程序，Web应用程序和网络服务中使用相同的逻辑单元而无需任何更改 .
最终，您是否应该为工作人员提供1：1的主管或1：n的答案取决于您正在做什么以及重启策略为您提供恢复到已知一致状态，用户感受到的延迟和资源之间的最佳 balancer 用法 .
关于Erlang，我最喜欢的一件事就是我可以从像上面那样的天真的主管结构开始，一直玩它直到我看到它不那么好的地方，而且很容易切换周围的东西并尝试替代方案而不会从根本上改变我的系统 . （如果你在它们周围写出适当的抽象，那么使用替代数据表示也是如此 . ）首先，得到一些在测试中起作用的东西 . 然后加载它，看看你是否可以打破它 . 在了解问题的实际位置后，开始担心细节问题 .
这是在erlang中为每个客户端生成一个服务器的常见模式，然后您将使用一个使用simple_one_to_one策略的主管为子服务器 . 这允许要求服务器启动服务器on_demand . 通常，当您不知道需要多少进程以及进程何时独立时（一个进程的崩溃不会影响另一个进程），就会使用此方法 .
在网站learnyousomeerlang.com（LYSE supervisor chapter）中有一个非常好的信息 . 整个网站值得一读 .