企业官网建设流程全解析

备考某云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服务一般用80，HTTPS用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核机器设权重200，2核机器设权重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。这个页面不需要查询数据库，不需要读文件，也不需要校验用户身份，它是专门给负载均衡探活用的。做好这一步，基本上能规避掉三分之一的健康检查误报问题。