189 8069 5689
本文长度为 3032 字，预计读完需 1.1MB 流量，建议阅读 8 分钟。
创新互联公司是一家朝气蓬勃的网站建设公司。公司专注于为企业提供信息化建设解决方案。从事网站开发，网站制作，网站设计，网站模板，微信公众号开发，软件开发，小程序设计，10多年建站对成都阳光房等多个方面，拥有多年的网站制作经验。
前面两篇《 分布式系统关注点——初识「高可用」 》、《 分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的 》看完后，相信大家对实现高可用的思路和负载均衡的策略有了一些了解。这篇主要阐述一下在实施的时候主流的一些解决方案。
再翻出第一篇中放出的一张图来回顾一下。
之前也有的小伙伴问到，为什么没有列出DNS？我认为，DNS的本质是解决「domain name --> ip」的问题。虽然DNS除了在公网运用的之外，还会运用于做内网的自定义domain name解析，但是在程序里单靠它来做负载均衡的话，还是太勉强了。
当然，基于DNS“智能解析”功能可以做到IP的动态返回，也算起到了负载均衡的作用。但是，由于其本身是一个工作在L3（网络层）的解决方案，所以无法对“端口”进行工作。而一般我们程序之间的通讯很多都会涉及到端口，因此我们本篇先不讨论DNS~
在清楚了我们应该在哪些环节考虑做负载均衡之后，接下去就是思考如何能够循序渐进的进行。
古时候军队打仗的时候一般都是拿盾的抗在前面，顶住攻击。而负载均衡解决方案从某种角度来说也是一个类似盾一般的防御性设施，因为前提就是要能承载上游过来的流量。因此，越往“前”做负载均衡解决方案，效果肯定会越好，因为受保护的应用范围越广。
如果说，系统之前没有运用过负载均衡，现在开始第一次做，该如何选择呢？小Z根据心目当中的优先级来和大家聊一下。
硬件这块名气最大的还属F5（根据ZOL的数据，其在市场占有率51.44%），大大盖过了其它几家硬件商的风头。此类硬件负载均衡器的特点是“壕”，毕竟是纯商业化的东西，投入的资源和精力自然是众多开源软件负载均衡所无法比拟的，所以功能非常强大。包含访问加速、压缩、安全等等负载均衡之外的许多附加功能。
题外话 ：如果用F5组网的话，有两种结构，串行结构和并行结构，也称为直连模式和旁路模式。前者的优势在对硬件产生压力较小、且天然安全性高，而后者对原网络架构的改动较小、且扩展性较好。大家在实际的使用中结合自身情况来部署。
“壕”物能够同时支持L2~L7的转发，所以上图中的每一个标注点都可以用硬件来做负载均衡。因此，如果在经济允许的情况下，直接上F5能解决很多原本需要花更多时间去解决的问题。所以当“时间”的重要度大于“金钱”的时候，建议优先采用硬件方案。
当“金钱”的重要程度大于“时间”的时候，我们可以通过软件来达到我们要的效果。相应的，也增加了一些运维成本。
一般情况下，只要对数据库不滥用，往往我们从「单应用 + 单库」组合最先需要突破的是应用，变成「多应用 + 单库」。那么针对Web应用的L7负载均衡，比较主流的产品是2个Nginx、HAProxy。在L7做负载均衡，最大的特点就是灵活，请求的URL、Header都是我们可以去掌控的，所以我们可以利用其中的任何信息为负载均衡策略所用。
这一类就是前面图中的「反向代理」。作为「客户端」和「Web应用」、「前端」和「后端」之间的桥梁。实际操作中主要做2步：
1. 在公网的域名解析中，配置解析到「反向代理」。记录类型是「A」，记录值是「反向代理」的IP。
2. 配置真实提供服务的Web应用IP和端口，和负载均衡均衡策略。上图中的配置是Nginx中的示例，负载均衡策略的缺省值是轮询。
当「Web应用」所依赖的TCP协议的「服务」需要横向扩展，或者需要做「数据库」、「分布式缓存」的多主、主从集群时，那么就需要一个支持L4的负载均衡软件。这里最知名的就属LVS了，1998年5月由章文嵩博士建立，2004年底被纳入Lunix内核。也正因为它是内核态的程序，所以相比用Nginx、HAProxy来做L4的负载均衡，在性能、资源的消耗上会更优一些。
实际运用中的操作步骤主要也是2步：
1. 在LVS中添加一个IP虚拟服务（IPVS），并指定它的IP、端口和负载均衡策略。
2. 将IP虚拟服务关联到真实的服务上，并指定模式和权重的信息。（做L4的负载均衡可以使用NAT或者FULLNAT模式）
题外话 ：LVS的模式一共有四种，除了NAT和FULLNAT（NAT的增强版）模式外，它的TUN模式可以在L3做负载均衡，DR模式可以在L2做负载均衡，到这个层面其实就和做硬件同处于一个层次了。并且，随着层次的深入，虽然对功能性上有所弱化，但是如果不考虑端口的话，单从IP层面的负载均衡来说，用DR模式做，则对数据包的加工介入度会降到最低，因此也是通过软件做负载均衡能够达到的性能极致。
另外，LVS中运用的虚拟IP概念，本质上和Nginx中的“server”概念一样，定义了一个统一入口，作用上并没有差别。将Nginx中的upstream关联到server，就如LVS操作步骤第2点中的关联一般。
这些每个具体的解决方案的使用教程网上比较多，就不展开了，大家实际用到的时候自行查阅一下，当然尽量优先看官方的。
做了一个苦差事，把所有同类型的产品都整合了一下优缺点和使用场景。不过，其中有不少是我没用过的，所以仅供大家参考。顺手将一些网上到处充斥的一些过时结论做了更新，如：Nginx不支持session sticky等。
我们可以看到，不同的解决方案有不同的侧重点。因此在单个解决方案已经无法满足的情况下，我们可以组合使用，各尽所长。
负载均衡这个领域还是以高可用和性能为2个最重要因素，下面是小Z推荐的一种组合方式，也是在系统量级达到每小时上亿PV之后最被广泛使用的一种。理论上，利用第一步DNS的域名解析所带的负载均衡效果，只要复制多套LVS主备出来，绑上多个不同的虚IP，可以做到无限横向扩展，以支撑不断增长的流量。
用到的3个软件目前都是开源产品，LVS+Keepalived负责做Nginx的负载均衡，而Nginx负责分发到实际的请求到Http和Tcp协议的应用上。
关于LVS的模式选择，如果在同网段内的话优先使用DR模式进行L2转发，性能最好。否则使用TUN模式进行L3分发。与此同时，在L4、L7的分发上使用Nginx来做，可以发挥其灵活易扩展的特点以及其它的一些额外特性如缓存等，也算是物尽其用。
云时代，service mesh风兴起。以sidecar模式为核心的后起之秀Linkerd、Conduit、NginMesh、Istio等软件除了满足负载均衡之外，还为高可用相关的做了众多的考量，后续有机会小Z和大家一起来梳理一下。很久之前写过一篇调研服务治理框架的文章，里面顺带有提到一下，有兴趣的小伙伴们可以跳过去看看：《 分布式系统中的必备良药 —— 服务治理 》。
有些事，并不需要做到一步到位，做技术也是这样。其实大部分情况下，在以上方案中选择一个，做一层转发就够了。行远自迩，避免给自己添不必要的麻烦。