摘要：前面两篇分布式系统关注点初识高可用分布式系统关注点仅需这一篇，吃透负载均衡妥妥的看完后，相信大家对实现高可用的思路和负载均衡的策略有了一些了解。配置真实提供服务的应用和端口，和负载均衡均衡策略。
本文长度为3032字，预计读完需1.1MB流量，建议阅读8分钟。
前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的》看完后，相信大家对实现高可用的思路和负载均衡的策略有了一些了解。这篇主要阐述一下在实施的时候主流的一些解决方案。
一、为什么没有DNS？再翻出第一篇中放出的一张图来回顾一下。
之前也有的小伙伴问到，为什么没有列出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步：
在公网的域名解析中，配置解析到「反向代理」。记录类型是「A」，记录值是「反向代理」的IP。
配置真实提供服务的Web应用IP和端口，和负载均衡均衡策略。上图中的配置是Nginx中的示例，负载均衡策略的缺省值是轮询。
03 软件负载均衡（L4）
当「Web应用」所依赖的TCP协议的「服务」需要横向扩展，或者需要做「数据库」、「分布式缓存」的多主、主从集群时，那么就需要一个支持L4的负载均衡软件。这里最知名的就属LVS了，1998年5月由章文嵩博士建立，2004年底被纳入Lunix内核。也正因为它是内核态的程序，所以相比用Nginx、HAProxy来做L4的负载均衡，在性能、资源的消耗上会更优一些。
实际运用中的操作步骤主要也是2步：
在LVS中添加一个IP虚拟服务（IPVS），并指定它的IP、端口和负载均衡策略。
将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和大家一起来梳理一下。很久之前写过一篇调研服务治理框架的文章，里面顺带有提到一下，有兴趣的小伙伴们可以跳过去看看：《分布式系统中的必备良药 —— 服务治理》。
有些事，并不需要做到一步到位，做技术也是这样。其实大部分情况下，在以上方案中选择一个，做一层转发就够了。行远自迩，避免给自己添不必要的麻烦。
相关文章：
分布式系统关注点——初识「高可用」
分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的
分布式系统中的必备良药 —— 服务治理
▶ 关于作者：张帆（Zachary）。坚持用心打磨每一篇高质量原创。本文首发于公众号：「跨界架构师」（ID：Zachary_ZF）。
微信公众号（首发）：跨界架构师。<-- 点击后阅读热门文章
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。
扫码加入小圈子 ↓
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/34905.html
摘要：因为我们认为正常情况下用户的不会在短时间内发生变化，所以当我们选择使用策略进行负载均衡时，意味着期望同一个用户能够一直访问到同一台服务器上，就像下图这样。但是，我们还需要明白一个事实严格来说保持本质上是破坏了做负载均衡的初衷。 本文长度为3056字，预计读完需1.1MB流量，建议阅读8分钟。 这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了，后续也会继续讲「高可用」相关的其...
摘要：因为我们认为正常情况下用户的不会在短时间内发生变化，所以当我们选择使用策略进行负载均衡时，意味着期望同一个用户能够一直访问到同一台服务器上，就像下图这样。但是，我们还需要明白一个事实严格来说保持本质上是破坏了做负载均衡的初衷。 本文长度为3056字，预计读完需1.1MB流量，建议阅读8分钟。 这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了，后续也会继续讲「高可用」相关的其...
摘要：可简单地认为它是的扩展，负载均衡自然成为不可或缺的特性。是基于开发的服务代理组件，在使用场景中，它与和整合，打造具备服务动态更新和负载均衡能力的服务网关。类似的特性在项目也有体现，它是另一种高性能代理的方案，提供服务发现健康和负载均衡。 摘要： Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注，尤其是 CNCF（Cloud Native Computing Fo...
摘要：在一个成熟的系统中，能够运用到缓存的地方其实并不是一处。那么在以终端用户为起点，系统所用的数据库为终点的这条道路上可以作为缓存设立点的位置大致有以下这些。缓存也有一系列的副作用需要考虑。 如果这是第二次看到我的文章，欢迎文末扫码订阅我个人的公众号（跨界架构师）哟~ 本文长度为3578字，建议阅读10分钟。坚持原创，每一篇都是用心之作～ 此前的「伸缩性」章节结束了，此文是「高性能」章...
摘要：前言不少在传统行业摸爬滚打的程序员越来越焦虑了，有些甚至睡不着觉。下面就几个方面和大家谈谈传统行业的技术人员如何转型互联网。传统行业的程序员的晋升周期可能会非常长，年，甚至年时间才能做到高位。 前言 不少在传统行业摸爬滚打的程序员越来越焦虑了，有些甚至睡不着觉。为什么？传统行业的程序员们每天进行的都是业务代码的编写，接触不到更新更好的技术；公司的效益并不好，如未达到目标收益，只能进行瘦...
阅读 515·2021-11-23 09:51
阅读 722·2021-11-23 09:51
阅读 1193·2021-11-18 10:02
阅读 2351·2021-11-15 18:01
阅读 3546·2021-10-11 11:07
阅读 1380·2021-09-24 09:47
阅读 2183·2021-09-22 15:30
阅读 922·2021-09-22 14:59
