企业官网建设流程全解析

上个月刚把一个内外网同服部署的模拟项目X收拾完，这套架构从DNS解析到后端存储一共串了五个组件：HAProxy、DNS、Nginx、NFS、Keepalived。业务方最开始只给了一句话“要稳定、要能撑住活动流量、别老让我半夜爬起来手动切流量”，所以最终落地方案就是把入口、调度、应用、存储分别做高可用，每个层都有自己的保命手段。这篇文章就是这次项目从选型到上线压测的完整复盘，里面有配置模板，也有真实踩过的坑，适合正在搭中小型高可用Web集群、又不想一上来上K8s的同学参考。

1. 架构设计：为什么偏偏是这五个组件凑在一起

先说结论：这套组合不是“为了高可用而高可用”，而是顺着业务需求一层层倒推出来的。项目的核心诉求是读多写少、有用户上传文件、需要随时滚动升级、任何单点故障不能导致业务整体不可用。在这些约束下，HAProxy负责七层流量调度，Keepalived给HAProxy提供VIP漂移能力，DNS负责多机房或多IP入口的负载分担，Nginx集群承接实际业务请求，NFS把集群里的共享文件统一存放。五个组件各管一段，谁也替代不了谁。

1.1 业务场景与核心痛点

模拟项目X是一个典型的中小型Web业务系统，日均请求量在百万级，高峰时段集中在每天固定的两三个小时。系统里有大量静态资源，比如图片、样式表、前端脚本，也有用户上传的文件需要存储和读取。最初单机部署的阶段，架构非常简单，一台Nginx扛所有请求，文件就存在本地磁盘，后面随着流量上涨，单机CPU和磁盘IO陆续出现瓶颈，扩容又受制于“一台机器只能挂一份数据”，这才决定拆成集群。

拆集群之后冒出三个新问题：一是多台Web节点前面需要有一个统一的流量入口和分发器；二是Web节点变成多台之后，用户上传的文件不能只存某一台，否则请求落到另一台就找不到文件；三是任何一台机器宕机时，流量必须能在秒级切换到其他节点，不能等人工干预。这三个问题分别对应HAProxy、NFS、Keepalived的定位，DNS则是在集群前面再加一道“多入口调度”，让不同网络环境下的用户都能就近访问。

1.2 五个组件的分工与高可用组合逻辑

这套架构里，每一层的高可用方式是完全不同的：

选型时也纠结过：为什么不直接用LVS做四层负载？LVS性能确实比HAProxy好看，但模拟项目X的压测需求集中在HTTP层，需要按照URL做动静分流，还需要灵活的HTTP健康检查，HAProxy对这种场景更顺手。为什么不直接用Nginx做负载均衡？Nginx做负载均衡没问题，但当前业务里Nginx本身已经是后端的Web服务节点，再让生产节点兼任入口负载，职责耦合，出了问题不好定位。HAProxy单独拎出来做一层“专职调度”，日志、统计页、配置管理都更独立。

另一个实际原因是HAProxy的配置热加载和优雅重载做得非常成熟，后面做版本升级或者临时调权重的时候，不需要断开现有连接，这对线上业务非常友好。

1.3 一次请求从浏览器到落盘的完整流转

理解一个架构最好的方式是把一次请求从头走到尾。用户在浏览器输入域名后，第一步是DNS解析，把域名解析到两台HAProxy所在节点的VIP上，这里通过DNS轮询让不同用户拿到不同的入口地址。浏览器请求到达HAProxy后，HAProxy根据ACL或者默认策略，把请求转发给后端的某台Nginx。Nginx拿到请求，动态接口直接交给应用逻辑处理，静态资源和上传文件则从NFS挂载目录读取。如果用户执行了上传操作，Nginx把文件写入NFS共享目录，这样无论下一次请求落到哪一台Nginx，都能通过NFS看到同一个文件。

完整链路里有一个细节值得强调：两个HAProxy节点共享一个VIP，正常情况下VIP放在主节点上，主节点挂掉之后Keepalived通过VRRP协议让备用节点接管VIP。DNS解析到的IP一直是这个VIP，不会因为主节点切换而发生变化，这也是为什么能把DNS和Keepalived一起用——DNS解决“入口地址有多个”，Keepalived解决“同一个地址永远可用”。

2. DNS调度与Keepalived联动：入口高可用的关键细节

