说说我们的负载均衡武器

说说我们的负载均衡武器

最近发现,组内的小伙伴对负载均衡组件有哪些还不清楚,总结了下,希望对大家能有写用处。

当用户点击了一次页面,到后端server执行完返回,经过了好几次传递,每次上游调用下游,都要使用负载均衡组件。

使用负载均衡组件有什么好处?

  1. 自动选择存活的服务器,剔除掉“死掉”的服务。
  2. 保证请求能够按照分配均匀地分给服务端。
  3. 服务端增减机器,修改配置,对客户端透明。

以上几点最深的体会就是。

作为服务端,不必急急忙忙地恢复死掉的服务,只要有存活的节点存在即可。因为有时你可能正在吃饭或睡觉。

作为客户端,服务端更换你不必配合发布,减少工作量,代码不用做业务外的特殊逻辑。

下面我们从前到后一次看看都有哪些组件供我们使用。

如图所示,用户发起请求时,先从dns获取域名的真实ip,然后用真实ip来访问web服务器。用到了tgw组件。tgw对外是一个外网ip,后端挂载了多个内网实体ip。tgw会定期检测后端真实ip的服务是否存活,通过负载算法,选择存活的ip来进行访问。用户的请求会经过tgw,但是对用户来说是透明的。tgw的好处是节约外网ip,一个ip可以把一个机房的机器都挂载上。增减web server速度快,正常dns刷新要几小时到几天才全更新。

请求到了web server后,需要使用后端server提供的接口服务。通过CMLB组件来拉取后端的所有ip和负载分配配置,调用sdk来选择出一个最合适的ip,然后web server使用这个ip来访问后端。要接入CMLB,需要使用CMLB的sdk,在请求之前获取一次ip。虽然多加了几行代码,但是这种方式简单直观,还是web sever直接链接的后端。组件只起到了更新配置的作用。

但是在链接数据库,redis这些场景中,有些时候ip是写到php配置文件,或者框架配置文件中的。没有办法“多加几行选择ip的代码”。这时LB组件出现了,和tgw类似,只是都是内网ip。对服务调用方来说就是一个ip,只是在调用的过程中经过了LB的服务器做代理,他来透明的把请求转到后端适合的数据库服务器上。
用LB还有个注意的地方,通常LB为了节约资源,定3小时如果链接不使用,那么会自动断掉链接,对于客户端和服务器都是没有感知的,只有在下次调用时发现链接不存在了。所以要监控链接的返回值,发现连不上要重连。

又有个问题,CMLB和LB功能类似,是否可以互相替代呢?

答案是可以互相替代。LB是后来腾讯云出品的,如果没有CMLB完全可以用LB来实现同样的功能。CMLB在内部已经使用很多,相应的组件和监控也非常成熟。对于能控制代码获取ip的地方,使用CMLB。对于在配置中等写死ip的场景,使用LB。

总结

组件名称 使用场景和方法
tgw 服务外网域名服务使用,同一个机房的服务器挂载到一个tgw的虚ip上。如果有提供https服务,需要把证书上传到tgw配置网页。在nginx上只提供http服务就可以。tgw会帮助做ssl校验和转换成http服务给后端。
CMLB 使用agent拉取远端配置ip列表,本地调用sdk获取最适合的ip和程序。
LB 和tgw类似,是内网版。可以给数据库、队列挂载LB的虚ip。要监控链接断开。

转载请注明来源:说说我们的负载均衡武器
欢迎收听公众号

发表评论

电子邮件地址不会被公开。 必填项已用*标注