漫谈分布式集群的负载均衡—口水篇

作者:于洋

1 什么是分布式集群

为了理解分布式集群这个概念,我们先说说这两个概念:“集群”和“分布式”。艺术来源于生活,计算机科学亦是如此。我们先通过例子,来了解一下现实生活中的“集群”和“分布式”。

从开餐馆说起:你开了一家餐馆,自己掌勺后厨(即做菜)。随着生意越来越好,发现自己忙不过来。于是你聘请了两个厨师,你们三位厨师就是一个“集群”。主要的职责是:洗菜、配菜、炒菜。你们关系如下:

随着生意越来越好,两种方式增加后厨的生产力:(1)继续增加厨师—相当于扩大集群;(2)引入流水线的机制,精细化分工。找人分担厨师洗菜、配菜等工作。类似下图。

其实,流水线提现了分而治之的思想。即将一个大任务分解为多个小任务,提高小任务的生产力,从而提高了整体的生产力。而“分布式”解决问题的思路:正是吸取了将大任务分步为多个小任务的思想,才得到通过跨地域的分布解决大问题。

从解决问题的角度,说一下分布式与集群的差异:

  • 分布式是以缩短单个任务的执行时间来提升效率的;
  • 集群则是通过提高单位时间内执行的任务数来提升效率。

从软件部署的角度,说一下分布式和集群的关系:

  • 分布式是指将不同的业务分布在不同的地方;
  • 集群则是将几台服务器集中在一起,实现同一业务;
  • 分布式中的每一个节点,都可以做集群;
  • 集群并不一定就是分布式的。

综上所述,一个较为理想的分布式集群应该是这样的:一个分布式系统,是通过多个节点组成的,各节点都是集群化,并且各集群还是分布式的。

2 什么是负载均衡

一台服务器的处理能力,主要受限于服务器自身的可扩展硬件能力。所以,在需要处理大量用户请求的时候,通常都会引入负载均衡器,将多台普通服务器组成一个系统,来完成高并发的请求处理任务。

提到的负载均衡,大家都想到了什么?DNS,LVS,nginx,HAProxy,反向代理,还是大名鼎鼎的F5?下面针对这些负载均衡技术做了分类和归纳。

其实上面描述的解决方案,通常都是互联网web接入方案的负载均衡。而web的服务方式是:通过简单易记的域名,屏蔽内部网络真实服务的IP,从而保证了内部服务器安全和可靠。基于这种服务方式,服务提供商可以在两处做负载均衡:

  1. DNS解析(查询式),域名服务器在进行域名到服务IP反向解析的时候,根据用户网络接入特点等(电信、网通等 ),将就近的服务IP列表返回给用户。 鹅厂GSLB是这方面的翘楚,大家有兴趣可自行km。
  2. 转发式,经过了上面DNS就近接入,当用户请求到就近服务的IP时。通常的做法是引入转发节点(通常是lvs或者nginx),通过均衡策略,将数据发送给多台RS(Real Server)。

在介绍web负载均衡的技术后,小伙伴们有没有这样的疑问。分布式系统各节点间的集群是如何做负载均衡呢?web的负载均衡是否适用于分布式节点间呢?等等。

其实不同的技术为了解决不同场景的问题,下图就罗列的常用的负载均衡使用场景。

上图通过三种颜色(包括图标和线条)的部分,分别说明了不同场景下的负载均衡。

  • 蓝色部分:用户通过DNS查询式,获取到了就近接入的业务服务(GSLB)。
  • 绿色部分:将用户请求集中转发的方法,完成了业务接入层的负载均衡。(LVS)
  • 红色部分:说明了通常分布式系统内部节点间的负载均衡。

其中,蓝色部分和绿色部分就是上面介绍的web负载均衡部分。下面一章我们重点分析一下如何考虑分布式节点间的负载均衡。

3 分布式集群的负载均衡

分布式各节点间的集群要做负载均衡的话,完全可以参考web负载均衡的方式来做,即查询式和转发式。但是通常后台开发的皮皮虾们基本不会这么做,根本原因就是不同场景下,考虑的侧重点是不同的,导致均衡的方式也有很大的差别。

我们先说一下两个web服务的基石:简单和安全。

  • 简单:使用域名的web服务,就是让用户通过简单易记的域名替代IP地址的访问方式,所以说“简单”应该说是用户的诉求。
  • 安全:而“安全”是服务提供商的诉求。就是对外服务时最大程度上屏蔽内部服务器的IP地址、网络部署,从而保证内部服务的安全。

针对上述两点,就需要在提供web服务时部署相应的节点支撑。如DNS解析,LVS转发、ngnix反向代理等。这些节点在保证服务的简单和安全时,也对系统服务引入了关键路径,增加了系统服务复杂性。

那么思考一下:分布式的各系统间,需要引入这么多节点来解决负载均衡的问题吗?

皮皮虾们的答案一定是:不需要☺。引入更多的节点意味越难保证系统的稳定性、可靠性。为什么这么说呢?

首先,分布式系统相对于集中式系统,是通过节点间相互传递消息通信协调工作的。节点间通信的不可靠性、不稳定性是分布式系统常态。这就导致系统的设计和开发时,需要针对每一种通信异常都有自身重试、恢复的解决方案。所以,引入更多的节点就意味着更复杂的重试、容灾、恢复等成本。