很多人在搭高可用时只盯着Keepalived的VIP漂移，忽略了DNS这一层才是用户访问的真正起点。如果DNS配不好，Keepalived再怎么漂移，用户拿到一个失效的IP也进不来。这一章把入口高可用的两段逻辑拆开讲清楚。

2.1 DNS多A记录轮询与TTL取舍

DNS层面的高可用核心是给域名配置多条A记录，让同一个域名解析出多个IP。在模拟项目X里，我们给入口域名配置了两条A记录，分别指向两台HAProxy节点的真实IP。正常情况下，用户会随机命中其中一条，流量天然被拆成两半。

DNS轮询的缺点是它只负责“把请求分给不同IP”，并不感知后端是否存活。如果某台HAProxy整体宕机，DNS不知道，依然会把一部分用户解析到已经失效的IP上。因此，DNS只能作为调度和冗余手段，真正的秒级故障转移必须靠Keepalived的VIP漂移完成，让两个IP实际上都能通过VIP提供服务，或者让宕机节点的IP也能被虚拟IP接管。

TTL的取舍是DNS层最容易踩的坑。TTL设太长，比如默认的600秒甚至3600秒，故障切换后大量用户的本地DNS缓存还是旧的解析结果，访问会持续失败十几分钟。设太短，比如10秒，又会让DNS服务器压力变大、查询变频繁。模拟项目X里最终把TTL设为30秒到60秒，既保证了切换速度，又不至于把DNS查询量推得太高。

2.2 Keepalived VRRP的选主流程与配置要点

Keepalived的核心是VRRP协议，它通过网络上的组播报文让同一组节点互相同步状态。每个节点都有优先级，优先级高的会成为MASTER，拥有VIP，优先级低的进入BACKUP状态等待接管。MASTER节点每隔一段时间发送VRRP广播包告诉其他节点自己还活着，如果BACKUP节点连续收不到广播，就会认为MASTER故障，然后按照优先级重新选举，由新的MASTER接管VIP。

模拟项目X里两台HAProxy节点的Keepalived核心配置如下：

global_defs { router_id LVS_HA_1 } vrrp_script check_haproxy { script "/etc/keepalived/check_haproxy.sh" interval 2 weight -20 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 10.10.20.66/24 dev eth0 label eth0:1 } track_script { check_haproxy } }

备用节点把state改成BACKUP、priority改成140或者120即可。有几个点必须保持一致：virtual_router_id在整个广播域内不能和其他组冲突，否则会发生抢VIP的严重事故；authentication的密码两端必须完全一样；advert_int广播间隔两端要一致。你可能会觉得这些细节写在文档里谁都会看，实际上真出问题的时候，十有八九就是这类“看似一致其实不一致”的小差异导致的。

2.3 检测脚本与状态切换的联动姿势

Keepalived本身只负责VIP漂移，它并不知道上层HAProxy是否还健康。如果HAProxy进程已经死了，但Keepalived还活着，VIP就不会漂移，流量被转发到一个没有监听端口的节点上，直接连接失败。所以必须给Keepalived配上检测脚本，让VRRP的优先级跟着HAProxy的健康状态动态变化。

模拟项目X的检测脚本内容很简单：

#!/bin/bash if [ "$(systemctl is-active haproxy)" = "active" ]; then exit 0 else exit 1 fi

脚本返回0表示健康，返回1表示异常。track_script配合weight -20的含义是：脚本检测失败时优先级扣20分，原来150的主节点会降到130，低于备用节点的140，于是备用节点升级接管VIP。这是一个很巧妙的设计，不要求脚本一定用kill进程这种粗暴方式，而是通过动态降低优先级完成“软切换”。

还有一个小细节容易漏：如果HAProxy绑定的是具体IP而不是通配符，VIP切换到备用节点后，备用节点的HAProxy可能因为“本地地址不存在”而启动失败或拒绝监听。最简单的规避方式就是在HAProxy配置里bind使用*:80而不是bind 10.10.20.66:80，这样VIP漂到哪台，监听就跟到哪台。

2.4 脑裂问题的预防

Keepalived集群里最怕的是脑裂，也就是主备节点同时认为自己是MASTER，同时持有VIP，导致网络里出现地址冲突和来回抢占。最常见的原因是防火墙拦截了VRRP广播包。VRRP使用的协议号是112，目的地址是组播地址224.0.0.18，不是普通的TCP/UDP端口，很多新加的防火墙规则会顺手把它拦住。

