码迷,mamicode.com
首页 > 其他好文 > 详细

一个支持高网络吞吐量、基于机器性能评分的TCP负载均衡器gobalan

时间:2020-02-10 22:20:46      阅读:83      评论:0      收藏:0      [点我收藏+]

标签:分布   软负载   删除   har   nec   否则   服务启动   golang   改进   

一个支持高网络吞吐量、基于机器性能评分的TCP负载均衡器gobalan

作者最近用golang实现了一个TCP负载均衡器,灵感来自grpc。几个主要的特性就是:

  • 支持高网络吞吐量
  • 实现了基于机器性能评分来分配worker节点的负载均衡算法
  • 尽量做到薄客户端,降低客户端复杂性

项目开源地址

背景

先介绍几种常用的负载均衡机制,以下几种负载均衡方案介绍来自grpc服务发现&负载均衡

根据负载均衡实现所在的位置不同,通常可分为以下四种解决方案:

集中式LB(Proxy Model)

技术图片

在服务消费者和服务提供者之间有一个独立的LB,通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy等实现。LB上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向LB发起请求,由LB以某种策略,比如轮询(Round-Robin)做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力,能自动摘除不健康的服务实例。 该方案主要问题:

单点问题,所有服务调用流量都经过LB,当服务数量和调用量大的时候,LB容易成为瓶颈,且一旦LB发生故障影响整个系统;
服务消费方、提供方之间增加了一级,有一定性能开销。

进程内LB(Balancing-aware Client)

技术图片

针对第一个方案的不足,此方案将LB的功能集成到服务消费方进程里,也被称为软负载或者客户端负载方案。服务提供方启动时,首先将服务地址注册到服务注册表,同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查,服务消费方要访问某个服务时,它通过内置的LB组件向服务注册表查询,同时缓存并定期刷新目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。LB和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。该方案主要问题:

开发成本,该方案将服务调用方集成到客户端的进程里头,如果有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本;
另外生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,升级较复杂。

独立进程LB(External LB service)

技术图片
该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似。
不同之处是将LB和服务发现功能从进程内移出来,变成主机上的一个独立进程。主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立LB进程做服务发现和负载均衡。该方案也是一种分布式方案没有单点问题,一个LB进程挂了只影响该主机上的服务调用方,服务调用方和LB之间是进程内调用性能好,同时该方案还简化了服务调用方,不需要为不同语言开发客户库,LB的升级不需要服务调用方改代码。
该方案主要问题:部署较复杂,环节多,出错调试排查问题不方便。

gRPC服务发现及负载均衡设计

gRPC开源组件官方并未直接提供服务注册与发现的功能实现,但其设计文档已提供实现的思路,并在不同语言的gRPC代码API中已提供了命名解析和负载均衡接口供扩展。

技术图片

其基本实现原理:

服务启动后gRPC客户端向命名服务器发出名称解析请求,名称将解析为一个或多个IP地址,每个IP地址标示它是服务器地址还是负载均衡器地址,以及标示要使用那个客户端负载均衡策略或服务配置。
客户端实例化负载均衡策略,如果解析返回的地址是负载均衡器地址,则客户端将使用grpclb策略,否则客户端使用服务配置请求的负载均衡策略。
负载均衡策略为每个服务器地址创建一个子通道(channel)。
当有rpc请求时,负载均衡策略决定那个子通道即grpc服务器将接收请求,当可用服务器为空时客户端的请求将被阻塞。

优缺点分析

可以看到第一种负载均衡是在server端进行负载均衡(也叫Proxy负载均衡),第二种和第三种负载均衡方案都是在客户端进行的负载均衡,这两类负载均衡各有优缺点

Proxy负载均衡优缺点

优点

  • 隐藏后端服务器。
    反向代理能够隐藏后端服务器,所有浏览器都不会与后端服务器直接交互,从而能够确保调度者的控制权,提升集群的整体性能。
  • 故障转移
    反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时,能够及时通知反向代理服务器,并立即将其删除。
  • 合理分配任务
    但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据服务器的配置设置不同的权重,权重的不同会导致被调度者选中的概率的不同。

缺点

  • 调度者压力过大
    由于所有的请求都先由反向代理服务器处理,那么当请求量超过调度服务器的最大负载时,调度服务器的吞吐率降低会直接降低集群的整体性能。
  • 制约扩展
    当后端服务器也无法满足巨大的吞吐量时,就需要增加后端服务器的数量,可没办法无限量地增加,因为会受到调度服务器的最大吞吐量的制约。

客户端负载均衡优缺点

优点

  • 客户端和提供服务的服务器进行直连,没有了Proxy负载均衡器的瓶颈,并且容易扩展。

缺点

  • 客户端逻辑会变得复杂,它需要追踪服务端的机器负载和健康度,需要实现负载均衡算法。第二种负载均衡机制还依赖客户端的实现语言,需要为不同语言实现不同的负载均衡版本。
  • 客户端必须是受信任的,因为客户端能够拿到所有负载均衡节点的信息。

grpc负载均衡优缺点

优点

grpc负载均衡是上述两种负载均衡机制的结合体,通过添加一个额外的load balancer server来实现,它基本上避免了两种负载均衡机制的缺点。

  • 负载均衡节点健康度检查和机器负载通过这个load balancer server来实现,并且复杂的负载均衡算法都由其来实现,避免了客户端过于复杂的缺点,客户端只是实现一些简单的负载均衡算法。
  • 服务网络连接依然采用直连,绕过load balancer,解决了网络吞吐量的问题。

缺点

  • 客户端仍然是需要受信任的

gobalan

为什么要实现一个负载均衡器,因为目前为止没有找到满足作者要求的负载均衡器。市面上负载均衡器大多是proxy负载均衡器,像LVS,Haproxy,上行流量会成为它们的瓶颈。grpc的负载均衡只是做了设计,并没有实现,并且grpc负载均衡设计的初衷是per-call的,设计的目标应该是针对微服务中的API调用,并且感觉grpc负载均衡设计还有改进的空间。

gobalan有一下特点:

  • gobalan是per-connection的,也就是一次TCP连接请求做一次负载均衡。
  • gobalan所有负载均衡逻辑均在负载均衡器中实现,包括服务健康检查,机器负载信息收集,负载均衡算法的实现。
  • 客户端只需要实现服务节点的请求和返回值解析两个逻辑就能使用gobalan,我们需要的是超薄客户端。
  • 客户端和服务节点采用直连,避免了proxy负载均衡的网络带宽瓶颈。

整个系统的交互流程是下面这个样子:

技术图片

关于gobalan的更加详细的设计原理和使用方法,参考项目地址

参考

高并发解决方案--负载均衡

grpc服务发现&负载均衡

gRPC Load Balancing

一个支持高网络吞吐量、基于机器性能评分的TCP负载均衡器gobalan

标签:分布   软负载   删除   har   nec   否则   服务启动   golang   改进   

原文地址:https://www.cnblogs.com/harlanc/p/12290634.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!