我想创建一个带有微服务方法的web应用。
它将由一组作为Erlang应用程序的独立服务组成，我将能够单独启动和停止。在他们前面会有nginx服务器作为反向代理。
我应该把所有这些服务放在一个好的主管之下，还是应该把它们分开，每个都有一个主管?
我应该基于什么事实来做这个决定?
通过使每个服务成为Erlang应用程序，您已经得到了答案:每个应用程序都有一个单独的监督树。
在我看来，答案取决于独立发布应用程序的能力(或必要性)。
如果服务需要保持一致，因为接口可能会改变，那么拥有一个或有限数量的监督树(和应用程序)会更容易。服务的启动和停止是应用程序的一个接口。
如果你的服务是独立的，或者如果它们有非常稳定的接口(例如使用标准)，或者如果你不关心在运行中发布，那么每个服务一个应用程序似乎是一个首选的解决方案。
管理器在那里有一个明确的目标:让你控制在出现错误时管理你的状态的方式。
如果你有两个部分(A和B)的应用程序。每个存储一些状态:SA和SB。您可以根据一个问题来决定如何构建您的监督树:如果没有其他部分的状态，这部分状态是否有意义?如果A重新启动，SA被清除，但B没有重新启动，SB没有被清除，我的应用程序可以继续正常工作吗?
当看到supervisor时，人们通常会想到重启和重启率。可以说，这是主管不太重要的一部分。你真正应该关心的是从什么开始，以什么顺序开始。什么应该重新开始，以什么顺序重新开始?
Supervisor给出了三种重启策略。
- one_for_one——这假定被管理的子进程的状态是独立的。
- one_for_all—如果其中一个子进程死亡，其他子进程的状态也必须被清除
- rest_for_one -左边的子进程不应该重启，右边的子进程应该重启。
我真正喜欢的另一个概念是"错误内核"。在rest_for_one的情况下，左边的子节点是你的"错误内核"。
你必须知道的另一件重要的事情是，主管按从左到右的顺序开始所有的孩子，深度优先。并以相反的顺序停止。