模拟项目X部署初期就遇到过几台机器上Keepalived日志疯狂输出“VRRP packet received with invalid address”，排查下来是系统防火墙默认策略拦住了VRRP组播。放行方式要根据具体防火墙环境来定，核心思路是允许目标地址224.0.0.18、协议号112的报文通过。确认放行后，两台节点的日志就干净了，主备状态恢复正常。

3. HAProxy核心配置与流量分发策略实测

HAProxy是这套架构里流量真正经过的“咽喉”，它的配置和调优直接决定集群的吞吐上限和稳定性。模拟项目X上线前对HAProxy做了三轮针对性调整，下面把最关键的几个配置点展开说。

3.1 全局参数与后端健康检查的调优

HAProxy的global段和defaults段不应该照抄模板，而是要结合机器规格和业务特征调整。模拟项目X用的均衡节点是4核8G，配置里把maxconn设为30000，启用4个线程，每个线程绑定一个CPU核心，同时把ulimit-n提到65535，避免文件描述符不够用。

global log /dev/log local0 info maxconn 30000 nbthread 4 cpu-map auto:1-4 0-3 ulimit-n 65535 defaults mode http timeout connect 5s timeout client 30s timeout server 30s option httplog option forwardfor

健康检查是最容易被低估的配置项。很多人习惯直接写option httpchk GET /，让HAProxy不断请求你的首页。这在业务低峰期没什么问题，到高峰期就糟糕了，健康检查本身会占用Web应用的处理线程，等于无形中增加了业务压力。模拟项目X的做法是后端Nginx单独放一个/health.html静态文件，健康检查只请求这个轻量页面，不触碰动态逻辑。同时把检查频率设为2到3秒一次，fall设为2，rise设为3。这样对故障的感知延迟在6秒以内，比默认的检查周期快很多。

健康检查路径这个细节普通文档不会强调，但在高峰期它就是“压垮业务的最后一根稻草”和“救命的稻草”之间的差别。你也不希望一次后端故障要等几十秒才能被负载均衡感知到，那段时间用户请求已经全部在报错了。

3.2 后端池与负载均衡算法选择

后端配置长这样：

backend nginx_servers balance roundrobin option httpchk GET /health.html HTTP/1.0 default-server inter 3s fall 2 rise 3 server web1 10.10.20.11:80 check server web2 10.10.20.12:80 check

负载均衡算法选了roundrobin而不是leastconn，原因是业务请求处理时间比较均匀，没有单个请求长时间占用的极端情况。roundrobin实现简单、调度均匀，对短连接HTTP请求非常友好。如果你的业务里有些请求特别耗时、有些特别快，可以改用leastconn，让连接数最少的节点优先接到新请求，避免慢请求堆积在某一台上。

HAProxy的后端池支持动态修改权重和状态。模拟项目X做滚动升级时，会先把某一台Nginx的权重调为0，等它处理完存量连接后再停服升级，升级完成后恢复权重，再操作下一台。这个操作不需要重启HAProxy，在线管理能力是它相比很多负载均衡方案好用的地方。

3.3 会话保持和真实客户端IP的处理

模拟项目X虽然有登录态，但会话信息本身存储在Cookie里，所以严格来说不需要强制会话保持。不过有些历史接口依赖来源IP做风控，就还是启用了stick-table。如果你也需要会话保持，可以这样配：

backend nginx_servers stick-table type ip size 200k expire 30m stick on src

真实客户端IP的透传是另一个必须处理的点。HAProxy默认会把来源IP替换成自己的IP，后端Nginx拿到的全是10.10.20.65这样的内网地址，日志和审计就没法看了。option forwardfor解决了这个问题，HAProxy会在请求头里追加X-Forwarded-For，Nginx端再通过realip_module把日志里的客户端IP替换成透传值。注意打开日志格式里的%ci变量，不然日志里依然看不到真实IP。

3.4 热加载与版本升级不中断连接

HAProxy 2.x版本之后，reload机制非常可靠。配置变更前先执行haproxy -c -f /etc/haproxy/haproxy.cfg校验语法，校验通过后再用systemctl reload haproxy触发重载。旧进程会继续处理未完成的连接，新进程慢慢接管新连接，最终完成平滑过渡。模拟项目X在整个部署周期里做过十几次配置调整，没有一次因为reload导致用户连接中断。

