漫谈分布式集群的负载均衡
于洋
05年参加工作，曾在在华为从事电信软件后台开发，14年入职腾讯数据平台部参与消息中间件的开发和设计。对分布式后台的开发和设计有浓厚兴趣。
漫谈分布式集群的负载均衡
1 什么是分布式集群
为了理解分布式集群这个概念，我们先说说这两个概念：“集群”和“分布式”。艺术来源于生活，计算机科学亦是如此。我们先通过例子，来了解一下现实生活中的“集群”和“分布式”。
从开餐馆说起：你开了一家餐馆，自己掌勺后厨（即做菜）。随着生意越来越好，发现自己忙不过来。于是你聘请了两个厨师，你们三位厨师就是一个“集群”。主要的职责是：洗菜、配菜、炒菜。你们关系如下：
随着生意越来越好，两种方式增加后厨的生产力：（1）继续增加厨师—相当于扩大集群；（2）引入流水线的机制，精细化分工。找人分担厨师洗菜、配菜等工作。类似下图
其实，流水线提现了分而治之的思想。即将一个大任务分解为多个小任务，提高小任务的生产力，从而提高了整体的生产力。而 “分布式”解决问题的思路：正是吸取了将大任务分步为多个小任务的思想，才得到通过跨地域的分布解决大问题。
从解决问题的角度，说一下分布式与集群的差异：
分布式是以缩短单个任务的执行时间来提升效率的；
集群则是通过提高单位时间内执行的任务数来提升效率。
从软件部署的角度，说一下分布式和集群的关系：
分布式是指将不同的业务分布在不同的地方；
集群则是将几台服务器集中在一起，实现同一业务；
分布式中的每一个节点，都可以做集群；
集群并不一定就是分布式的。
综上所述，一个较为理想的分布式集群应该是这样的： 一个分布式系统，是通过多个节点组成的，各节点都是集群化，并且各集群还是分布式的。
2 什么是负载均衡
一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。
提到的负载均衡，大家都想到了什么？DNS，LVS，nginx，HAProxy，反向代理，还是大名鼎鼎的F5？下面针对这些负载均衡技术做了分类和归纳。
其实上面描述的解决方案，通常都是互联网web接入方案的负载均衡。而web的服务方式是：通过简单易记的域名，屏蔽内部网络真实服务的IP，从而保证了内部服务器安全和可靠。基于这种服务方式，服务提供商可以在两处做负载均衡：
1. DNS解析（查询式），域名服务器在进行域名到服务IP反向解析的时候，根据用户网络接入特点等（电信、网通等 ），将就近的服务IP列表返回给用户。
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服务处理/存储的数据量是差不多的。
最后，我们回顾负载均衡的本质，小伙伴们千万不要为了负载均衡而均衡：
功能：单台服务器能力有限。当处理大量用户请求时，通过需要多台服务器组成系统，从而完成高并发的请求处理。
描述：N个客户端访问M个服务端的问题。（通常：M>1，N>>M）
难点：将N的请求/数据"均匀"分摊到多个M操作单元上执行，关键是"均匀"。
同学们，下课啦~~~
PS：由于分布式和负载均衡是两个比较大的课题，本篇文章讲解的内容只是针对具体的场景下阐述。如果没有讲解到小伙伴们想了解的方面，同学们可以自行google，baidu。
蓝鲸版本介绍
蓝鲸根据不同用户的需求对外提供了三套版本：
1.社区版：独立搭建的版本（当前稳定版本为V2.0.1），点击下载。
2.企业版：针对企业订制开发的版本，如有需要可联系蓝鲸客服QQ:800802001
3.公有云版：搭建在公有云上的版本，接入入口。
有关蓝鲸搭建布署以及使用方面的疑问，可加入QQ群(495299374)讨论交流。
您可能比较感兴趣
蓝鲸智云招募合作伙伴
合作共赢，是腾讯文化中重要的一部分。蓝鲸智云团队计划在全国范围内，大力发展生态体系，寻找优质的合作伙伴，共创运维领域的新局面。我们希望为解决方案供应商、集成商、服务商、应用软件开发商、咨询机构等提供更多的增值服务。
招募详情，请点击“访问蓝鲸官网”。
敬请关注
注明:马哥教育合作伙伴