备考某云ACP认证负载均衡SLB这个知识点在我复习阶段占比非常突出。考纲里明确给了17%的权重差不多是除了几个核心服务之外占分最大的一块之一。一开始我只是把它当作一个普通考点觉得“把流量分发到多台机器”这种概念太常见了能有什么可挖的结果真正刷题和动手配置之后才发现SLB这17%的水一点也不浅——四层和七层的选型、监听协议、健康检查阈值、调度算法、会话保持每一条都能单独出一道场景题。如果你也在准备云厂商相关认证或者日常工作中要接触到负载均衡却一直停留在“会用不会讲”的状态这篇整理应该能帮你把这些零散知识点串起来。文章会从分值分析讲到核心概念再给一个完整的配置过程最后把我在实际排查中踩过的坑一起列出来。1. 先聊清楚SLB这门课为什么能占17%1.1 17%到底是个什么概念ACP认证考试通常分成多个知识模块每个模块按重要性分配题目比重。SLB单独占17%这个数字在整张考卷里的地位相当靠前。如果按一套卷子70道题来估算意味着大约有12道题是围绕负载均衡展开的涵盖概念理解、场景选型、故障排查和参数判断。我备考时做过一个小统计把模拟题里涉及SLB的题目按考查方式分类大概可以分成三类——第一类是“给你一个业务场景让你选负载均衡方案”这类题占比最高第二类是“直接考某个参数配置是否正确”比如健康检查间隔、调度算法名称、会话保持超时时间第三类是“描述一个故障现象让你判断问题出在哪个环节”。其中场景选型题最迷惑人因为四个选项经常把SLB、云解析、内容分发网络混在一起一个不小心就选错。很多人在备考时习惯把精力放在计算、网络、数据库这些“硬核”模块觉得负载均衡就是“点几下控制台的事”结果到了SLB这头轻飘飘地过了一遍。实际上从考题分布就能看出来越是贴近日常运维的产品越容易以场景题的形式反复出现。我在实际考试中遇到的SLB相关题几乎没有一道是直接背概念能拿分的全是带着具体业务背景的。所以这一部分的价值不在“背诵”而在“理解每个配置项背后的动机”。1.2 复习顺序框架比题海更管用SLB本身并不孤立。它和域名解析、对象存储、消息服务、数据库这些产品经常在同一个场景题目里出现考试考的是“串联”能力。我建议不要上来就刷题先花点时间搭一个认知框架。我的复习顺序是先搞清楚“一个请求从用户浏览器到后端服务器之间发生了什么”把SLB在整条链路中的位置牢牢刻在脑子里然后去看四层与七层的区别这是SLB所有考题的地基再去理解监听、后端服务器组、健康检查、虚拟服务器组这些配置项最后才去梳理调度算法。这样复习的好处是当你遇到一个陌生场景时能很快把问题归类到“应该是监听配错了”还是“调度算法选型不对”而不是对着四个选项瞎猜。我还发现一个比较好用的学习方法把SLB想象成公司前台。用户是来访客人后端服务器是各个部门调度算法是“前台按什么规则叫人来接”健康检查是“前台定期确认每个部门还有人值班”。一旦建立起这个类比后面的知识点就不再是零散的条目而是一个完整的流程。2. 深度拆解SLB核心知识体系2.1 一个请求进来后发生了什么先走一遍完整链路。用户输入域名DNS解析拿到入口IP——这个IP指向的通常是SLB实例的虚拟IP不是某一台具体服务器。SLB收到请求后会查看自己配置的监听规则这是四层监听还是七层监听监听的是哪个端口然后根据调度算法选出一台后端服务器再通过内部网络把请求转发过去。后端服务器处理完响应原路返回用户看到结果。这里面有几个容易混淆的点。第一个是“四层”和“七层”不是版本高低而是工作在不同网络层级。四层监听基于IP和端口转发负载均衡设备只看到TCP/UDP报文不关心报文里的内容是HTTP还是HTTPS七层监听则是在应用层工作能看到URL、浏览器类型、Cookie这些信息。第二个是“监听”和“后端服务器组”是分开配置的监听负责“要不要接这个端口进来的请求”后端服务器组负责“接到之后转给谁”。这么说可能有点抽象我举个具体例子。你的应用有这样一个需求同一个域名下/api/路径的请求需要转发到后端一组专门处理接口的服务器/web/路径的请求转发到另一组处理静态页面的服务器。这种“按路径分发”的需求只有七层监听能做因为只有七层才能读到URL。如果只是简单的TCP端口转发比如把所有访问80端口的流量转发给后端那四层监听就够了性能还更高。2.2 四层与七层怎么选才不出错这个知识点在考试里几乎必考而且在实操中也是很多人选错的第一步。我见过不少刚接触负载均衡的同学一上来就选七层HTTP监听觉得“功能多肯定更好”。但在某些场景下四层监听的效率和稳定性反而更优。四层负载均衡的优点在于转发速度快、消耗资源少因为它不需要解析应用层内容只做报文级别的转发。它适合的场景包括TCP长连接、游戏服务端、数据库中间件、不基于HTTP协议的私有协议。缺点是灵活性低没法根据URL做精细化控制也不支持基于HTTP Header的转发策略。七层负载均衡的优点在于“懂业务”。它能读取HTTP头部、URL、Cookie甚至请求体内容因此可以做更细的流量治理比如根据用户所属地域把请求分发到特定服务器或者针对某个API路径做独立限流。缺点是性能开销比四层大而且本身依赖HTTP解析如果后端服务不是HTTP协议用七层监听就没有意义。实操里我的选型建议很简单后端是HTTP/HTTPS服务又需要做路径、域名、报文头级别的路由或者需要会话保持、HTTPS证书卸载就选七层后端是不认识的协议、对转发性能有极致要求、或者只是做TCP端口透传就选四层。不要为了“看起来很高级”去选七层也不要因为“七层慢”就一律不用四层看完业务需求再决定。2.3 那些藏在题干里的核心配置项SLB的核心配置项不算多但每一个都能引申出不少考题。这里按配置顺序逐个说清楚。监听负责定义“SLB愿意接收什么流量”。需要配置协议TCP/UDP/HTTP/HTTPS、监听端口比如80或443、带宽上限如果限定了峰值、以及一些高级选项比如调度算法、会话保持开关、获取客户端真实IP开关。后端服务器组负责定义“流量转给谁”。一个SLB实例下面可以创建多个后端服务器组每组包含多个云服务器实例每个实例可以单独设置权重。这里有个很容易被忽略的点云服务器实例必须和SLB实例在同一个地域否则添加后端服务器时根本选不到。虚拟服务器组这个名词看着复杂实际理解起来不难。当你有两种不同类型的后端服务器、需要应用不同的转发规则时可以通过虚拟服务器组把服务器按业务划分开。比如监听A转发到虚拟服务器组X监听B转发到虚拟服务器组Y每组内部再配置不同的权重和健康检查策略。健康检查负责判断哪台后端服务器“还活着”。SLB会按你设置的间隔定期向后端服务器发起探测请求如果连续几次都失败就会把该服务器从转发池中摘除如果之后恢复又会自动加回来。这个机制决定了整个负载均衡集群对后端故障的容错能力。2.4 调度算法不只是“随机选一台”调度算法是SLB的高频考点也是实际配置中最容易拍脑袋乱选的地方。常见的有三种轮询、加权最小连接数、一致性哈希在某些语境下也叫IP Hash具体以控制台为准。轮询很好理解就是按顺序把请求轮流分给每台后端服务器不关心每台服务器当前负载怎么样。如果后端服务器配置都差不多轮询简单又公平。但如果几台服务器性能差异明显纯轮询会把请求均匀分给性能较弱的机器容易拖垮整体响应速度。这时就需要加权轮询——给高性能机器更高的权重让它在单位时间内接更多请求。加权最小连接数更聪明一点。它不是机械地按顺序转而是每次看当前后端服务器“正在处理中的连接数”挑最轻松的那台转过去。这个算法适合长连接或请求处理时间差异较大的场景。比如某些请求要执行几秒的复杂计算某些请求几十毫秒就返回了如果只按轮询可能一分钟内某台机器积压了大批慢请求其他机器却在空闲。最小连接数能尽量让每台机器的“忙碌程度”相近。一致性哈希通常用于需要会话保持的场景它根据客户端IP或请求里的某个字段计算哈希值固定映射到某一台后端服务器。好处是同一个客户端长期被转发到同一台机器适合需要本地缓存的场景坏处是如果某台服务器宕机哈希映射会发生变化可能导致一部分会话失效。对这个算法不要只看字面意思要理解“一致性”是为了降低扩容缩容时的重新映射范围。3. 动手实操一个完整SLB搭建过程3.1 前置准备别急着点“创建”我在实际带新同学配置SLB的时候最常看到的问题是“没想清楚就创建实例然后发现地域选错没法用”。前置准备比控制台操作更值得花时间。首先是地域选择。SLB实例必须和规划加入后端服务器组的云服务器在同一个地域否则添加后端服务器时会发现列表里是空的。如果你想让SLB具备跨可用区容灾能力可以在同地域的多个可用区都准备后端服务器SLB具备跨可用区转发能力但后端服务器本身与SLB同地域这个前提不能变。其次是安全组配置。后端服务器的安全组需要放行来自SLB的健康检查、转发流量的来源地址段否则健康检查永远失败监听也一直处于异常状态。很多同学配置完SLB以后发现后端服务器日志里一条流量都没有排查到最后往往就是安全组没放通。所以在创建SLB之前先去后端服务器的安全组里确认入方向规则有没有包含对应的端口和来源网段。第三是规划好监听端口和后端端口。HTTP服务一般用80HTTPS用443这没争议。有争议的是“前端80转到后端8080”这类端口映射场景配置时前端监听端口填80后端服务器组的端口填8080不要填反。我见过太多人在这一步填错了导致请求能到SLB但永远转发不到后端进程。3.2 创建SLB实例时的几个关键设置到了控制台创建实例这一步参数看起来很多但真正需要拿主意的主要是四个计费方式、网络类型、规格、IP类型。计费方式通常有按量计费和包年包月不同平台叫法可能不同。测试环境选按量计费就好用完就释放不会浪费钱。生产环境如果流量稳定包年包月划算一些。网络类型一般是公网、私网、双栈之类的选项需要想清楚这个入口是要对外提供服务还是只给内部系统用。对外提供Web服务就选公网内部微服务之间的流量尽量选私网既安全又省公网带宽费用。规格这块如果平台支持性能容量型或按规格选择刚入门时先不要追求最大规格可以选一个能满足当前业务峰值的档位后续根据监控数据再调整。IP类型基本就是IPv4和IPv6除非你明确知道业务需要IPv6访问否则IPv4即可。我在配置时习惯给实例加上标签比如“生产环境-前端入口”或“测试-订单服务”。这个小习惯在实例多了之后非常有用考试里虽然不考但实际运维时能省很多找实例的时间。3.3 配置监听把入口规则写清楚创建完成SLB实例后第一步是配置监听。我以一个最常见的HTTP负载均衡场景为例前端监听80端口后端服务器跑在8080端口调度算法用加权轮询。配置监听时要填“监听端口”也就是最终用户访问的端口填80“后端端口”或者叫“服务器端口”填8080。接着选择监听协议HTTP或HTTPS。如果选HTTPS还需要提前准备好了证书加载到SLB上由SLB完成HTTPS证书卸载后端服务器不用再处理SSL加解密这样可以明显降低后端CPU压力。再往下是高级配置。调度算法我习惯一开始选加权轮询因为后端机器配置通常不完全一致。会话保持开关建议先打开超时时间根据业务设置一般半小时左右比较合理。获取真实IP的开关要打开否则后端服务器看到的客户端IP全是SLB的转发地址日志分析和安全策略会直接受影响根本查不出真实访问来源。另外健康检查配置在监听页面也能一并设置。检查方式选HTTP检查端口填后端实际提供服务的端口8080检查路径设置为一个较轻量的静态接口比如/healthcheck。这个路径不要是那种需要查询大量数据库动态拼接的页面否则健康检查本身就会给后端带来额外压力还可能因为数据库抖动导致误判。3.4 添加后端服务器与权重分配监听配好之后进入后端服务器组把云服务器实例添加进来。这里会出现一个“权重”参数很多第一次配置的人不知道填多少合适我提供一个简单参考权重在平台规则里通常代表“接收流量的比例”。如果两台机器配置完全一样权重都设100即可。如果一台是4核8G另一台是2核4G保守起见可以给4核机器设权重2002核机器设权重100。换算下来4核机器接收约2/3的流量2核机器接收约1/3。这里不要追求精确到个位数的平衡因为权重本质上只是一个相对的“流量倾斜比例”只要别设成极端值比如100和1系统都能正常运行。添加后端服务器时要注意后端端口在这一步也要确认一遍。有些平台在监听级别设置后端端口有些则在服务器组级别设置后端端口如果两边都能设置需要保持一致。我踩过一次坑监听里写的后端端口是8080服务器组里默认填成80结果健康检查从8080探测完全无响应整个后端组全被摘除。3.5 健康检查参数调优不是默认就行健康检查参数是运维里比较有意思的部分。常见的参数有检查间隔、超时时间、健康阈值、不健康阈值。默认值当然能用但在一些业务场景下需要调整。检查间隔不要太短。有的同学为了让故障发现得更快把间隔设成2秒结果后端服务一到高峰期响应变慢CPU稍微一忙健康检查请求就超时瞬间把一批服务器标记为不健康。请求量被摘除机器一挡剩余机器压力更高形成恶性循环。我的一般做法是间隔设为5到10秒健康阈值设为3次成功才标记为正常不健康阈值设为3次失败才标记为异常给后端留出足够的“解释时间”。另外健康检查用的是SLB到后端服务器的探测和用户真实访问路径还是有点差别。比如健康检查探活URL返回200就认为健康但用户真实接口可能因为数据库连接池满了而返回500。这就说明健康检查只能作为一种“基础存活判断”不能完全替代业务层面的监控报警。实操中一定要在业务监控系统里单独对关键接口做可用性检测不能单纯依赖SLB的健康检查。3.6 配置完成后如何验证效果配置完成后先别急着一台台手动刷新页面用命令行验证更高效。假设SLB公网入口IP是1.2.3.4后端有两台服务器我想确认轮询或权重转发是否生效可以在本机执行一个循环请求for i in {1..100}; do curl -s http://1.2.3.4/ done然后再分别登录两台后端服务器看各自访问日志里记录的请求数量。如果权重设置是200:100那么两台服务器的日志条数应该接近2:1。如果只看到某一台有日志另一台没有大概率是权重配置错误或者另一台服务器被健康检查摘除了。还要测一下故障转移。手动关掉其中一台后端服务器的应用进程然后继续循环请求观察SLB是否自动把流量全部导向另一台正常服务器。这个过程里用户请求不应当出现连接中断或长时间超时关掉的那台机器在恢复进程后过一会儿又自动回到转发池中这才算配置合格。4. 常见问题与排查思路实录4.1 健康检查一直失败后端服务明明活着这个问题出现的频率极高。常见原因有三个安全组没放通健康检查来源、检查端口填错、检查路径返回的不是2xx状态码。排查时按顺序来先看后端服务器安全组是否放通了SLB的探测来源和端口再确认监听级别的后端端口和服务器组级别的后端端口是否一致最后在服务器本机直接执行一遍健康检查URL比如curl -i http://localhost:8080/healthcheck看看实际返回状态码。如果后端服务依赖了用户登录态或某些请求头健康检查请求不带这些内容自然会被应用层挡掉。这种情况最简单的处理办法单独提供一个免鉴权的健康检查路径比如/healthz只返回固定字符串用于SLB探活不参与业务逻辑。4.2 会话保持失效用户登录状态反复丢失会话保持是一个封装得很好的功能看起来只是“开个开关”但踩坑点不少。最常见的是前后端端口不一致导致Cookie写入的域和端口对不上其次是后端服务器本身做了重启或扩容原本持有会话的服务器被移出转发池新请求被转到其他机器而机器之间没有做会话同步。我的排查思路是先确认会话保持开关已经在监听级别打开再检查后端应用的Session存储方案是否已经统一迁移到Redis这类外部存储最后再去看Cookie的Domain和Path设置。如果后端是Java应用多实例部署时Session默认放在各自内存里不配置外部缓存的话会话保持再怎么做都是空的。4.3 四层监听和七层监听混用导致流量异常有一种情况最容易让人迷惑一个SLB实例上同时配置了TCP监听的多个端口和HTTP监听后端服务器组又混用了不匹配的端口。比如TCP 3306端口的四层监听转发到后端的数据库服务而HTTP 80监听也转发到同一批服务器组一旦后端服务器端口配置不一致四条规则互相干扰流量直接乱套。我的建议是尽量收敛监听规则不同用途的负载均衡单独创建不同的SLB实例不要让一个实例背上三四个互不相干的监听。这样不但排查问题容易权限管理和监控告警也清晰。如果你确实想在一个实例上复用资源至少保证每个监听对应独立的虚拟服务器组避免一个组的调整影响到另一个组。4.4 需要多大带宽、几台机器一道经典计算题ACP考试很喜欢给你一个业务量让你反推后端机器数量或带宽大小。比如一个系统预计平均QPS是200峰值是平均值的3倍即600QPS单台后端机器能扛200QPS那至少需要3台后端机器来应对峰值。同时要考虑故障冗余至少再留一台推荐4台。带宽计算类似假设平均请求响应体是50KB峰值QPS是600那么出口带宽峰值约为600 × 50KB × 8 240000Kbps换算约等于234Mbps。所以带宽按“毛估”至少买250Mbps如果还要留余量就上300Mbps。实际生产里响应体大小会波动日志、图片请求差异很大不可能一个公式算到底但考试和面试时这种估算思路比“随便填一个数”要可靠得多。5. 最后再分享一点我备考和实操的体会复习SLB这个知识点我最大的感受是“题海战术真的不如动手一次”。我备考初期刷了几百道SLB相关的模拟题正确率一直在七成左右徘徊很多题看了解析当时明白过两天又忘。后来我干脆申请了两台最低配的云服务器一台跑Nginx模拟后端应用一台跑一个简单页面然后从零开始配置SLB实例、监听、健康检查、权重、会话保持把所有流程亲手走了一遍。做完这个实验之后再回去刷题正确率一下子到了九成以上因为很多场景背后的原理已经从“记住答案”变成了“我设过这个参数我知道它为什么生效也知道它出错长什么样”。如果你也在备考或者刚接触负载均衡建议你也试试这个方法。不一定非要上云本地虚拟机里装几个Nginx实例再用任何一套支持负载均衡的软件比如Nginx反代或者云上的免费额度把“流量入口到后端转发”的链路打通一遍收获会超过背十份文档。最后还有一个小技巧给后端服务设计健康检查路径时一定要设计一个不带任何业务逻辑、只返回当前进程存活状态的固定页面比如直接返回ok。这个页面不需要查询数据库不需要读文件也不需要校验用户身份它是专门给负载均衡探活用的。做好这一步基本上能规避掉三分之一的健康检查误报问题。