我个人的习惯是每次reload之后都看一眼haproxy统计页，确认前后端连接数、健康状态、队列长度都正常。统计页本身也需要配置好：

listen stats bind :8404 stats enable stats uri /stats stats realm Haproxy-Statistics stats auth admin:yourpassword

统计页平时不需要长时间开着，可以在压测和故障演练的时候临时打开，用完就关。

4. Nginx + NFS：动静分离与文件一致性的落地姿势

应用和数据这两层是整个架构里和业务耦合最深的。Nginx怎么配置、NFS怎么挂，都会直接影响业务体验。模拟项目X在后端这一层花了不少时间调参数，这里挑几个最有代表性的点讲。

4.1 Nginx配置与静态资源缓存策略

Nginx的配置比HAProxy还要细碎。第一件事是开启gzip压缩，文本类资源能压掉70%以上，带宽占用明显下降。第二件事是配置静态资源过期时间，模拟项目X对CSS、JS、图片设置了7天的expires头和Cache-Control: public，用户本地缓存命中后，根本不会请求到Nginx。第三件事是整理日志格式，加上$upstream_response_time和$request_time，方便后面分析接口耗时段落。

一个容易忽略的系数是worker进程数和worker连接数。很多默认配置是worker_processes 1，单核跑不满也扛不住；设置为auto后Nginx会自动按CPU核数启动worker进程。worker_connections建议配置为4096到8192，同时把worker_rlimit_nofile提到65535，否则高并发下会触碰到连接数上限，日志里全是“too many open files”。

4.2 NFS导出与挂载参数的实战选择

NFS服务端的导出配置需要权衡权限和便利性。模拟项目X的共享目录是/data/webapp，给Nginx网段导出，使用同步写入模式确保文件写入后其他节点立即可见。

/data/webapp 10.10.20.0/24(rw,sync,no_subtree_check)

客户端挂载参数的选择值得多说两句。模拟项目X最终用的是：

mount -t nfs -o hard,intr,rsize=1048576,wsize=1048576,_netdev 10.10.20.100:/data/webapp /data/webapp

hard模式会在NFS服务端临时不可用时不断重试，保证只要网络恢复，数据不会丢失。intr允许挂载过程中的等待可以被中断，避免进程因为NFS卡死导致彻底无法操作。rsize和wsize调大后，大文件读写的吞吐提升非常明显。_netdev保证开机时等网络就绪后再挂载，防止系统启动时因为NFS不可用卡在挂载阶段。

同步写入模式在性能上有开销，但考虑到共享目录里是用户上传文件和核心静态资源，一致性比性能更重要，这个方向不能错。

4.3 用户上传文件的权限与一致性处理

Nginx与NFS之间最常出现的是权限问题。Nginx进程通常以nginx用户运行，写入文件时属主是nginx；但不同机器上nginx用户的UID可能不一样，比如一台是1001，另一台是999，这会导致文件在一台机器上能写，在另一台机器上就提示权限不足。解决办法是把所有Nginx节点的nginx用户UID统一设置成同一个值，同时在NFS导出时不加no_root_squash，让普通用户权限映射保持正常。

模拟项目X的Nginx配置里，上传目录指向NFS挂载点下的uploads目录：

server { listen 80; root /data/webapp; index index.html; location /static/ { expires 7d; add_header Cache-Control "public"; } location /uploads/ { alias /data/webapp/uploads; client_max_body_size 20m; } }

client_max_body_size如果没有显式设置，默认只有1m，用户传一个几MB的图片就会直接报413，这是新手最容易踩的坑。

4.4 NFS单点风险与可接受的运维预案

NFS本身是单点，虽然是这套架构里性能最脆弱的环节，但对模拟项目X这种规模来说，性价比压力没那么大。大家都不喜欢单点，但分布式文件系统带来的运维复杂度、网络要求、部署成本，对一个小几十台机器的集群来说可能属于过度设计。

模拟项目X的NFS服务端做了一层RAID1磁盘阵列，降低单块硬盘故障导致数据丢失的风险，同时配置了每小时一次的rsync增量备份到另一台冷备机器。如果NFS服务端意外宕机，整个Web集群的静态资源和上传文件确实会短暂不可用，但只要服务端恢复，挂载关系会自动重建，不需要改动任何业务代码。至于完全消除NFS单点，那是下一步把存储迁到独立分布式存储时才会考虑的事。

