阿里云ACP认证SLB备考指南：四层七层转发与高可用架构核心考点

1. 17%的占比意味着什么：先把SLB的备考坐标系立起来

我是被一张考纲图吓醒的。不是因为它难，而是因为我发现自己严重低估了它：阿里云ACP认证的考纲里，负载均衡SLB的考题占比是17%。我一开始满脑子都是ECS和对象存储，差点把SLB当“附加题”处理。后来做完几套题才回过味来——17%意味着它在考试里的分量几乎和核心存算产品平起平坐，而且SLB的考点高度集中，比分散在各种实例规格、存储类型里的边角料知识好拿分得多。

这篇笔记不是官方文档的复读，是我把这部分考纲拆开揉碎、再配合刷题复盘整理出来的知识框架和避坑点。给正在备考ACP、尤其容易被比例图带偏节奏的同学做一个参照。看完你至少能搞清楚三件事：SLB考什么、为什么这些考点容易被绕进去、以及考前最后两周怎么抓重点。

1.1 一张考纲图背后的分数账

先算一笔朴素的账。我报考的那一版ACP考试题型是单选、多选和判断混合，满分100分、80分及格（不同时期题型和及格线可能微调，以你报名时拿到的官方说明为准）。这意味着整场考试你最多只能丢20分。负载均衡SLB占17%，如果按大体比例折算，就是17分上下的题目量。

17分是什么概念？如果SLB这块你丢了一半，剩下8.5分需要从其他科目里去补；如果SLB基本全对，你就给自己争取到了接近五分之一的“容错空间”。所以我说它是分数基本盘：不是可以战略性放弃的模块，而是应该优先保证正确率的模块。

更关键的是，SLB的知识点密度很低。ECS要背实例规格、镜像类型、快照区别，存储要分清几种云盘性能层级，SLB的核心骨架就是“实例—监听—后端服务器组”三条线，外加健康检查、会话保持、转发策略、证书、访问控制这几个功能点。只要把每条线捋顺，概念题基本不会丢分。

1.2 SLB在ACP知识地图中的位置和出题规律

从整个考试的知识地图看，SLB处在“ECS之后、高可用架构中间”的位置。它既是独立考查对象，又是和ECS、弹性伸缩、云解析DNS、Web应用防火墙联动出场景题的材料。这意味着你不能只背孤立概念，还得知道SLB在一条完整访问链路里站在哪。

我刷题时的体感是，SLB相关题目主要分成四类：

• 概念辨析题：问四层监听和七层监听的区别、会话保持的类型、健康检查的判定逻辑，这类题占比最高。
• 限制边界题：比如“SLB是否支持跨地域负载均衡”“后端ECS是否必须有公网IP”，这类题靠的是对产品边界有清晰记忆。
• 配置流程题：给一个场景，让你选正确的配置顺序或参数组合，比如创建HTTPS监听时先上传证书还是先配置后端。
• 架构联动题：电商大促、突发流量、容灾场景，问应该选哪些产品组合，重点考多可用区、弹性伸缩和DDoS防护的配合。

把这四类题在脑子里归档之后，你会发现SLB的复习路径清晰了很多：先懂原理，再记边界，最后串场景。下面按这个顺序展开。

2. SLB的底层逻辑：四层转发、七层转发和基础概念

很多同学一上来就背“加权轮询”“最小连接数”，结果题目稍微换个问法就懵。我自己的教训是：先别急着记名词，把SLB到底是一台什么样的设备搞明白。

2.1 一台SLB的组成：实例、监听、后端服务器组

SLB全称Server Load Balancer，中文叫服务器负载均衡，是阿里云提供的流量分发服务。一台SLB的完整结构可以用三个词讲清楚：负载均衡实例、监听、后端服务器组。

负载均衡实例是整个服务的入口，负责接收来自客户端的访问请求。它分为公网类型和私网类型：公网实例自带公网IP，用户直接访问这个IP；私网实例只暴露在VPC内网里，通常用于内部服务之间互相调用。

