把一次请求从浏览器到服务器的完整旅程拆开看会发现路上其实站着三个角色CDN负责“抄近路”负载均衡负责“分流道”反向代理负责“守大门的换乘站”。很多人在面试、写架构方案、排查线上事故时把这三个概念混在一起其实它们解决的问题、部署的位置、生效的层级完全不同。这篇文章不抄概念定义直接从一次真实请求出发讲清楚三者各自的职责边界、底层原理再给一套可以在本地跑起来的模拟演示让“看懂”变成“会用”。1. 从一次真实请求出发看清三者各自的职责边界任何网络架构本质上都是在回答一个问题用户输入网址按下回车之后这个请求怎么走、谁来接、最终落在哪台机器上。一次看似简单的访问背后往往叠加了三层不同的机制。我在做某电商平台压测的时候把一次请求从头到尾抓了一遍才真正意识到这三者是在不同的环节干不同的事。用户敲下域名操作系统先做DNS解析。这时候CDN已经插手了如果域名接入了CDNDNS解析返回的不是源站的真实地址而是离用户最近的一个边缘节点的IP。这个节点通常叫边缘缓存服务器它可能就在同一个城市的某个机房里。CDN做的事情是让用户请求“够近就停”如果边缘节点上有缓存内容直接返回连源站都不碰。这一步解决的是“远”的问题——地理距离带来的网络延迟和高防丢失。请求到了边缘节点没命中缓存才会上行回源这个回源的请求接下来会碰到一个入口网关通常就是反向代理。反向代理表面上是接收请求、再转发给内部服务器但它真正的存在理由是“隔离”和“转化”用户只看到网关的地址不知道背后真正的应用服务器在哪网关可以统一接管证书、限流、路径路由、日志等非业务逻辑请求到达后端之前可以被改写成后端真正认识的结构。再往后如果后端不止一台机器负载均衡就开始工作了。它从反向代理接过来的请求里按照一定策略挑选一台实际处理业务的应用服务器。这一步解决的是“多”的问题——单台机器扛不住流量那就把流量分散到多台上。关键区别记住一句话CDN解决“我怎么把内容送到用户身边”负载均衡解决“这一堆服务器谁来干活”反向代理解决“请求进来之后如何被安全、合理地转交”。三者可以独立存在也可以在一条链路里串联协作。这个认知很重要因为很多人问“我用了Nginx是不是就有负载均衡了”其实是把反向代理和负载均衡混在一起。Nginx同时具备两种能力但它监听443端口、做证书卸载、转发请求时身份是反向代理当它背后配置了多个上游服务器并按照轮询或哈希策略分发时才是在做负载均衡。一个模块可以身兼两职但概念边界必须清晰。2. CDN真正解决的是“远”不是“快”核心藏在缓存与就近CDN全称是内容分发网络。最直观的理解是如果你把服务器放在某一线城市一个偏远地区的用户访问你的站点数据包要经过很长的骨干链路光传输的物理时延就摆在那里再怎么优化后端代码都没用。CDN的思路是“把内容搬到用户身边”——在全国乃至全球部署大量边缘节点用户访问时自动解析到最近的节点由这个节点直接把内容吐给他。2.1 边缘节点与回源机制恰好是CDN的两条腿CDN的架构核心可以拆成两部分。第一部分是边缘节点它承担了绝大多数用户的读请求。一个设计良好的静态资源CDN缓存命中率能做到90%以上这意味着每100次用户请求里最多只有几次需要真正回到源站去取数据。第二部分是回源机制当边缘节点没有缓存或者缓存内容已经过期它就必须向源站发起请求拿到最新内容后再缓存下来同时返回给用户。回源听起来简单里面有个很关键的细节叫“回源HOST”。我遇到过不少人在接入CDN之后发现网页样式错乱、图片加载不出来排查到最后往往就是回源HOST没有配置。边缘服务器回源的时候需要通过域名来告诉源站“我来取哪个站点的内容”如果回源HOST填错或没填源站上的虚拟主机就不知道该返回哪个业务的内容。2.2 缓存命中率不是靠运气而是靠缓存策略CDN加速效果好不好一个硬指标是缓存命中率。这个数字直接决定了回源的流量大小、源站的压力以及用户拿到的响应速度。而命中率不是配置一下CDN就自动变高的它主要取决于源站返回的HTTP缓存头。我给某内容类站点调优时遇到过典型问题源站所有接口都返回了Cache-Control: no-cache导致CDN每次请求都回源命中率只有百分之十几CDN几乎退化成纯转发。后来把静态资源的响应头改成Cache-Control: max-age86400同时配合CDN节点的缓存规则命中率才一路涨到85%以上。所以接CDN之前先回头审视自己的响应头这一步的收益往往比调整CDN控制台参数更大。实际操作中控制台里的缓存配置一般这么设置静态文件js/css/png/jpg/webp/woff等建议缓存7天以上配合文件名哈希更新机制不带参数的HTML页面建议缓存几分钟到几小时需要自己能接受延迟API接口除非是纯公开数据否则不建议开CDN缓存或者只做很短的缓存带用户身份的请求直接绕过CDN缓存走全链路透传。很多人以为CDN只能加速静态内容其实动态请求也有对应的方案——动态加速本质是让CDN节点通过最优线路和源站建立连接降低公网链路的抖动和丢包。原理上它不是一个缓存产品而是一条“网络高速公路”。不过这类方案成本比较高一般业务用静态资源CDN加智能DNS就足够覆盖绝大多数需求了。2.3 一个容易被忽略的细节节点分布决定了用户体验下限CDN调优还有个容易忽略的维度就是节点的地域覆盖度。接入CDN之后你可以在管理控制台看“地域维度请求量分布”如果发现某个地区的用户请求大量回源或者该地区命中率明显偏低大概率是当地节点资源不足。这种情况下的调整办法不是改代码而是联系服务商确认该区域的节点扩容计划或者考虑在回源链路上做优化比如源站多线接入、回源走内网。记住CDN能优化的是“最后一公里”和“中间链路”最终回源的那一跳如果太慢整体体验依旧好不了。3. 负载均衡解决的是“多”从一台扛不住到一百台扛得住当业务量上来以后一台应用服务器再强也有限度。我在跑压测的时候某台8核16G的服务器纯接口请求大概在每秒两三千的吞吐后就出现明显抖动CPU打到80%以上RT直线上升。这个场景下自然想到“加机器”但加了机器之后请求怎么分配谁来决定该给哪台这就是负载均衡存在的理由。3.1 四层与七层负载均衡应该怎么选负载均衡有两个主要流派四层L4和七层L7。它们的核心区别在于工作在哪一层以及能感知到什么信息。四层模式工作在传输层基于IP和端口做转发不关心HTTP协议内容。它对报文只做NAT网络地址转换或DR直接路由级别的转发性能极高。我实测过纯四层转发在普通商用服务器上每秒处理数万连接很轻松CPU占用很低。适合的场景是TCP/UDP长连接服务、数据库中间件、游戏网关等对性能敏感的流量入口。七层模式工作在应用层能看到完整的HTTP请求包括URL路径、请求头、Cookie。它能做的事情就多得多按照路径转发到不同服务、根据Header做灰度分流、识别WebSocket连接等。代价是性能比四层低一些因为它要终结HTTP请求再重新发起。我们平时最常用的分类是技术选型时流量入口用七层负载均衡做路由灵活性数据库层用四层负载均衡做纯性能分发。3.2 负载均衡算法不是越复杂越好常见的负载均衡算法主要有下面几种我直接说说它们各自适合的场景轮询每个请求轮流发给后端适合后端机器配置一样、请求处理时长差不多的场景。最简单也最常用。加权轮询给配置高的机器更大的权重适合后端机器规格不一致的集群。最少连接谁当前正在处理的请求少就发给谁。适合长连接、请求时长差异大的场景比如WebSocket服务。一致性哈希同一个用户的请求总是发给同一台后端机器。适合有状态服务比如需要本地Session或本地缓存的场景。最难的不是理解算法本身而是识别自己的业务到底需要哪一种。我见过某团队搞了个复杂的自定义加权策略结果上线后发现不如直接轮询的效果好因为他们的后端服务是Redis这种本身就做了横向扩展的无状态组件算法权重反而干扰了分配的均匀度。判断依据很简单如果后端服务已经做到完全无状态选最简单均匀的算法如果某个请求必须固定落到某台机器比如带本地缓存才考虑哈希类算法只有在后端处理能力差异明显时加权才有意义。3.3 健康检查是负载均衡的保底机制负载均衡还有一半功能藏在不显眼的地方——健康检查。它定期向后端探测服务是否活着一旦某台机器上报失败就把它从转发池里摘除不给他分流量恢复后自动加回来。这一步决定了整个集群“抗故障”的能力。我遇到过一种非常隐蔽的问题健康检查检查的是某个固定URL的返回码但业务核心接口依赖的数据库连接池已经快满了。健康检查一直显示“正常”前端还在持续往这台机器发流量结果接口大面积超时。后来把健康检查从“探测页面存活性”升级为“探测核心依赖的轻量接口并且设定合理的响应时间阈值”问题才控制住。所以健康检查的设计必须贴近真实请求链路不能只检查“进程活着”更不是随便写一个200返回就算数。4. 反向代理的核心是“隔离与转化”不只是转发反向代理最常见的实现是Nginx、HAProxy、云上的网关产品。很多人把它简单理解为“转发器”这其实低估了它在整个架构里承担的分量。反向代理的核心价值在于它站在流量入口处把外部请求和内部服务彻底隔开然后在入口位置统一处理所有“非业务逻辑”。4.1 路由与改写反向代理的看家本领反向代理最基础的能力就是“按规则路由”。同样一个域名/api/前缀的请求转发到后端A集群/web/前缀的请求转发到静态资源服务这就是典型的路径级路由。它能做到的还不止这么简单改写URL把前端友好的路径改写成后端真实接口路径改写请求头注入用户真实IP、附加内部认证信息、设置超时时间改写响应头统一增加安全响应头比如X-Content-Type-Options请求体限制在入口直接拦截超大请求体避免后端被拖垮。举一个日常的例子假设前端需要调用/api/user/profile而后端服务实际暴露的接口是/user-service/v2/user/profile反向代理可以通过一行rewrite指令把它转换过来。这样做的好处是后端无论怎么改内部路径、怎么拆服务对外暴露的接口契约可以保持稳定。4.2 反向代理与负载均衡的实际分工在同一套Nginx配置里可能同时出现反向代理和负载均衡的段落。举个例子upstream backend_cluster { server 10.0.0.11:8080 weight3; server 10.0.0.12:8080 weight1; server 10.0.0.13:8080 backup; } server { listen 443 ssl; server_name api.example.com; location /api/ { proxy_pass http://backend_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }upstream段定义了一个后端集群配了加权轮询还设置了一个备份节点这段就是在做负载均衡而server里对/api/路径的转发、设置请求头、做证书卸载这是标准的反向代理职责。两段协作完成整个入口能力。理解这个组合关系就能明白为什么很多人说“Nginx是反向代理和负载均衡一体化的最典型例子”了。4.3 入口网关的隐藏能力安全与性能的统一收口反向代理还有一个容易被忽视的价值——它是安全策略和性能策略的天然收口位置。入口处可以做IP黑白名单、单IP限流、全局限流这个位置做拦截成本最低因为请求还没触达业务逻辑。性能层面TLS证书统一在这里卸载后端服务只需要处理HTTP明文流量减少了后端的加密开销。HTTP/2、HTTP/3的协议升级也在这一层完成后端完全不用关心。我之前给某团队做架构梳理时发现他们的网关层居然把超时时间设成了默认60秒而下游某个数据分析接口偶尔需要跑两分钟导致大量请求在网关超时被切断后端任务还在继续跑产生了不少脏数据。把超时时间改为可配置、按接口差异化设置之后问题才解决。这一类问题最能体现反向代理“入口统一管控”的价值也最容易因为配置不当而坑到业务。5. 实战演示三台容器搭出一条真实的流量链路理论知识说得再多不如亲手把链路搭一遍。下面这套演示用Docker Compose在本地拉起三个角色一个模拟CDN边缘节点用本地Nginx加缓存模块实现、一个负载均衡层同样用Nginx但只做转发分发、两个后端应用服务器分别监听不同端口。整体拓扑是请求 → CDN边缘节点 → 负载均衡 → 后端服务A/B。这个演示核心是观察“请求经过每一层后发生的变化”而不是追求生产级别的性能。所有配置以“能跑通、能看到效果”为准。5.1 准备三个容器的编排文件先建立一个项目目录比如edge-demo。目录里包含docker-compose.yml、nginx-cdn.conf、nginx-lb.conf、以及两个后端服务目录。完整文件清单如下version: 3.8 services: cdn: image: nginx:1.25 container_name: mock-cdn ports: - 8081:80 volumes: - ./nginx-cdn.conf:/etc/nginx/conf.d/default.conf - ./static:/usr/share/nginx/html depends_on: - lb lb: image: nginx:1.25 container_name: mock-lb expose: - 80 volumes: - ./nginx-lb.conf:/etc/nginx/conf.d/default.conf depends_on: - app1 - app2 app1: image: nginx:1.25 container_name: mock-app1 expose: - 80 volumes: - ./app1:/usr/share/nginx/html app2: image: nginx:1.25 container_name: mock-app2 expose: - 80 volumes: - ./app2:/usr/share/nginx/html这里的cdn服务就是模拟的CDN边缘节点lb是负载均衡层app1和app2是两个后端节点。为了保证演示清晰三个角色各自使用独立的配置文件互不掺和。5.2 配置负载均衡层观察请求到底分给谁负载均衡层的配置如下upstream app_cluster { server app1:80; server app2:80; } server { listen 80; server_name localhost; location / { proxy_pass http://app_cluster; add_header X-Backend-Server $hostname always; } }后端两台容器返回的响应里通过add_header追加了一个响应头X-Backend-Server这个头会告诉我们是哪台容器返回了内容。启动后多刷新几次页面能看到响应头里X-Backend-Server的值在mock-app1和mock-app2之间交替变化这就是轮询效果的可视化验证。为了让负载均衡的观察更直观可以给两台后端容器放不同的内容app1的页面显示“APP1实例”app2显示“APP2实例”。浏览器反复刷新就能看到内容在两个实例间切换。5.3 配置模拟CDN边缘节点观察缓存命中与回源CDN边缘节点配置文件如下proxy_cache_path /var/cache/nginx levels1:2 keys_zoneedge_cache:10m max_size100m inactive60m; server { listen 80; server_name localhost; location / { proxy_cache edge_cache; proxy_cache_valid 200 10m; proxy_cache_key $host$request_uri; proxy_pass http://lb:80; add_header X-Cache-Status $upstream_cache_status always; } }这个配置做了两层事情定义了本地磁盘缓存路径和缓存区keys_zoneedge_cache:10m就是给缓存元数据划分了一块10MB的内存区当请求打到这个边缘节点时先查缓存没有就转发给负载均衡层proxy_pass http://lb:80拿到响应后按10分钟的缓存有效期存下来并通过X-Cache-Status头暴露这次是“命中缓存”还是“回源取数据”。实际验证的时候第一次请求会看到X-Cache-Status: MISS连续刷新几次变成X-Cache-Status: HIT。这个实验虽然简单但能让你直观理解CDN命中和回源的区别。5.4 启动演示与链路验证在项目目录里执行docker compose up -d --build等所有容器都变成Up状态之后访问http://localhost:8081/看到的流程是请求进入mock-cdn它先查本地缓存未命中则转发给mock-lbmock-lb按轮询把请求交给mock-app1或mock-app2后端返回内容mock-cdn把结果缓存并返回给浏览器。用curl看响应头是最直接的验证方式curl -I http://localhost:8081/ HTTP/1.1 200 OK X-Backend-Server: mock-app1 X-Cache-Status: HIT用X-Backend-Server确认负载均衡生效用X-Cache-Status确认CDN缓存生效。这样一个最小化的链路就把三个角色的职责全部串起来了。5.5 演示之外的延伸观察把演示跑通之后还可以做两组小实验加深理解第一组关掉app1容器刷新请求会发现负载均衡层自动把流量全部转发给app2这就是健康检查保护的直观效果。docker stop mock-app1之后无需任何人工干预。第二组在CDN配置里把proxy_cache_valid调成1分钟然后修改app1里的页面内容1分钟之内刷新看到的还是旧内容超过1分钟再刷新才看到新内容。这一步能扎扎实实理解“缓存生效时间”的含义。6. 架构决策什么时候该上CDN、负载均衡、反向代理以及踩过的坑看完原理和演示最后一个问题是我的项目到底需要哪些角色这三个组件不是越多越好每加一层就多一层延迟和运维复杂度。结合我自己的经验给出一套决策路径6.1 从单机到集群再到全国分发单台服务器、域名直接解析到这台机器什么都不用加只需要在业务前面放一个反向代理处理HTTPS、日志和静态资源。Nginx或者云上的Web服务就能解决。单机扛不住了横向扩容成两台以上必须在入口加负载均衡此时Nginx的upstream配置就够了。同时把Session设计成无状态否则哈希策略解决不了宕机后的会话丢失。后端服务很多、路径区隔明显把入口代理升级成网关按路径路由到不同服务这时候反向代理的价值最为明显。静态资源多、用户分布广、跨地域访问卡顿到这一步再接入CDN把静态资源、下载内容、音视频流推到边缘节点。这套演进路径的核心思想是需求驱动组件引入不要为了用而用。6.2 实际项目中常见的几个认知坑这次讲解中我认为有三个坑最值得重点提醒第一个把负载均衡算法当成性能优化工具。大多数业务在绝大多数时候简单轮询就足够好只有后端处理能力差异大、请求时长差异大的场景才需要考虑更复杂的算法。先压测再调算法。第二个接入CDN前不检查缓存头。CDN的缓存行为受源站响应头控制如果源站所有接口都返回no-cacheCDN会形同虚设。在接入CDN前先统一静态资源的缓存头策略。第三个忽略了链路中的超时和重试设置。入口网关的超时时间、负载均衡的重试次数、CDN的回源超时这三者必须联动考虑。遇到过网关只允许3秒超时、而后端大数据接口要跑10秒的经典事故不是代码问题纯粹是链路参数没对齐。6.3 最后分享一个排查思路线上出现“访问变慢、部分用户打不开页面”这类问题时按照“客户端→DNS→CDN→入口网关→负载均衡→应用服务器”逐层看数据先看延迟出现在哪一段浏览器开发者工具的Timing面板里DNS和连接时间异常偏大大概率是CDN或DNS问题请求发出到首字节时间偏大可能是反向代理转发问题TTFB首字节时间大而整体传输不大大概率是后端处理慢。再看响应头Via头能看出是否经过CDNX-Cache-Status能看出是否命中X-Backend-Server能看出是哪台后端节点返回的。每层都加上有辨识度的响应头排查链路时能省下一半时间。不要一上来就查应用代码先把链路每一层的“证据”收集齐问题往往自己就浮出水面了。这套思路在我多次参与线上问题排查时都被证明是最省力的方案。 
长河君 · 2026/10/13 4:13:58 · 阅读 1.2k 一次请求的旅程：CDN、负载均衡与反向代理的职责边界与实战演示
把一次请求从浏览器到服务器的完整旅程拆开看会发现路上其实站着三个角色CDN负责“抄近路”负载均衡负责“分流道”反向代理负责“守大门的换乘站”。很多人在面试、写架构方案、排查线上事故时把这三个概念混在一起其实它们解决的问题、部署的位置、生效的层级完全不同。这篇文章不抄概念定义直接从一次真实请求出发讲清楚三者各自的职责边界、底层原理再给一套可以在本地跑起来的模拟演示让“看懂”变成“会用”。1. 从一次真实请求出发看清三者各自的职责边界任何网络架构本质上都是在回答一个问题用户输入网址按下回车之后这个请求怎么走、谁来接、最终落在哪台机器上。一次看似简单的访问背后往往叠加了三层不同的机制。我在做某电商平台压测的时候把一次请求从头到尾抓了一遍才真正意识到这三者是在不同的环节干不同的事。用户敲下域名操作系统先做DNS解析。这时候CDN已经插手了如果域名接入了CDNDNS解析返回的不是源站的真实地址而是离用户最近的一个边缘节点的IP。这个节点通常叫边缘缓存服务器它可能就在同一个城市的某个机房里。CDN做的事情是让用户请求“够近就停”如果边缘节点上有缓存内容直接返回连源站都不碰。这一步解决的是“远”的问题——地理距离带来的网络延迟和高防丢失。请求到了边缘节点没命中缓存才会上行回源这个回源的请求接下来会碰到一个入口网关通常就是反向代理。反向代理表面上是接收请求、再转发给内部服务器但它真正的存在理由是“隔离”和“转化”用户只看到网关的地址不知道背后真正的应用服务器在哪网关可以统一接管证书、限流、路径路由、日志等非业务逻辑请求到达后端之前可以被改写成后端真正认识的结构。再往后如果后端不止一台机器负载均衡就开始工作了。它从反向代理接过来的请求里按照一定策略挑选一台实际处理业务的应用服务器。这一步解决的是“多”的问题——单台机器扛不住流量那就把流量分散到多台上。关键区别记住一句话CDN解决“我怎么把内容送到用户身边”负载均衡解决“这一堆服务器谁来干活”反向代理解决“请求进来之后如何被安全、合理地转交”。三者可以独立存在也可以在一条链路里串联协作。这个认知很重要因为很多人问“我用了Nginx是不是就有负载均衡了”其实是把反向代理和负载均衡混在一起。Nginx同时具备两种能力但它监听443端口、做证书卸载、转发请求时身份是反向代理当它背后配置了多个上游服务器并按照轮询或哈希策略分发时才是在做负载均衡。一个模块可以身兼两职但概念边界必须清晰。2. CDN真正解决的是“远”不是“快”核心藏在缓存与就近CDN全称是内容分发网络。最直观的理解是如果你把服务器放在某一线城市一个偏远地区的用户访问你的站点数据包要经过很长的骨干链路光传输的物理时延就摆在那里再怎么优化后端代码都没用。CDN的思路是“把内容搬到用户身边”——在全国乃至全球部署大量边缘节点用户访问时自动解析到最近的节点由这个节点直接把内容吐给他。2.1 边缘节点与回源机制恰好是CDN的两条腿CDN的架构核心可以拆成两部分。第一部分是边缘节点它承担了绝大多数用户的读请求。一个设计良好的静态资源CDN缓存命中率能做到90%以上这意味着每100次用户请求里最多只有几次需要真正回到源站去取数据。第二部分是回源机制当边缘节点没有缓存或者缓存内容已经过期它就必须向源站发起请求拿到最新内容后再缓存下来同时返回给用户。回源听起来简单里面有个很关键的细节叫“回源HOST”。我遇到过不少人在接入CDN之后发现网页样式错乱、图片加载不出来排查到最后往往就是回源HOST没有配置。边缘服务器回源的时候需要通过域名来告诉源站“我来取哪个站点的内容”如果回源HOST填错或没填源站上的虚拟主机就不知道该返回哪个业务的内容。2.2 缓存命中率不是靠运气而是靠缓存策略CDN加速效果好不好一个硬指标是缓存命中率。这个数字直接决定了回源的流量大小、源站的压力以及用户拿到的响应速度。而命中率不是配置一下CDN就自动变高的它主要取决于源站返回的HTTP缓存头。我给某内容类站点调优时遇到过典型问题源站所有接口都返回了Cache-Control: no-cache导致CDN每次请求都回源命中率只有百分之十几CDN几乎退化成纯转发。后来把静态资源的响应头改成Cache-Control: max-age86400同时配合CDN节点的缓存规则命中率才一路涨到85%以上。所以接CDN之前先回头审视自己的响应头这一步的收益往往比调整CDN控制台参数更大。实际操作中控制台里的缓存配置一般这么设置静态文件js/css/png/jpg/webp/woff等建议缓存7天以上配合文件名哈希更新机制不带参数的HTML页面建议缓存几分钟到几小时需要自己能接受延迟API接口除非是纯公开数据否则不建议开CDN缓存或者只做很短的缓存带用户身份的请求直接绕过CDN缓存走全链路透传。很多人以为CDN只能加速静态内容其实动态请求也有对应的方案——动态加速本质是让CDN节点通过最优线路和源站建立连接降低公网链路的抖动和丢包。原理上它不是一个缓存产品而是一条“网络高速公路”。不过这类方案成本比较高一般业务用静态资源CDN加智能DNS就足够覆盖绝大多数需求了。2.3 一个容易被忽略的细节节点分布决定了用户体验下限CDN调优还有个容易忽略的维度就是节点的地域覆盖度。接入CDN之后你可以在管理控制台看“地域维度请求量分布”如果发现某个地区的用户请求大量回源或者该地区命中率明显偏低大概率是当地节点资源不足。这种情况下的调整办法不是改代码而是联系服务商确认该区域的节点扩容计划或者考虑在回源链路上做优化比如源站多线接入、回源走内网。记住CDN能优化的是“最后一公里”和“中间链路”最终回源的那一跳如果太慢整体体验依旧好不了。3. 负载均衡解决的是“多”从一台扛不住到一百台扛得住当业务量上来以后一台应用服务器再强也有限度。我在跑压测的时候某台8核16G的服务器纯接口请求大概在每秒两三千的吞吐后就出现明显抖动CPU打到80%以上RT直线上升。这个场景下自然想到“加机器”但加了机器之后请求怎么分配谁来决定该给哪台这就是负载均衡存在的理由。3.1 四层与七层负载均衡应该怎么选负载均衡有两个主要流派四层L4和七层L7。它们的核心区别在于工作在哪一层以及能感知到什么信息。四层模式工作在传输层基于IP和端口做转发不关心HTTP协议内容。它对报文只做NAT网络地址转换或DR直接路由级别的转发性能极高。我实测过纯四层转发在普通商用服务器上每秒处理数万连接很轻松CPU占用很低。适合的场景是TCP/UDP长连接服务、数据库中间件、游戏网关等对性能敏感的流量入口。七层模式工作在应用层能看到完整的HTTP请求包括URL路径、请求头、Cookie。它能做的事情就多得多按照路径转发到不同服务、根据Header做灰度分流、识别WebSocket连接等。代价是性能比四层低一些因为它要终结HTTP请求再重新发起。我们平时最常用的分类是技术选型时流量入口用七层负载均衡做路由灵活性数据库层用四层负载均衡做纯性能分发。3.2 负载均衡算法不是越复杂越好常见的负载均衡算法主要有下面几种我直接说说它们各自适合的场景轮询每个请求轮流发给后端适合后端机器配置一样、请求处理时长差不多的场景。最简单也最常用。加权轮询给配置高的机器更大的权重适合后端机器规格不一致的集群。最少连接谁当前正在处理的请求少就发给谁。适合长连接、请求时长差异大的场景比如WebSocket服务。一致性哈希同一个用户的请求总是发给同一台后端机器。适合有状态服务比如需要本地Session或本地缓存的场景。最难的不是理解算法本身而是识别自己的业务到底需要哪一种。我见过某团队搞了个复杂的自定义加权策略结果上线后发现不如直接轮询的效果好因为他们的后端服务是Redis这种本身就做了横向扩展的无状态组件算法权重反而干扰了分配的均匀度。判断依据很简单如果后端服务已经做到完全无状态选最简单均匀的算法如果某个请求必须固定落到某台机器比如带本地缓存才考虑哈希类算法只有在后端处理能力差异明显时加权才有意义。3.3 健康检查是负载均衡的保底机制负载均衡还有一半功能藏在不显眼的地方——健康检查。它定期向后端探测服务是否活着一旦某台机器上报失败就把它从转发池里摘除不给他分流量恢复后自动加回来。这一步决定了整个集群“抗故障”的能力。我遇到过一种非常隐蔽的问题健康检查检查的是某个固定URL的返回码但业务核心接口依赖的数据库连接池已经快满了。健康检查一直显示“正常”前端还在持续往这台机器发流量结果接口大面积超时。后来把健康检查从“探测页面存活性”升级为“探测核心依赖的轻量接口并且设定合理的响应时间阈值”问题才控制住。所以健康检查的设计必须贴近真实请求链路不能只检查“进程活着”更不是随便写一个200返回就算数。4. 反向代理的核心是“隔离与转化”不只是转发反向代理最常见的实现是Nginx、HAProxy、云上的网关产品。很多人把它简单理解为“转发器”这其实低估了它在整个架构里承担的分量。反向代理的核心价值在于它站在流量入口处把外部请求和内部服务彻底隔开然后在入口位置统一处理所有“非业务逻辑”。4.1 路由与改写反向代理的看家本领反向代理最基础的能力就是“按规则路由”。同样一个域名/api/前缀的请求转发到后端A集群/web/前缀的请求转发到静态资源服务这就是典型的路径级路由。它能做到的还不止这么简单改写URL把前端友好的路径改写成后端真实接口路径改写请求头注入用户真实IP、附加内部认证信息、设置超时时间改写响应头统一增加安全响应头比如X-Content-Type-Options请求体限制在入口直接拦截超大请求体避免后端被拖垮。举一个日常的例子假设前端需要调用/api/user/profile而后端服务实际暴露的接口是/user-service/v2/user/profile反向代理可以通过一行rewrite指令把它转换过来。这样做的好处是后端无论怎么改内部路径、怎么拆服务对外暴露的接口契约可以保持稳定。4.2 反向代理与负载均衡的实际分工在同一套Nginx配置里可能同时出现反向代理和负载均衡的段落。举个例子upstream backend_cluster { server 10.0.0.11:8080 weight3; server 10.0.0.12:8080 weight1; server 10.0.0.13:8080 backup; } server { listen 443 ssl; server_name api.example.com; location /api/ { proxy_pass http://backend_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }upstream段定义了一个后端集群配了加权轮询还设置了一个备份节点这段就是在做负载均衡而server里对/api/路径的转发、设置请求头、做证书卸载这是标准的反向代理职责。两段协作完成整个入口能力。理解这个组合关系就能明白为什么很多人说“Nginx是反向代理和负载均衡一体化的最典型例子”了。4.3 入口网关的隐藏能力安全与性能的统一收口反向代理还有一个容易被忽视的价值——它是安全策略和性能策略的天然收口位置。入口处可以做IP黑白名单、单IP限流、全局限流这个位置做拦截成本最低因为请求还没触达业务逻辑。性能层面TLS证书统一在这里卸载后端服务只需要处理HTTP明文流量减少了后端的加密开销。HTTP/2、HTTP/3的协议升级也在这一层完成后端完全不用关心。我之前给某团队做架构梳理时发现他们的网关层居然把超时时间设成了默认60秒而下游某个数据分析接口偶尔需要跑两分钟导致大量请求在网关超时被切断后端任务还在继续跑产生了不少脏数据。把超时时间改为可配置、按接口差异化设置之后问题才解决。这一类问题最能体现反向代理“入口统一管控”的价值也最容易因为配置不当而坑到业务。5. 实战演示三台容器搭出一条真实的流量链路理论知识说得再多不如亲手把链路搭一遍。下面这套演示用Docker Compose在本地拉起三个角色一个模拟CDN边缘节点用本地Nginx加缓存模块实现、一个负载均衡层同样用Nginx但只做转发分发、两个后端应用服务器分别监听不同端口。整体拓扑是请求 → CDN边缘节点 → 负载均衡 → 后端服务A/B。这个演示核心是观察“请求经过每一层后发生的变化”而不是追求生产级别的性能。所有配置以“能跑通、能看到效果”为准。5.1 准备三个容器的编排文件先建立一个项目目录比如edge-demo。目录里包含docker-compose.yml、nginx-cdn.conf、nginx-lb.conf、以及两个后端服务目录。完整文件清单如下version: 3.8 services: cdn: image: nginx:1.25 container_name: mock-cdn ports: - 8081:80 volumes: - ./nginx-cdn.conf:/etc/nginx/conf.d/default.conf - ./static:/usr/share/nginx/html depends_on: - lb lb: image: nginx:1.25 container_name: mock-lb expose: - 80 volumes: - ./nginx-lb.conf:/etc/nginx/conf.d/default.conf depends_on: - app1 - app2 app1: image: nginx:1.25 container_name: mock-app1 expose: - 80 volumes: - ./app1:/usr/share/nginx/html app2: image: nginx:1.25 container_name: mock-app2 expose: - 80 volumes: - ./app2:/usr/share/nginx/html这里的cdn服务就是模拟的CDN边缘节点lb是负载均衡层app1和app2是两个后端节点。为了保证演示清晰三个角色各自使用独立的配置文件互不掺和。5.2 配置负载均衡层观察请求到底分给谁负载均衡层的配置如下upstream app_cluster { server app1:80; server app2:80; } server { listen 80; server_name localhost; location / { proxy_pass http://app_cluster; add_header X-Backend-Server $hostname always; } }后端两台容器返回的响应里通过add_header追加了一个响应头X-Backend-Server这个头会告诉我们是哪台容器返回了内容。启动后多刷新几次页面能看到响应头里X-Backend-Server的值在mock-app1和mock-app2之间交替变化这就是轮询效果的可视化验证。为了让负载均衡的观察更直观可以给两台后端容器放不同的内容app1的页面显示“APP1实例”app2显示“APP2实例”。浏览器反复刷新就能看到内容在两个实例间切换。5.3 配置模拟CDN边缘节点观察缓存命中与回源CDN边缘节点配置文件如下proxy_cache_path /var/cache/nginx levels1:2 keys_zoneedge_cache:10m max_size100m inactive60m; server { listen 80; server_name localhost; location / { proxy_cache edge_cache; proxy_cache_valid 200 10m; proxy_cache_key $host$request_uri; proxy_pass http://lb:80; add_header X-Cache-Status $upstream_cache_status always; } }这个配置做了两层事情定义了本地磁盘缓存路径和缓存区keys_zoneedge_cache:10m就是给缓存元数据划分了一块10MB的内存区当请求打到这个边缘节点时先查缓存没有就转发给负载均衡层proxy_pass http://lb:80拿到响应后按10分钟的缓存有效期存下来并通过X-Cache-Status头暴露这次是“命中缓存”还是“回源取数据”。实际验证的时候第一次请求会看到X-Cache-Status: MISS连续刷新几次变成X-Cache-Status: HIT。这个实验虽然简单但能让你直观理解CDN命中和回源的区别。5.4 启动演示与链路验证在项目目录里执行docker compose up -d --build等所有容器都变成Up状态之后访问http://localhost:8081/看到的流程是请求进入mock-cdn它先查本地缓存未命中则转发给mock-lbmock-lb按轮询把请求交给mock-app1或mock-app2后端返回内容mock-cdn把结果缓存并返回给浏览器。用curl看响应头是最直接的验证方式curl -I http://localhost:8081/ HTTP/1.1 200 OK X-Backend-Server: mock-app1 X-Cache-Status: HIT用X-Backend-Server确认负载均衡生效用X-Cache-Status确认CDN缓存生效。这样一个最小化的链路就把三个角色的职责全部串起来了。5.5 演示之外的延伸观察把演示跑通之后还可以做两组小实验加深理解第一组关掉app1容器刷新请求会发现负载均衡层自动把流量全部转发给app2这就是健康检查保护的直观效果。docker stop mock-app1之后无需任何人工干预。第二组在CDN配置里把proxy_cache_valid调成1分钟然后修改app1里的页面内容1分钟之内刷新看到的还是旧内容超过1分钟再刷新才看到新内容。这一步能扎扎实实理解“缓存生效时间”的含义。6. 架构决策什么时候该上CDN、负载均衡、反向代理以及踩过的坑看完原理和演示最后一个问题是我的项目到底需要哪些角色这三个组件不是越多越好每加一层就多一层延迟和运维复杂度。结合我自己的经验给出一套决策路径6.1 从单机到集群再到全国分发单台服务器、域名直接解析到这台机器什么都不用加只需要在业务前面放一个反向代理处理HTTPS、日志和静态资源。Nginx或者云上的Web服务就能解决。单机扛不住了横向扩容成两台以上必须在入口加负载均衡此时Nginx的upstream配置就够了。同时把Session设计成无状态否则哈希策略解决不了宕机后的会话丢失。后端服务很多、路径区隔明显把入口代理升级成网关按路径路由到不同服务这时候反向代理的价值最为明显。静态资源多、用户分布广、跨地域访问卡顿到这一步再接入CDN把静态资源、下载内容、音视频流推到边缘节点。这套演进路径的核心思想是需求驱动组件引入不要为了用而用。6.2 实际项目中常见的几个认知坑这次讲解中我认为有三个坑最值得重点提醒第一个把负载均衡算法当成性能优化工具。大多数业务在绝大多数时候简单轮询就足够好只有后端处理能力差异大、请求时长差异大的场景才需要考虑更复杂的算法。先压测再调算法。第二个接入CDN前不检查缓存头。CDN的缓存行为受源站响应头控制如果源站所有接口都返回no-cacheCDN会形同虚设。在接入CDN前先统一静态资源的缓存头策略。第三个忽略了链路中的超时和重试设置。入口网关的超时时间、负载均衡的重试次数、CDN的回源超时这三者必须联动考虑。遇到过网关只允许3秒超时、而后端大数据接口要跑10秒的经典事故不是代码问题纯粹是链路参数没对齐。6.3 最后分享一个排查思路线上出现“访问变慢、部分用户打不开页面”这类问题时按照“客户端→DNS→CDN→入口网关→负载均衡→应用服务器”逐层看数据先看延迟出现在哪一段浏览器开发者工具的Timing面板里DNS和连接时间异常偏大大概率是CDN或DNS问题请求发出到首字节时间偏大可能是反向代理转发问题TTFB首字节时间大而整体传输不大大概率是后端处理慢。再看响应头Via头能看出是否经过CDNX-Cache-Status能看出是否命中X-Backend-Server能看出是哪台后端节点返回的。每层都加上有辨识度的响应头排查链路时能省下一半时间。不要一上来就查应用代码先把链路每一层的“证据”收集齐问题往往自己就浮出水面了。这套思路在我多次参与线上问题排查时都被证明是最省力的方案。