5. 部署过程中踩过最值得写的几个坑

每个项目都有那么几个“当初要是知道就好了”的坑。模拟项目X在联调阶段和上线预演阶段踩了四个比较有代表性的问题，过程都不复杂，但排查链路值得记录，给后面搭类似架构的人一个参考。

5.1 健康检查太慢，流量先打到宕机节点

第一次做故障演练时，手动停掉一台Nginx后，HAProxy并没能像预期那样快速把流量切走。从停止Nginx到健康检查判定节点失败，竟然花了将近30秒，这在生产环境是不可接受的。排查后发现两个问题：一是健康检查间隔是默认的10秒，二是我没有显式设置fall参数，默认需要连续失败3次才会剔除，30秒就是这么算出来的。

调整方案是把inter设为3秒、fall设为2、rise设为3，故障感知时间从30秒缩短到6秒左右。同时把后端的Nginx健康检查请求改为访问/health.html，避免每次检查触发动态业务逻辑。调整后再次演练，流量在7秒内完成了所有切换，体感上已经非常接近“无感知故障转移”了。

5.2 NFS延迟导致Nginx进程D状态

上线后某段时间，Nginx日志偶尔出现请求超时，后端Nginx进程状态不稳定，top里能看到一堆进程处于D状态，也就是不可中断睡眠。排查发现是NFS服务端磁盘IO打满，导致前端请求的字面操作全部阻塞在NFS的读写上，Nginx进程无法继续处理新请求。

这个问题不能只靠调Nginx参数解决，关键在于降低每个请求对NFS的同步访问压力。模拟项目X的调整思路有三步：第一，静态资源的缓存过期时间延长到7天，让更多请求由用户浏览器和Nginx本地缓存消化，不会每次都穿透到NFS；第二，把Nginx上访问最频繁的小图标、Logo等资源同步到本地磁盘一份，不走NFS；第三，给NFS服务端增加一块SSD作为缓存层，同步写入性能有了质的提升。调整之后，D状态进程基本消失，接口响应时间恢复正常。

5.3 Keepalived的VRRP报文被本地防火墙拦截

前面章节提过这个问题，再展开说一下排查链路。模拟项目X的备用HAProxy节点一直显示BACKUP状态，但反复出现主备切换的日志，每次切换持续时间只有一两秒，VIP在主备节点之间来回跳跃。看日志发现，备用节点不断收到“VRRP packet with invalid address”的警告，这是典型的VRRP广播被防火墙拦截后的现象。备用节点收不到主节点的组播报文，开始选举自己为MASTER，但主节点又仍然活着，于是两边抢VIP。

解决方式是放行VRRP协议流量，目标地址224.0.0.18，协议号112。放行之后，两台节点的日志彻底安静了，主备状态稳定，VIP不再抖动。这个坑很有代表性，凡是用了Keepalived的机器，都应该在部署清单里加上“确认防火墙放行VRRP组播”这一项。

5.4 客户端DNS缓存导致的切换黑洞

Keepalived切换演练做得很顺利，VIP从主节点漂到了备用节点，HAProxy和后端Nginx都没有异常。但真实业务环境中依然有用户反馈“网站打不开”。排查后发现，这些用户本地DNS服务器缓存了旧IP的解析结果，而这个旧IP指向的是已经不再持有VIP的节点。

这个坑暴露了DNS方案的一个硬伤：无论TTL设多短，总有一些公共DNS或者企业DNS会无视TTL强制缓存。要彻底解决，一是把TTL尽量调短并长期维持稳定，二是如果业务有多个入口IP，尽量让每个IP都绑定VIP而不是一台宕机就整个失效。模拟项目X的最终处理是在故障切换演练后通知主要用户群刷新DNS，并准备了一个应急方案，如果切换时间窗口内出现大面积解析异常，直接通过备用域名切一套完整集群。

6. 压测与故障演练：上线前一定要做完整的验证

模拟项目X上线前花了一个周末做压测和故障演练。很多人觉得配置没问题就能上线，但真实场景下的并发、延迟、故障恢复速度，跟实验环境完全两回事，不跑一轮压测你永远不知道瓶颈在哪。

6.1 压测场景与工具选择

