首页 文章

使用Meteor的级联微服务

提问于
浏览
0

我一直在研究扩展Meteor,并通过使用Meteor Cluster package获得了一个想法;

  • 创建一个用户连接的超级服务*,包含每个微服务使用的一般核心包(api,app,salesSite等会使用它的包),

  • 然后,超级服务路由到适当的微服务(例如,应用程序),为其提供其自己的包的功能 .

(* - 就像超级和次级,不是很棒......我的意思是......但是......)

我的想法是,我可以将每个服务级联为超级服务的超集 . 这也使我能够以级联服务风格巧妙地继承其他服务的功能 . 例如 . ,

unauthedApp> guestApp> userApp> modApp> adminApp,

对于应用程序,其中先前服务的功能被继承到前面的服务(例如,沿着该链的更右侧,添加和继承更多的额外功能) .

这可能吗?

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

[[[[[ BIG EDIT #2: ]]]]]

想想我正在努力使解决方案适合这个问题,所以让我重新解释一下,这个问题可以根据问题而不是我试图实现的解决方案来回答 .

基本上,我想“继承”(缺少一个更好的词)包依赖于所需的功能,因此不会通过网络不必要地发送代码 .

因此,从核心软件包开始,我希望我的所有服务都有库,然后我想根据需要进一步“添加”功能 . 然后我想添加页面包,如果提供基于页面的服务(而不是,例如,API服务,它不呈现页面),然后是适当的基于角色的页面包等,直到最具体的包是添加 .

我的想法是,我可以以这样一种方式 Build 服务链,使我能够从最通用的服务到最具体的服务,并最终以多种服务的包组合结束 . 因此,例如,guestApp,可能是核心包通用页面包通用应用程序包unauthApp打包guestApp包,因此不添加任何不必要的包 .

还有我正在描述的这个虚构模式,我不需要将所有核心软件包添加到每个微服务中 - 我可以在核心软件包中处理它们,就在我上面讨论过的包遍历的顶部而不是不得不担心忘记将包添加到“继承”包中 .

希望我的理由在这里有道理,我希望你们知道这样做的最佳实践 . 谢谢!

1 回答

  • 1

    简答:是的!这对微服务架构很有用 .

    答案很长:微服务不一定像OOP那样为您提供继承机制 . 您应该将微服务视为独立的“函数”,它们接收输入并响应输出/操作 . 任何微服务都可以依赖于另一个微服务来完成自己的任务 .

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

    您可以使用一个或几个面向“前端”的服务,这些服务使用少量其他后端微服务,其端口不对公共网络开放 .

    微服务的缺点是其“最小占地面积” . 微服务的想法是围绕一些主要的好处:

    • 单独核心服务,使它们可以独立"maintained"

    • 单独核心服务,使它们可以独立"replaced"

    • 单独核心服务,以便它们可以独立"scaled"

    但是,每个微服务,作为节点/流星应用程序,即使只是空闲并等待连接,也将具有最小的cpu / ram足迹 .

    此外,从管理者的角度来看,管理单个单一应用程序或仅仅是一些“大型”服务要比管理数十个单独部署要容易得多 .

    因此,在所有工程决策中,正确的答案意味着某种“ balancer ” .

    编辑:引用继承

    根据OP的评论,微服务确实可以从父代码作为函数或类引用,并且可以组成(函数)或从(类)继承,因为在所有底层功能都是DDP endpoints 之后 .

    如果您正在使用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并从中继承,根据需要公开其接口 .

相关问题