那是上个月的一个深夜，我们为一位金融客户部署在香港的高防节点突然报警。短短几分钟内，接近300Gbps的UDP flood流量蜂拥而至，服务器硬抗了第一波之后，尽管高防线路暂时稳住了带宽，但我发现I/O延迟急剧上升，SSD写入速率出现异常抖动，整个系统的日志服务、数据库同步、缓存持久化都受到了影响。

作为架构负责人，我一度以为是高防系统未能清洗干净TCP层的连接，直到深入追查才发现：虽然流量清洗做得不错，但攻击引发的异常连接、日志大量写入和无效写入行为，最终还是压垮了SSD I/O性能。这让我开始重新审视“架构层面”如何彻底分离攻击流量与磁盘写入行为，实现真正意义上的软硬隔离。

以下，是我走过的坑、试验的策略和最后稳定运行的方案。

一、问题背景：为何仅靠高防还不够？

高防服务器本质是通过带宽和清洗设备来抵御流量攻击（如SYN Flood, UDP Flood, DNS Amplification等）。但很多人忽视了以下几个现实：

• 高防清洗只处理数据包层面，但无法阻止攻击引发的系统资源消耗（例如日志大量写入、连接堆积）。
• 系统默认配置中，大量异常连接或超时请求仍会触发应用层日志、Nginx访问日志、系统审计日志等，最终导致磁盘I/O暴增。
• SSD在应对持续高并发写入时容易进入GC（垃圾回收）循环，甚至触发TRIM失效，影响正常请求的数据读取。

所以，我们的目标很明确：

架构上必须实现攻击流量与磁盘写入路径的隔离，避免攻击引发的写入行为干扰核心业务磁盘I/O。

二、整体架构设计思路

下图是我最终确定的系统架构分离策略（文字版说明）：

┌───────────────────────┐
│   香港高防入口服务器     │（Layer 3 清洗/ACL）
└────────┬──────────────┘
         │
         ▼
┌───────────────────────┐
│     HAProxy / LVS      │（负载均衡 + TCP连接隔离）
└────────┬──────────────┘
         │
         ├───→ 连接池+限速模块（IPtables + conntrack + BPF）
         │
         ▼
┌────────────────────────────┐
│       应用层网关 Nginx       │
│  - 日志写入分离 (tmpfs)       │
│  - 攻击请求 444 断链          │
│  - 请求频控+Bot识别           │
└────────┬──────────────┘
         │
         ▼
┌────────────────────────────┐
│  应用服务容器（Docker / Pod）│
│  - SSD读写分区隔离（IO cgroup）│
│  - 高速读写日志挂载内存盘      │
│  - 后台数据批处理异步写入      │
└────────────────────────────┘

三、关键技术实现与调优细节

1. 临时日志转储：使用 tmpfs 挂载分区隔离写入

问题：Nginx、PHP-FPM 的访问/错误日志在遭受攻击时会大量写入磁盘，压缩写入队列。

方案：

mkdir /mnt/logtmp
mount -t tmpfs -o size=512M tmpfs /mnt/logtmp
ln -s /mnt/logtmp/nginx_access.log /var/log/nginx/access.log

效果：大幅降低 SSD 写放大，攻击流量不会写入磁盘，而是保存在内存文件系统中。

2. 内核层连接跟踪限制 + SYN 限速

# 限制每个IP最多保持50个连接
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j DROP

# SYN flood 基础限速
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT

3. SSD I/O 保护：使用 cgroups + blkio 做 I/O 控制

设置 Docker 容器对磁盘的最大读写速率：

docker run --device-write-bps /dev/sda:2mb --device-read-bps /dev/sda:5mb ...

同时限制系统级日志服务的写入优先级，防止和业务争抢 SSD I/O。

4. 攻击请求“短路”：使用 Nginx 返回 444 并跳过日志

map $http_user_agent $log_ua {
    default         1;
    ~*curl          0;
    ~*python        0;
}

server {
    access_log /var/log/nginx/access.log combined if=$log_ua;

    if ($request_uri ~* "(wp-login|xmlrpc|\.env)") {
        return 444;
    }
}

5. 高防日志分区和业务数据分区物理分离

如果使用 NVMe SSD，建议：

• /var/log 与 /data 业务挂载在不同 SSD。
• /tmp、日志缓存走 tmpfs 内存盘。
• 使用 RAID10 或 ZFS 做块级隔离。

四、实际效果评估：I/O 抖动显著降低

通过对比攻击前后一周的数据：

五、高防不只是带宽游戏，系统架构才是真正的战场

经历这次事件，我深刻体会到：高防不仅是带宽和清洗设备的堆叠，更重要的是系统架构是否能“免疫攻击副作用”。攻击流量最终可能不会直接让服务器宕机，但如果间接引起日志风暴、SSD过热、I/O堆积，业务也会被拖垮。

我的建议是：

• 应用级架构必须做流量行为隔离设计；
• 日志策略和磁盘策略需要动态应变；
• 结合防火墙 + 系统内核参数 + 用户态策略做“闭环防护”。

愿我的经验对你在部署香港高防服务器架构设计时有所启发。如果你也经历过类似的挑战，欢迎交流，我们技术人都是从“掉坑”开始成长的。