压测工具选了wrk和ab交替使用。wrk适合测HTTP接口吞吐，ab适合做单接口的持续并发测试。模拟项目X定义了三个核心压测场景：

• 首页场景：模拟用户访问首页，包含动态请求和少量静态资源，用来衡量整体链路吞吐。
• 静态资源场景：模拟CSS、JS、图片的读取，用来衡量Nginx与NFS的联合读性能。
• 上传场景：模拟小文件写入NFS共享目录，用来衡量写入路径的稳定性和NFS磁盘性能。

压测命令本身很简单，比如用wrk打首页：

wrk -t8 -c400 -d60s http://10.10.20.66/

关键是压测过程中的监控。压测的同时要用top、iostat、ss这些命令盯着每台机器的CPU、内存、磁盘IO、连接数，任何一项接近瓶颈都要记录下来，压测结束之后逐一优化。

6.2 故障演练清单与恢复时间统计

故障演练的核心目标不是“看系统能不能扛住”，而是量化每一次故障从发生到业务恢复需要多长时间。模拟项目X设计的演练清单包括：

每一轮演练都要记录“故障注入时间”“感知时间”“完全恢复时间”，观察有没有单点残留。比如kill掉主节点HAProxy后，备用节点的Keepalived需要在广播超时后触发选举，这个时间通常和advert_int设置挂钩，1秒的广播间隔加上2秒的检测间隔，整体在3到5秒内完成VIP接管属于正常范围。

模拟项目X的最终统计结果是：所有单机层面的故障，业务恢复时间都控制在15秒内，达到了最初“半分钟内无人干预恢复”的要求。但也暴露了NFS单点的问题，NFS服务端的故障恢复时间偏长，所以后来加了备份与快速恢复预案。

6.3 一轮调优后的效果对比

压测和调优不是一次性工作，模拟项目X前后做了三轮调优，最终形成了这样一组对比数据：

主要调优动作包括：调整HAProxy的nbthread和cpu-map、打开Nginx的gzip和静态缓存、调整NFS挂载的rsize和wsize、将健康检查频率提高、修改系统文件描述符上限。这些都不是什么高深操作，但每一项都实打实影响着吞吐。

7. 日常运维检查清单与后续演进思路

上线只是开始，真正考验架构的是后面几个月的稳定性和可维护性。模拟项目X把日常运维拆成了“每天看什么”“每周看什么”“什么时候需要动架构”三件事。

7.1 日常需要盯的指标和检查点

每天固定看一眼HAProxy统计页，确认前后端连接数没有异常堆积、节点健康状态全绿、队列长度始终处于低位。同时检查Keepalived的状态文件，确认主备角色没有频繁切换，切换次数如果突然变多，说明网络或者防火墙有异常。NFS则用df -h确认所有Web节点的挂载点都正常，配合iostat关注服务端磁盘IO是否长期高位。

日志检查也有规律。模拟项目X用日志里的状态码分布判断健康度，5xx比例如果连续超过某个阈值，就要及时看后端Nginx日志定位是业务问题还是存储问题。所有检查项都应该写进运维脚本，每天的巡检不应该依赖人工肉眼，应该用脚本把异常指标直接推送出来。

7.2 如果想继续演进该往哪走

如果模拟项目X继续发展，架构演进有几个明确方向。首先是HAProxy从双节点主备扩展到多节点，同时配合更智能的DNS分流策略。其次是NFS替换，当存储容量和性能要求超过当前NFS服务端能力后，需要评估分布式存储方案，把共享存储也变成多副本高可用。再往后就是容器化改造，把Nginx应用容器化，配合编排系统自动扩缩容，HAProxy和Keepalived的角色会被更上层的服务发现和负载均衡机制逐渐替代。

但架构演进不是越复杂越好。以模拟项目X当前的业务量级来看，五组件这套组合已经足够稳定可靠，继续演进更多是为了团队技术积累和更高的扩展可能性。

最后分享一个我自己的体会：这套架构里最容易被低估的是NFS和DNS，很多人盯着HAProxy和Keepalived调来调去，却忽略了存储的IO吞吐和DNS的TTL设置。实际上业务的文件读写路径和用户入口的解析路径，往往是压测先爆、故障先出的地方。部署任何一套高可用架构，都应该把这两层当成一等公民来对待，提前做好预案，而不是等事故来了再补救。