分布式系统关注点——如何去实施「负载均衡」？

本文长度为3032字，预计读完需1.1MB流量，建议阅读8分钟。

前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的》看完后，相信你们对实现高可用的思路和负载均衡的策略有了一些了解。这篇主要阐述一下在实施的时候主流的一些解决方案。

1、为何没有DNS？

再翻出第一篇中放出的一张图来回顾一下。

以前也有的小伙伴问到，为何没有列出DNS？我认为，DNS的本质是解决「domain name --> ip」的问题。虽然DNS除了在公网运用的以外，还会运用于作内网的自定义domain name解析，可是在程序里单靠它来作负载均衡的话，仍是太勉强了。

固然，基于DNS“智能解析”功能能够作到IP的动态返回，也算起到了负载均衡的做用。可是，因为其自己是一个工做在L3（网络层）的解决方案，因此没法对“端口”进行工做。而通常咱们程序之间的通信不少都会涉及到端口，所以咱们本篇先不讨论DNS~

2、如何实施？

在清楚了咱们应该在哪些环节考虑作负载均衡以后，接下去就是思考如何可以按部就班的进行。

古时候军队打仗的时候通常都是拿盾的抗在前面，顶住攻击。而负载均衡解决方案从某种角度来讲也是一个相似盾通常的防护性设施，由于前提就是要能承载上游过来的流量。所以，越往“前”作负载均衡解决方案，效果确定会越好，由于受保护的应用范围越广。


若是说，系统以前没有运用过负载均衡，如今开始第一次作，该如何选择呢？小Z根据心目当中的优先级来和你们聊一下。

01  硬件负载均衡

硬件这块名气最大的还属F5（根据ZOL的数据，其在市场占有率51.44%），大大盖过了其它几家硬件商的风头。此类硬件负载均衡器的特色是“壕”，毕竟是纯商业化的东西，投入的资源和精力天然是众多开源软件负载均衡所没法比拟的，因此功能很是强大。包含访问加速、压缩、安全等等负载均衡以外的许多附加功能。

题外话：若是用F5组网的话，有两种结构，串行结构和并行结构，也称为直连模式和旁路模式。前者的优点在对硬件产生压力较小、且自然安全性高，然后者对原网络架构的改动较小、且扩展性较好。你们在实际的使用中结合自身状况来部署。

“壕”物可以同时支持L2~L7的转发，因此上图中的每个标注点均可以用硬件来作负载均衡。所以，若是在经济容许的状况下，直接上F5能解决不少本来须要花更多时间去解决的问题。因此当“时间”的重要度大于“金钱”的时候，建议优先采用硬件方案。

02  软件负载均衡（L7）

当“金钱”的重要程度大于“时间”的时候，咱们能够经过软件来达到咱们要的效果。相应的，也增长了一些运维成本。


通常状况下，只要对数据库不滥用，每每咱们从「单应用 + 单库」组合最早须要突破的是应用，变成「多应用 + 单库」。那么针对Web应用的L7负载均衡，比较主流的产品是2个Nginx、HAProxy。在L7作负载均衡，最大的特色就是灵活，请求的URL、Header都是咱们能够去掌控的，因此咱们能够利用其中的任何信息为负载均衡策略所用。


这一类就是前面图中的「反向代理」。做为「客户端」和「Web应用」、「前端」和「后端」之间的桥梁。实际操做中主要作2步：

1. 在公网的域名解析中，配置解析到「反向代理」。记录类型是「A」，记录值是「反向代理」的IP。
2. 配置真实提供服务的Web应用IP和端口，和负载均衡均衡策略。上图中的配置是Nginx中的示例，负载均衡策略的缺省值是轮询。

03  软件负载均衡（L4）

当「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点中的关联通常。

这些每一个具体的解决方案的使用教程网上比较多，就不展开了，你们实际用到的时候自行查阅一下，固然尽可能优先看官方的。

3、优缺点

作了一个苦差事，把全部同类型的产品都整合了一下优缺点和使用场景。不过，其中有很多是我没用过的，因此仅供你们参考。顺手将一些网上处处充斥的一些过期结论作了更新，如：Nginx不支持session sticky等。

咱们能够看到，不一样的解决方案有不一样的侧重点。所以在单个解决方案已经没法知足的状况下，咱们能够组合使用，各尽所长。


负载均衡这个领域仍是以高可用和性能为2个最重要因素，下面是小Z推荐的一种组合方式，也是在系统量级达到每小时上亿PV以后最被普遍使用的一种。理论上，利用第一步DNS的域名解析所带的负载均衡效果，只要复制多套LVS主备出来，绑上多个不一样的虚IP，能够作到无限横向扩展，以支撑不断增加的流量。

用到的3个软件目前都是开源产品，LVS+Keepalived负责作Nginx的负载均衡，而Nginx负责分发到实际的请求到Http和Tcp协议的应用上。

关于LVS的模式选择，若是在同网段内的话优先使用DR模式进行L2转发，性能最好。不然使用TUN模式进行L3分发。与此同时，在L四、L7的分发上使用Nginx来作，能够发挥其灵活易扩展的特色以及其它的一些额外特性如缓存等，也算是物尽其用。


云时代，service mesh风兴起。以sidecar模式为核心的后起之秀Linkerd、Conduit、NginMesh、Istio等软件除了知足负载均衡以外，还为高可用相关的作了众多的考量，后续有机会小Z和你们一块儿来梳理一下。好久以前写过一篇调研服务治理框架的文章，里面顺带有提到一下，有兴趣的小伙伴们能够跳过去看看：《分布式系统中的必备良药 —— 服务治理》。

4、结语

有些事，并不须要作到一步到位，作技术也是这样。其实大部分状况下，在以上方案中选择一个，作一层转发就够了。行远自迩，避免给本身添没必要要的麻烦。

---

相关文章：
分布式系统关注点——初识「高可用」
分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的
分布式系统中的必备良药 —— 服务治理

▶ 关于做者：张帆（Zachary）。坚持用心打磨每一篇高质量原创。本文首发于公众号：「 跨界架构师」（ID：Zachary_ZF）。

微信公众号（首发）：跨界架构师。<-- 点击后阅读热门文章

按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。

扫码加入小圈子 ↓