代码之家  ›  专栏  ›  技术社区  ›  user2173353

如何在.NET中平衡服务的负载

  •  1
  • user2173353  · 技术社区  · 7 年前

    我正在考虑使用面向服务的体系结构(SOA)构建一个应用程序。

    这种架构不像microservices解决方案那样复杂和混乱(我认为),但我也面临着类似的设计问题。假设我有ServiceA类型的服务,它将工作发送到ServiceB类型的服务。我猜,如果我使用队列,那么负载平衡就不会是问题(因为消费者会从队列中获取他们能处理的东西)。但是队列往往会在代码中产生一些不好的异步,需要额外的努力来修复。所以,我更倾向于在服务之间使用HTTP调用,使用高效和惊人的 async/await

    所以我的问题是:

    1. 异步/等待 它的功能类似于HTTP调用,在需要的地方返回结果,而不是在无法继续原始执行流的回调中?
    2. 在使用HTTP时,如何平衡服务之间的流量并检测不适合新分配的节点?我的意思是,我可能可以自己从头开始设计一些东西,但现在应该有一些标准的方法、库或框架来做到这一点。我在网上找到的最好的是 this

    更新: 我现在发现了这个问题,它也要求排队等候: awaitable Task based queue

    1 回复  |  直到 7 年前
        1
  •  1
  •   Francesc Castells    7 年前

    关于您的第一个问题,NServiceBus是.NET的一个商业框架,它对消息传输进行了抽象,并在上面添加了许多特性,它具有您想要的特性。他们实际上称之为 callbacks “用法如下:

    var message = new Message();
    var response = await endpoint.Request<ResponseMessage>(message);
    log.Info($"Callback received with response:{response.Result}");
    

    这个简单的语法将要做的是将消息放入队列中并等待(异步)直到消息被后端服务处理并回复。响应是队列中响应类型的消息。

    在ServiceB中,您将执行以下操作:

    public class Handler : IHandleMessages<Message>
    {
      public Task Handle(Message message, IMessageHandlerContext context)
      {
        var responseMessage = new ResponseMessage
        {
            Result = "TheResult"
        };
        return context.Reply(responseMessage);
      }
    }
    

    注意,这样做的缺点是,如果ServerA在等待响应时宕机,您将永远不会收到响应。因此,不建议在大多数情况下使用此模式。

    Service Fabric .