使用 Meteor 级联微服务
Cascading microservices using Meteor
我一直在研究扩展 Meteor，并通过使用 Meteor Cluster package;
有了一个想法
- 创建用户连接的超级服务*，包含每个微服务要使用的通用核心包（api、app、salesSite 等将使用它的包） ,
- 超级服务然后路由到适当的微服务（例如，应用程序），为其提供自己的包的功能。
(* - 与超级和次级一样，并不是说它很棒......我是说它是......）
我的想法是我可以将每个服务级联为超级服务的超集。这也让我能够以级联服务方式巧妙地继承其他服务的功能。例如，
unauthedApp > guestApp > userApp > modApp > adminApp,
对于应用程序，前一个服务的功能继承到前一个服务（例如，沿着该链越靠右，添加和继承的额外功能越多）。
这可能吗？
编辑：如果可能，是否提供了如何使用微服务实现这种模式的示例？
[[[[[ 大编辑#2：]]]]]
我想我正在尝试制定适合问题的解决方案，所以让我重新解释一下，以便可以根据问题而不是我正在尝试实施的解决方案来回答这个问题。
基本上，我想“继承”（找不到更好的词）依赖于所需功能的包，这样就不会通过线路发送不必要的代码。
因此，从核心包开始，它具有我希望我的所有服务都具有的库，然后我想根据需要进一步“添加”功能。然后，如果提供基于页面的服务（而不是 API 服务，它不呈现页面），我想添加页面包，然后添加适当的基于角色的页面包等，直到添加了最具体的包。
我的想法是，我可以用这样一种方式来制作服务链，即我可以从最通用的服务遍历到最具体的服务，最终以来自多个服务的包的组合结束。因此，例如guestApp，可能是核心包+通用页面包+通用应用程序包+unauthApp包+guestApp包，所以没有添加不必要的包。
还有我描述的这个假想模式，我不需要将我所有的核心包添加到每个微服务——我可以在包遍历顶部的核心包中处理它们上面已经讨论过，不必担心忘记将包添加到“继承”包中。
希望我在这里的推理是有道理的，我希望你们知道这样做的最佳实践。谢谢！
简答：
是的！这是微服务架构的一个很好的用途。
长答案：
微服务不一定像 OOP 那样为您提供继承机制。您应该将微服务视为独立的 "functions"，它接收输入并以 output/action 响应。任何微服务都可以依赖另一个微服务来完成自己的任务。
然后，你"compose"需要微服务才能实现最终的output/action。
您可以有一个或几个面向 Web 的 "frontend" 服务，这些服务混合使用一些端口未向 public 网络开放的其他后端微服务。
微服务的缺点是它 "minimum footprint"。微服务的想法围绕着一些主要好处：
- 分离核心服务，以便它们可以 "maintained" 独立
- 分离核心服务，以便它们可以 "replaced" 独立
- 分离核心服务，以便它们可以 "scaled" 独立
但是，作为 node/meteor 应用程序的每个微服务将具有其最小 cpu/ram 占用空间，即使它们只是空闲并等待连接。
此外，从 devops 的角度来看，管理单个整体应用程序或仅几个 "largish" 服务比管理数十个单独的部署要容易得多。
因此，对于所有工程决策，正确答案都意味着某种 "balance"。
编辑：参考继承
根据 OP 的评论，微服务确实可以从父代码作为函数或 类 引用，并且可以组合（函数）或继承自（类），因为毕竟基础功能是 DDP 端点。
如果您使用的是 meteorhacks 的集群包
// create a connection to your microservice
var someService = Cluster.discoverConnection("someService");
// call a normal meteor method from that service
var resultFromSomeService = someService.call("someMethodFromSomeService");
因此，与任何 javascript 代码一样，您可以将上述代码包装在函数或 class with its constructor and all 中并从中继承，根据需要公开其接口。
我一直在研究扩展 Meteor，并通过使用 Meteor Cluster package;
有了一个想法- 创建用户连接的超级服务*，包含每个微服务要使用的通用核心包（api、app、salesSite 等将使用它的包） ,
- 超级服务然后路由到适当的微服务（例如，应用程序），为其提供自己的包的功能。
(* - 与超级和次级一样，并不是说它很棒......我是说它是......）
我的想法是我可以将每个服务级联为超级服务的超集。这也让我能够以级联服务方式巧妙地继承其他服务的功能。例如，
unauthedApp > guestApp > userApp > modApp > adminApp,
对于应用程序，前一个服务的功能继承到前一个服务（例如，沿着该链越靠右，添加和继承的额外功能越多）。
这可能吗？
编辑：如果可能，是否提供了如何使用微服务实现这种模式的示例？
[[[[[ 大编辑#2：]]]]]
我想我正在尝试制定适合问题的解决方案，所以让我重新解释一下，以便可以根据问题而不是我正在尝试实施的解决方案来回答这个问题。
基本上，我想“继承”（找不到更好的词）依赖于所需功能的包，这样就不会通过线路发送不必要的代码。
因此，从核心包开始，它具有我希望我的所有服务都具有的库，然后我想根据需要进一步“添加”功能。然后，如果提供基于页面的服务（而不是 API 服务，它不呈现页面），我想添加页面包，然后添加适当的基于角色的页面包等，直到添加了最具体的包。
我的想法是，我可以用这样一种方式来制作服务链，即我可以从最通用的服务遍历到最具体的服务，最终以来自多个服务的包的组合结束。因此，例如guestApp，可能是核心包+通用页面包+通用应用程序包+unauthApp包+guestApp包，所以没有添加不必要的包。
还有我描述的这个假想模式，我不需要将我所有的核心包添加到每个微服务——我可以在包遍历顶部的核心包中处理它们上面已经讨论过，不必担心忘记将包添加到“继承”包中。
希望我在这里的推理是有道理的，我希望你们知道这样做的最佳实践。谢谢！
简答： 是的！这是微服务架构的一个很好的用途。
长答案： 微服务不一定像 OOP 那样为您提供继承机制。您应该将微服务视为独立的 "functions"，它接收输入并以 output/action 响应。任何微服务都可以依赖另一个微服务来完成自己的任务。
然后，你"compose"需要微服务才能实现最终的output/action。
您可以有一个或几个面向 Web 的 "frontend" 服务，这些服务混合使用一些端口未向 public 网络开放的其他后端微服务。
微服务的缺点是它 "minimum footprint"。微服务的想法围绕着一些主要好处：
- 分离核心服务，以便它们可以 "maintained" 独立
- 分离核心服务，以便它们可以 "replaced" 独立
- 分离核心服务，以便它们可以 "scaled" 独立
但是，作为 node/meteor 应用程序的每个微服务将具有其最小 cpu/ram 占用空间，即使它们只是空闲并等待连接。
此外，从 devops 的角度来看，管理单个整体应用程序或仅几个 "largish" 服务比管理数十个单独的部署要容易得多。
因此，对于所有工程决策，正确答案都意味着某种 "balance"。
编辑：参考继承
根据 OP 的评论，微服务确实可以从父代码作为函数或 类 引用，并且可以组合（函数）或继承自（类），因为毕竟基础功能是 DDP 端点。
如果您使用的是 meteorhacks 的集群包
// create a connection to your microservice
var someService = Cluster.discoverConnection("someService");
// call a normal meteor method from that service
var resultFromSomeService = someService.call("someMethodFromSomeService");
因此，与任何 javascript 代码一样，您可以将上述代码包装在函数或 class with its constructor and all 中并从中继承，根据需要公开其接口。