监听是“分发策略”的载体。你创建监听时需要指定两件事：前端协议和端口、后端协议和端口。比如“对外提供HTTP 80端口的访问，实际把请求转发给后端的8080端口”，这种需求就是通过监听来配置的。监听定义了四层还是七层、用什么调度算法、怎么做健康检查。

后端服务器组是真正干活的ECS集合。你可以选择把流量分发给一组ECS，也可以配置主备服务器组或虚拟服务器组，后面会细说。

一句话总结：用户访问SLB实例，SLB按监听规则把请求分发到后端服务器组里的某台ECS上。ECSS不需要直接暴露公网IP，因为入口只有SLB一个。

2.2 四层与七层：协议栈差异决定了能力边界

这是SLB最核心的一条分界线。判断一道题考的是四层还是七层，先看它聊的是端口还是HTTP内容。

四层监听工作在传输层，对应TCP和UDP协议。SLB只查看网络包里的源IP、目的IP、源端口、目的端口，不做HTTP层面的解析，直接把流量转发给后端。它的优点是性能高、延迟低，适合对性能要求高的场景：数据库连接、游戏网关、视频推流、物联网长连接。

七层监听工作在应用层，对应HTTP和HTTPS协议。SLB会解开HTTP报文，看到URL路径、域名Host、Cookie、Header这些内容，所以能做更精细的路由，比如把某个域名的请求转发到一组服务器，把某个URL路径的请求转发到另一组。代价是CPU开销更大，性能比四层略低。

我备考时把这两者的差异做成了一张对比表，基本没再错过题：

理解这张表之后，很多判断题就变得很直接：题目说“四层监听可以按域名转发”，答案是错；题目说“HTTPS监听属于七层监听”，答案是对。

2.3 调度算法、会话保持和真实IP：三个绕不开的机制

调度算法解决的是“请求来了发给谁”的问题。经典三种：

• 加权轮询：按权重比例轮流分配。权重高的ECS拿到的请求多。适合请求处理时长接近、短连接为主的场景，比如普通Web站点。
• 加权最小连接数：实时看后端服务器的连接数，连接数少的多分一点，同时叠加权重。适合长连接或请求处理时长差异大的场景，比纯轮询更智能。
• 一致性哈希：把某个哈希因子（通常是源IP）相同的请求固定发给同一台后端。这个机制天然有“保持”效果，但使用场景更窄。

面试和考试都爱问的一个延伸点：为什么短连接用轮询很稳定，长连接却要优先看连接数？因为长连接建立一次会占用后端很久，轮询只看“建了几次连接”，不看“现在挂着多少连接”，可能导致某台ECS快挂了还在不停往它塞新连接。

会话保持解决的是“同一个用户的几次请求要不要落在同一台ECS上”。四层监听默认基于源IP做会话保持，超时时间内相同源IP都发到同一台后端；七层监听默认支持植入Cookie，也可以配置自定义Cookie。典型的应用场景就是购物车和登录态：用户在A机器登录了，下一个请求跑到B机器，B如果没同步登录态就会出问题。

还有一个高频考点和“真实IP”有关。七层监听作为反向代理转发请求时，后端ECS看到的是SLB的访问来源，不是用户的真实IP。要拿真实IP，就得在SLB上开启通过X-Forwarded-For请求头传递客户端IP，后端再解析这个Header。很多运维新手上线后查日志发现全是SLB的内网IP，就是漏了这一步。

3. 控制台配置题的高频雷区：监听、权重和健康检查

ACP不只考概念，还会把你拉到“控制台操作”的语境里，让你判断某个配置场景应该怎么设置。这部分如果没用控制台实际操作过，光靠背是容易出错的。

3.1 监听参数怎么记最不容易忘

创建监听时必填的核心参数就几个：前端协议、前端端口、后端协议、后端端口、调度算法。很多人容易把“前端”和“后端”搞反，其实只要记住一句：前端是用户看的，后端是服务器听的。

