如果这是第二次看到我的文章，请订阅Z哥的微信官方账号(跨界建筑师)。每周五11: 45准时送达。 当然我会时不时加一顿~本文长度3032字，估计需要1.1MB流量才能看完。建议读8分钟。 看完前两篇文章《分布式系统关注点——了解“高可用性”和《分布式系统关注点——只需要这篇文章，彻底正确理解“负载均衡”，相信你对实现高可用性的思路和负载均衡的策略有了一点了解。 本文主要阐述实施过程中的几种主流处理方案。 1.为什么没有DNS？翻出第一篇放出的一张图来回顾一下。 之前有朋友问为什么DNS不上市？我认为DNS的本质是处理“域名->: Ip”问题。 虽然DNS不仅用于公网，也用于内网设置域名解析，但是在程序中依靠它进行负载均衡还是太勉强了。 当然，基于DNS的“智能解析”功能可以实现IP的动态回归，也起到了负载均衡的作用。 但因为是在L3(网络层)工作的处理方案，所以不能在“端口”上工作。 一般我们程序之间的通信很多都会涉及到端口，所以先不讨论DNS~了。二、如何实施？知道了应该考虑负载均衡的环节之后，下一步就是考虑如何一步一步来。 古时候军队打仗，一般都是拿盾牌抵挡进攻。 负载均衡方案从某种角度来说也是一种盾状的防御装置，因为前提是能够承载上游流量。 所以采用的负载均衡方案越“靠前”，效果越好，因为保护的应用范围会更广。 比如说，如果系统以前没有用过负载均衡，现在第一次开始做，怎么选择？z会按照心里的优先级跟你聊。 01硬件负载均衡最著名的硬件是F5(根据ZOL的数据，其市场份额为51.44%)，大大盖过了其他几家硬件厂商的风头。 这种硬件负载均衡器的特点是“护城河”。毕竟是纯商业的东西。投入的资源和精力自然是很多开源软件负载均衡器无法比拟的，所以非常强大。 除了负载平衡之外，它还包含许多附加功能，如访问加速、压缩、安全等。 题外话:如果用F5组网，有两种结构，串行结构和并行结构，也叫直连模式和旁路模式。 前者的优点是硬件压力小，天然安全性高，后者对原有网络架构改动小，可扩展性更好。 大家在实际使用中会根据自己的情况进行调配。 “Trench”可以同时支持L2~L7的转发，所以上图中每个标记点都可以通过硬件进行负载均衡。 所以在经济允许的情况下，直接去找F5可以处理很多原本要花更多时间处理的问题。 所以当“时间”的重要性大于“金钱”的重要性时，建议优先考虑硬件方案。 02软件负载均衡(L7)当“钱”比“时间”更重要的时候，我们可以通过软件达到想要的效果。 相应的，也增加了少量的运维成本。 总的来说，只要数据库不被滥用，我们从“单一应用+单一数据库”的组合中首先需要突破的就是应用，它就变成了“多应用+单一数据库” 那么对于Web应用的L7负载均衡，主流产品是Nginx和HAProxy两个。 L7中负载均衡最大的特点就是灵活性。我们可以控制请求的URL和头部，因此我们可以将其中的任何信息用于负载平衡策略。 这一类就是上图中的“反向代理”。 它是“客户端”和“Web应用程序”、“前台”和“后台”之间的桥梁 在实践中，主要有两个步骤:1 .在公网域名解析中，配置被解析为“反向代理” 记录类型为“A”，记录值为“反向代理”的IP 2.配置真正提供服务的Web应用程序的IP和端口，以及负载平衡策略。 上图中的配置是Nginx中的一个例子，负载均衡策略的默认值是轮询。 03软件负载均衡(L4)当Web应用所依赖的TCP协议的服务需要横向扩展，或者用户需要做数据库和分布式缓存的多主从集群时，那么就需要一个支持L4的负载均衡软件。 这里最著名的就是了，由张博士于1998年5月创立，2004年底归入Lunix内核。 因为是内核程序，所以在性能和资源消耗上会比使用Nginx和HAProxy进行L4负载均衡要好。 实际操作步骤主要是两步:1。在LVS添加IP虚拟服务(IPVS ),并指定其IP、端口和负载平衡策略。 2.将IP虚拟服务与真实服务相关联，并指定模式和权重信息。 (L4可以使用NAT或FULLNAT模式进行负载均衡)题外话:LVS有四种模式。除了NAT和Full NAT(增强版NAT)之外，其TUN模式可用于L3的负载均衡，DR模式可用于L2的负载均衡。这个水平其实和硬件是一个层次的。 而且随着层次的加深，虽然功能性减弱，但是如果不考虑端口，如果只使用IP级的负载均衡，那么使用DR模式会将数据包处理的干预程度降到最低，所以使用软件进行负载均衡也是可以达到的极致性能。 另外，LVS使用的虚拟IP的概念和Nginx中“服务器”的概念本质上是一样的，定义了统一的入口，在功能上没有区别。 将Nginx中的上游与服务器关联起来，就像LVS操作步骤第2点中的关联一样。 对于每一种具体的治疗方案的使用，网上有很多教程，就不进行了。当你实际使用它们时，你可以自己检查它们。当然，尽量以官方的为主。 三、优缺点做了一个苦差事，整合了所有同类型产品的优缺点和使用场景。 不过很多都不是我用的，仅供大家参考。 升级一小部分过时的结论，比如:Nginx不支持会话粘性等。 我们可以看到不同的治疗方案有不同的侧重点。 所以在单一治疗方案已经不能满足要求的情况下，可以联合使用，发挥所长。 在负载平衡领域，高可用性和性能是两个最重要的因素。下面是小Z推荐的一种组合方式，也是系统达到每小时上亿PV后应用最广泛的一种。 理论上，利用第一步DNS域名解析带来的负载均衡效果，只需要复制多套LVS主备，绑定多个不同的虚拟IP，就可以实现无限制的横向扩展，以支持不断增加的流量。 目前使用的三款软件都是开源产品，LVS+Keepalived负责Nginx的负载均衡，Nginx负责将实际请求分发到Http和Tcp协议的应用。 关于LVS的模式选择，如果在同一个网段，L2转发首选DR模式，性能最好。 否则，使用TUN模式执行L3分配。 同时，在L4和L7的分发中使用Nginx可以充分发挥其灵活易扩展的特性，以及其他一些附加特性如缓存等。，也算是物尽其用了。 云时代，服务网格风兴起。 除了负载均衡之外，以sidecar模式为核心的后起之秀Linkerd、Conduit、NginMesh、Istio等软件都为高可用性做了很多考虑。后续小Z会有机会和你一起梳理。 很久以前，我写过一篇关于服务治理框架的文章，顺带提到过。感兴趣的朋友可以跳过去看看:《分布式系统中的必备良药——服务治理》 四。结论有些事情不需要一步到位，做技术也是一样。 其实大多数情况下，选择上面的一个方案，做一层转发就够了。 远离你的旅行，避免给自己带来不必要的麻烦。 相关文章:分布式系统关注点——第一次了解“高可用性”分布式系统关注点——只需要这篇文章就能彻底了解适当平衡的分布式系统中的必要药物——服务治理作者:扎卡里(个人微信号:扎卡里-ZF)微信微信官方账号(首发):跨界架构师。 & lt-点击查看近期热门文章。如果你是初级程序员，想升职却不知道如何下手。 或者某个做了多年程序员的人，陷入了几个瓶颈，想开阔眼界。 欢迎我的微信官方账号“跨界建筑师”，回复“科技”，送你一张我长期收集整理的思维导图。 如果你是做生意的，面对瞬息万变的市场，你是无助的。 或者其他人想了解主流商业策略来充实自己的“仓库” 欢迎我的微信官方账号“跨界建筑师”，回复“管理”，送你一张我长期收集整理的思维导图。 定期发布原创内容:架构设计，分布式系统，产品，运营和一点点深入思考。