.net 微服务体系结构、请求平衡器

ibrsph3r  于 2023-03-13  发布在  .NET
关注(0)|答案(2)|浏览(128)

我有这样的建筑。

  1. API网关作为单个入口点和用户请求平衡器(Ocelot
    1.例如,2个微服务(data serviceprocessor service),每个微服务有两个示例。
    我们有这样一个交流的场景:用户通过API网关调用处理器服务,Ocelot 将此请求平衡到其中一个服务示例,processor service做一些工作,但它需要来自data service的信息才能继续。

问题

如何从processor service调用data service,并在调用此服务的同一位置直接获得响应。我可能的解决方案:
1.我可以使用简单的REST调用或gRPC,但我如何平衡服务示例之间的调用,我可以使用我们已经用于平衡用户请求的API网关,还是应该使用另一个内部平衡器?

  1. AMQP(RabbitMQ)也可以是解决方案,在这种情况下,我不需要一个平衡器,因为RabbitMQ已经有了一个。但是有没有可能在调用发起的同一个地方返回一个响应?
    哪一个是最好的解决方案(优点和缺点),或者你有其他的建议?
juud5qan

juud5qan1#

如果使用Phoesion Glow(一个专门为使用dotnet创建微服务而设计的框架),就可以与Internal Operation mechanism进行服务间通信。
要做到这一点,你需要

1.创建API项目并定义端点的原型:

namespace Foompany.Services.API.SampleService2.Modules.InteropSample1
{
    public abstract class Actions
    {
        [Interop]
        public static string InteropAction2(string firstname, string surname) => default;
    }
}

2.创建您的目标端点(声明上述类为API)

namespace Foompany.Services.SampleService2.Modules
{
    [API(typeof(API.SampleService2.Modules.InteropSample1.Actions))]
    public class InteropSample1 : FireflyModule
    {
        [InteropBody]
        public string InteropAction2(string firstname, string surname)
        {
            return $"Hi {firstname} {surname}";
        }
    }
}

3.从另一个服务调用/调用远程端点:

(Add API项目作为项目参考)

[Action(Methods.GET)]
public async Task<string> Action2()
{
    var firstName = "John";
    var surName = "Doe";
    var result = await Call(API.SampleService2.Modules.InteropSample1.Actions.InteropAction2, firstName, surName)
                        .InvokeAsync();
    return $"Service 2 said '{result}'";
}

InvokeAsync是将请求发送到目标服务的单个示例的RemotePprocedureCall(RPC)机制。还有其他机制,如消息和广播。

这个系统还提供了一个强类型API依赖项,这意味着如果API中发生了一些破坏性的更改,所有调用方都将在编译时失败

幕后发生了什么?

这就是开发人员要让一个服务与另一个服务通信所需要做的全部工作。在幕后,Phoesion GlowKaleidoscope是一个消息代理。例如RabbitMQ(也是基于类似AMQP的协议),它将自动创建适当的交换/队列/绑定,并且当您从代码调用其他服务时,Phoesion Glow还将处理服务发现/路由/序列化/反序列化/自动绑定。
更多信息,请阅读Documentation或查看完整的Sample Code

负载平衡

Phoesion GlowPrism是您云计算的入口。(如示例中的Ocelot).Prism作为Web服务器,将处理传入请求,但与Kaleidoscope一起使用(服务总线)负载平衡请求到最适合的Firefly*(服务主机)*。当部署到您的Glow设置时,系统会自动通知所有实体有关服务和路由指令的信息,因此您无需手动配置/更新网关。

架构

下面是该体系结构的顶层视图。Architecture Overview
有关architecture you can read this的更多信息。

  • 披露:我是Phoesion Glow* 的开发人员
envsm3lx

envsm3lx2#

最简单的解决方案

您在问题中提到您有2个processor services和2个data services。由于用户请求已经负载平衡,您可能不需要在data service示例之间重新平衡。

  • Processor Service #1已连接到Data Service #1
  • Processor Service #2已连接到Data Service #2

这种方法的主要缺点是:如果Data Service #1Data Service #2被淹没或无法访问,该怎么办?使用此设置,Processor Service #1Processor Service #2也无法使用,因为它的一个依赖项暂时不可用。

耐用解决方案

正如你在问题中指出的,还有其他解决办法。
如果您在Data Service示例前面应用 * 内部负载平衡器 *,则Processor Service示例将隐藏示例的不可访问性。Processor Services不知道是单个Data Service示例(由于流量低)还是4个或更多示例(由于负载高)。
如果你想使用一个消息系统,那么你可以将这两个服务从时间和空间上分离开来。但是这也带来了一系列新的挑战。我不建议仅仅因为这个问题就引入一个消息系统。Event-driven architectures很棒,但是与基于RPC的服务集成有很大的不同。

相关问题