举例：用户习惯访问HTTPS 443，但后端ECS跑的是HTTP 8080。你的监听就配成前端HTTPS 443、后端HTTP 8080，证书挂在SLB上做解密，后端不碰证书。这就是常见的SSL卸载场景，既降低了ECS的计算压力，也统一了证书管理入口。

另外有两个高频判断题：

• 同一个SLB实例可以创建多个监听吗？可以。比如同时监听80和443，分别对应HTTP和HTTPS。
• 不同监听后端端口必须一致吗？不一定。每个监听可以独立指定后端端口，按具体服务走。

3.2 后端服务器组：权重、主备、虚拟组的取舍

后端服务器组不是“把ECS加进去”这么简单。给它设置权重时，范围一般是0到100，权重越高分到的流量越多，权重设为0表示不参与转发。这个“0就是不转发”的细节，判断题里出现过不止一次。

除了默认的服务器组，还有两种常见类型：

• 主备服务器组：同一时刻只有主服务器接收流量，备用服务器只等主服务器出问题才顶上。适合需要严格控制“双活”风险的场景，比如数据库代理层。
• 虚拟服务器组：一组后端可以按域名或URL路径绑定到同一个监听的不同转发规则上。典型形态是：/api开头走API服务组，其余走Web服务组。

还有一个和“平滑上线”相关的功能叫慢启动。新加进组的ECS如果立刻以满权重接流量，可能会被瞬时并发打崩。开启慢启动后，权重会在设定的时间内逐步提升，让新节点慢慢热身。这道题经常以“大促前扩容了一批ECS，如何避免刚扩容的机器被打挂”的问法出现。

3.3 健康检查参数与后端ECS故障摘除逻辑

健康检查是SLB“自动运维”能力的核心，也是我见过最多人理解偏差的地方。它的工作逻辑是：SLB按照你设置的间隔，定时对后端ECS发探测请求，连续成功若干次标记为健康，连续失败若干次标记为不健康；不健康的ECS会被自动摘除，不再接收新请求，恢复健康后自动加回。

四层监听的健康检查一般通过TCP端口探测实现，能建连就算健康；七层监听则是发HTTP请求到指定路径，看返回状态码，也可以配置检查响应内容。关键参数有四个：探测间隔、响应超时时间、健康阈值、不健康阈值。

我给你的复习建议是不要死记参数默认值，而是理解参数之间的配合逻辑。比如“健康阈值设得很大”意味着要连续成功很多次才认为恢复，可以避免后端刚起来就被大批流量压垮，但也会延长摘除后的恢复时间；“不健康阈值设得很大”则意味着SLB要容忍后端连续失败多轮才摘除，能减少抖动误杀，但会让故障影响时间变长。考试不会让你背默认值，但会给你一个业务场景让你选合理的配置倾向。

还有一个隐藏深坑：后端ECS的安全组如果没有放行SLB健康检查的来源地址，SLB探测不到端口，后端会被判定为不健康，流量始终异常。我见过不止一个同学在控制台排查半天，最后发现是安全组规则漏了。备考时不用记具体网段，但要记住“安全组必须放行健康检查来源”这个结论。

4. 进阶功能考点：转发策略、证书和访问控制

如果说前面是SLB的“基础操作”，那这一章聊的就是让SLB从“能用”变成“好用”的进阶功能，也是多选和场景题最喜欢的素材。

4.1 域名与URL转发规则

七层监听支持域名和URL路径转发，这是四层做不到的。它的意义在于，一台SLB实例只需要一个公网IP，就可以把不同业务的流量按域名或路径分流到不同的虚拟服务器组。

举例，一个电商系统在同一个SLB后面挂了三个后端组：

• 用户访问 www.example.com 且路径以 /api/ 开头 → 转发到API服务器组
• 路径以 /static/ 开头 → 转发到静态资源服务器组
• 其他请求 → 默认转发到Web服务器组

配置时需要注意规则优先级。多组规则同时命中时，SLB一般按规则创建的先后顺序或系统给定的优先级匹配，具体以控制台说明为准。理解这一点比背规则编号更重要：真实业务里规则条数多了以后，最容易出问题的就是“两条规则互相覆盖”。

