使用 Meteor 级联微服务

Question

我一直在研究如何缩放 Meteor，并有一个使用 Meteor Cluster package 的想法；

• 创建一个用户连接的超级服务*，其中包含每个微服务使用的通用核心包（api、app、salesSite 等将使用其包），
• 然后，超级服务路由到适当的微服务（例如应用程序），为其提供自己的包的功能。

(* - 就像在 super- 和 sub- 中一样，并不是说它很棒...我的意思是它是但是...)

我可以将每个服务级联为超级服务的超集。这也将允许我以级联服务风格巧妙地继承其他服务的功能。例如，

unauthedApp > guestApp > userApp > modApp > adminApp,

对于应用程序，前一个服务的功能被继承到前一个服务（例如，沿着该链越靠右，添加和继承的额外功能越多）。

这可能吗？

编辑：如果可能，是否提供了如何使用微服务实现这种模式的示例？

[[[[[大编辑#2：]]]]]

认为我正在尝试制定适合问题的解决方案，所以让我重新解释一下，以便可以根据问题而不是我尝试实施的解决方案来回答这个问题。

基本上，我想“继承”（因为没有更好的词）依赖于所需功能的包，这样就不会通过线路不必要地发送任何代码。

因此，从核心包开始，其中包含我希望我的所有服务都拥有的库，然后我想根据需要进一步“添加”功能。然后，如果提供基于页面的服务（而不是不呈现页面的 API 服务），我想添加页面包，然后添加适当的基于角色的页面包等，直到最具体的包已添加。

我的想法是，我可以制作服务链，使我可以从最通用的服务遍历到最具体的服务，并最终以来自多个服务的包的组合结束。因此，例如 guestApp，可能是核心包 + 通用页面包 + 通用应用包 + unauthApp 包 + guestApp 包，因此不会添加不必要的包。

此外，通过我所描述的这种虚构模式，我不需要将所有核心包添加到每个微服务 - 我可以在我讨论过的包遍历顶部的核心包中处理它们以上，不必担心忘记将包添加到“继承”包中。

希望我在这里的推理是有道理的，我希望你们知道这样做的最佳实践。谢谢！

Answer 1

简短回答： 是的！这对微服务架构很有用。

长答案： 微服务不一定像 OOP 那样为您提供继承机制。您应该将微服务视为独立的“功能”，它接受输入并以输出/动作响应。任何微服务都可以依赖另一个微服务来完成自己的任务。

然后，您“组合”必要的微服务以实现最终输出/操作。

您可以拥有一个或几个面向 Web 的“前端”服务，这些服务混合使用一些其他后端微服务，这些后端微服务的端口未对公共网络开放。

微服务的缺点是它的“最小占用空间”。微服务的理念围绕着一些主要优势：

• 分离核心服务，以便它们可以独立“维护”
• 分离核心服务，以便它们可以独立“替换”
• 分离核心服务，以便它们可以独立“扩展”

但是，作为节点/流星应用程序的每个微服务，即使它们只是空闲并等待连接，也会有其最小的 cpu/ram 占用空间。

此外，从 devops 的角度来看，管理一个单一的应用程序或几个“大型”服务比管理数十个单独的部署要容易得多。

因此，对于所有工程决策，正确的答案都意味着某种“平衡”。

编辑：对继承的引用

根据 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 中并从它继承，并根据需要公开其接口。