小伙伴们,有没有一种出师未捷身先死的感觉呢?oh, my god。还没有考虑负载均衡,仅仅是分布式系统间稳定性和可靠性,就已经很让人头疼了呢?所以说分布式的皮皮虾是苦逼的,落寞的,高贵的。(请珍惜您身旁的每只皮皮虾☺)

皮皮虾们不要皮,大司马出题了。

大司马:如果敌方打野没有在小地图的视野中,那么分布式系统的负载均衡要怎么做呢?

在学习了大司马的“正方形打野”,“边缘ob”,“你皮任你皮后”,这个问题我是这么看的。

我:更少的节点,更简单可靠的通信模式下,才能较好的完成负载均衡。

大司马:这位同学你很有灵性嘛。(看不懂段子的,看加粗字字哈☺)

怎么做好负载均衡呢?总结一下上面的段子就是一句话:simple is beautiful.(皮皮虾耳朵听出茧子了吧)。

  • 更少的节点:分布式业务节点数,需根据业务自身的特点确定。原则是:少且够用。
  • 简单可靠的通信模式:这里给一个简单的通信方式,udp请求发送+ udp服务确认。这种模式下可以减少因tcp链接管理造成的服务器资源消耗。

如果自身系统的还是很复杂的话,其实也是有迹可循的。下面我整理一下,考虑负载均衡的要点。大家多多思考,根据自身业务特点取舍,最终一定会做出不错的负载均衡效果。

再强调一个关键点,小伙伴们一定要先找到系统中的均衡要点是什么?这里在说一下:请求均衡和数据均衡(上图右下角)。

请求均衡理想效果是:每个RS服务处理的请求是差不多的。

数据均衡理想效果是:每个RS服务处理/存储的数据量是差不多的。

公司内部也有很好的均衡算法组件l5/cmlb等(自行km哈),可以较好支持udp的请求均衡。使用这种组件也有一些限制,大家确认是否适合自己的系统哈。

最后,我们回顾负载均衡的本质,小伙伴们千万不要为了负载均衡而均衡:

  • 功能:单台服务器能力有限。当处理大量用户请求时,通过需要多台服务器组成系统,从而完成高并发的请求处理。
  • 描述:N个客户端访问M个服务端的问题。(通常:M>1,N>>M)
  • 难点:将N的请求/数据"均匀"分摊到多个M操作单元上执行,关键是"均匀"。

同学们,下课啦 !

PS:由于分布式和负载均衡是两个比较大的课题,本篇文章讲解的内容只是针对具体的场景下阐述。如果没有讲解到小伙伴们想了解的方面,同学们可以自行google,baidu。☺

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏熊二哥

《大型网站技术架构》学习笔记-02架构篇

上一篇文章已经介绍了网站系统最需要关注的5大质量属性,接下来对这些特性进行详细介绍(这部分有部分内容会显得有些陈旧,之后会进行更新)。 ? 高性能架构 网站...

2555
来自专栏Java技术栈

聊聊微服务架构及分布式事务解决方案!

分布式事务场景如何设计系统架构及解决数据一致性问题,个人理解最终方案把握以下原则就可以了,那就是:大事务=小事务(原子事务)+异步(消息通知),解决分布式事务的...

1374

32位 or 64位:Apache CloudStack系统VM架构选择

最近我和一些朋友讨论了一个关于CloudStack的问题:为什么现在CloudStack 4.3同时提供32位或64位系统虚拟机的选项。我提出了一个观点,并将其...

2166
来自专栏VMCloud

【腾讯云的1001种玩法】在腾讯云上创建您的SQL Server 故障转移集群 (1)

在国内公有云厂商上搭建一套SQL Cluster的难度相信做Windows的童鞋都会很清楚,并非它的搭建有多少难度,只是很多细节需要注意。所以,今天我就来讲讲如...

5.3K2
来自专栏杨建荣的学习笔记

数据库无响应问题的紧急处理和分析 (r10笔记第42天)

黄金周里处理了一起紧急的问题,在外面幸亏有同事帮忙协助,等我赶回家去,赶紧继续处理。 首先问题是在晚饭时间左右开始发生,但是过了没多久又恢复了,所以这个问题暂时...

33012
来自专栏Spark学习技巧

Redis热点Key发现及常见解决方案

在日常工作生活中一些突发的的事件,例如:双十一期间某些热门商品的降价促销,当这其中的某一件商品被数万次点击浏览或者购买时,会形成一个较大的需求量,这种情况下就会...

1343
来自专栏后端技术探索

nginx安全加固心得

nginx发展多年,自身的安全漏洞比较少,发现软件漏洞,一般利用软件包管理器升级一下就好了。 本文侧重讲述的不是nginx自身的安全,而是利用nginx来加固w...

2285
来自专栏Android群英传

推送,从入门到放弃

1352
来自专栏WeTest质量开放平台团队的专栏

浅谈服务器性能测试的全生命周期——从测试、结果分析到优化策略

服务器性能测试是一项非常重要而且必要的工作,本文是作者Micheal在对服务器进行性能测试的过程中不断摸索出来的一些实用策略,通过定位问题,分析原因以及解决问题...

1873
来自专栏企鹅号快讯

使用Redis走进误区,该怎么办?

首先是一个产品线开发人员搭建起了一套庞大的价格存储系统,底层是关系型数据库,只用来处理一些事务性的操作和存放一些基础数据; 在关系型数据库的上面还有一套Mong...

2599

扫码关注云+社区