考试里常见的变体是：某电商有多个域名，不同域名对应不同后端，应该怎么配置。答案思路就是：一台七层HTTPS监听，配多条域名转发规则，每条指向一个虚拟服务器组。看到“按域名分流”字样，第一反应就应该是虚拟服务器组加转发规则，而不是再开一台SLB。

4.2 HTTPS监听与证书管理

HTTPS监听和证书是安全类的稳定考点。创建HTTPS监听时，SLB要求配置SSL证书，证书需要包含公钥和私钥。控制台上传证书时，最常见的问题是“证书内容格式不对”或“证书与私钥不匹配”，实际工作中多半是多了空格、换行格式损坏，或者私钥和证书根本不是同一对。

两类高频判断题值得记：

• 证书到期了还能正常访问吗？SLB会提示证书到期，但已配置的HTTPS监听在证书材料未失效前仍会继续工作。实际运维中要赶在到期前续期，否则用户访问时浏览器会报警。
• 支持双向认证吗？支持。HTTPS单向认证只验证服务器身份，双向认证还会验证客户端证书，适合内部系统、金融类业务等高要求场景。

另一个和“四层七层”关联的考点是：如果你用的是四层TCP监听，又想加密，一般需要后端自己处理证书；只有七层HTTPS监听才能把SSL卸载放到SLB上。这一点和前面协议栈对比是呼应的。

4.3 访问控制：黑白名单的判定逻辑

SLB的访问控制是配置在监听层面的，支持白名单和黑名单两种模式。逻辑很简单：

• 白名单模式：只有名单里的IP才能访问，其他全部拒绝。适合办公系统、管理后台这类只对特定来源开放的业务。
• 黑名单模式：名单里的IP被拒绝，其他都可以访问。适合封禁恶意攻击来源、异常爬虫IP。

考场上的坑在于“默认策略”。白名单模式下，名单为空就等于全部拒绝访问；黑名单模式下，名单为空就等于全部放行。有些题会故意问“某公司只允许办公网段访问管理后台，审计时发现某些员工无法访问”，答案方向就是检查白名单里是否漏了对应网段。

还需要知道一个限制：访问控制基于IP地址生效，做的是粗粒度管控。如果要精细到用户名、Token、请求路径，那是WAF或应用层的事，不是SLB访问控制的职责。知道这条边界，就不会被诱导性选项带跑。

5. 联动考题不能只看SLB本身：高可用架构里的位置

ACP的难度有一半在“跨产品”。单考SLB概念大家都能答对，但把SLB放进一个完整链路里，和弹性伸缩、DNS、WAF混在一起，就容易晕。这一章专门讲联动。

5.1 多可用区容灾

SLB支持同地域多可用区部署，这是容灾类送分题的固定答案。具体机制是：创建SLB实例时选择主可用区和备可用区，正常情况下流量走主可用区；如果主可用区发生故障，SLB自动切换到备用可用区的后端服务器，实现跨可用区高可用。

注意边界：SLB只支持同地域内的多可用区容灾，不支持跨地域负载均衡。跨地域容灾需要配合云解析DNS，让不同地域的用户解析到不同地域的SLB入口。这道判断题几乎每个题库都有：题目说“SLB支持跨地域负载均衡”，答案是错。

配合这道题还有一个常见场景：某应用部署在两个可用区的多台ECS中，SLB应该选择“多可用区部署”还是“同可用区部署”？答案当然是多可用区。原因不是负载更均衡，而是避免单可用区故障导致全部后端不可用。

5.2 和弹性伸缩、DNS、高防、WAF的配合

弹性伸缩和SLB是天生一对。伸缩组里新扩容出来的ECS会自动加入SLB后端并开始接收流量，缩容时自动摘除。考试里经常考“大促前临时扩容10台ECS，如何让扩容出来的机器自动接入SLB”，答案思路就是同时配置弹性伸缩组和SLB联动，而不是手动一台台去控制台添加。

DNS和SLB的配合主要是做域名解析。用户访问域名时，DNS把域名解析到SLB的公网IP。如果后面再叠加高防或WAF，解析链路会变成“DNS → 高防/WAF → SLB → 后端ECS”。高防负责清洗大流量DDoS攻击，WAF负责拦截Web层攻击，真正可用的业务流量才回源到SLB。

CDN也是联动常客。静态资源如图片、CSS、JS由CDN缓存，动态请求回源到SLB。判断依据很简单：看请求内容是固定的还是实时生成的。静态走CDN，动态走SLB回源。

记住一个原则：SLB解决的是“流量分发到多台ECS”，它不负责缓存静态内容、不负责清洗超大流量、不负责Web漏洞拦截。看到对应需求，应该选CDN、高防和WAF，而不是指望SLB一把梭。

5.3 典型架构题的解题思路

我在刷题时最怕的是那种又臭又长、描述一堆业务痛点的场景题，后来总结出一个三步拆解法，正确率明显上来了：

第一步，找“核心目标”。题目说“提升系统并发处理能力”“消除单点故障”“实现平滑扩容”，这些目标直接对应SLB加弹性伸缩。

第二步，找“附加威胁”。出现“大流量攻击”“CC攻击”“SQL注入”，对应高防和WAF；出现“网站内容更新频繁全国加速”，对应CDN。

第三步，找“数据库边界”。看到数据库，不要想着用SLB去负载数据库，RDS自带主备高可用和读写分离，SLB不负责数据库分发。选错这个基本整题凉凉。

以电商大促为例，合理架构通常是：DNS把域名解析到高防IP，高防清洗后回源到WAF，WAF过滤Web攻击，然后把请求交给SLB，SLB分给同一个地域两个可用区内的ECS集群，ECS按压力由弹性伸缩动态扩缩容，数据库用RDS高可用版本。这个链路里，SLB的左侧是高防和WAF，右侧是ECS和弹性伸缩，上下还有DNS和RDS。想清每个产品的位置，场景题就不怕了。

6. 刷题阶段的易混点和冲刺建议

知识框架搭好之后，接下来就是和错题搏斗。我把备考过程中反复出现的易错点集中整理了一下，这一章直接给结论，方便你做考前速查。

6.1 我踩过的高频易错点清单

这张表里的每一行都来自真实做错后的复盘。你会发现大部分错误并不是“不知道知识点”，而是“概念边界没卡死”。所以我建议你刷题时不要只看正确选项，而是把错误选项为什么不对写出来，哪怕一句话也行。这个过程比刷十道新题更有用。

6.2 考前两周的复习安排和个人复盘经验

如果你离考试还剩两周，我会这样建议：

第一周，做知识框架复述。不看文档，拿一张白纸画出SLB的组成结构图：实例、监听、后端服务器组，再把健康检查、会话保持、转发策略、证书、访问控制这些功能挂在对应的位置。能画出来，说明框架已经在你脑子里；画不出来，就回去看对应章节。这个过程每天重复一次，直到闭眼能默出为止。

第二周，刷题加错题归档。按“概念、边界、配置、场景”四类分类刷题。我自己的标准是：同一类型题目连续错两次以上，就停下来翻官方帮助文档，把对应章节的原话读一遍，再重新做。错题不是记录完就完了，每两天要重新做一遍最近两天的错题，直到连续做对两次才可以从列表里划掉。

考前最后两天，只看这张易错点表和自己的错题记录，不再碰新题。原因很简单，你已经复习到这个阶段，决定分数上限的不是还能学会多少新知识，而是已经会的东西在考场上别丢。

最后分享一个让我受益很大的小习惯：做题时把“SLB、ECS、RDS、云解析DNS、WAF、弹性伸缩”这几个产品画成一张小图，每做一道场景题就把题里的流量路径在图里走一遍，看卡在哪一环。这个方法帮我从“背知识点”过渡到了“用知识点”，我觉得比盲目刷题效率高很多。希望这篇整理也能帮你建立同样的感觉。