我在A5数据香港机房负责服务器租用托管运维，接到一位跨境电商客户的需求：他们计划在黑五促销期间，全球用户访问其独立站静态资源（图片／JS／CSS）和短视频片段时延必须做到 < 120 ms，并希望自己部署一个 CDN 边缘节点在香港，以便结合国内外客户访问。因为客户已有香港服务器（我司提供的）且拥有 CN2 优化带宽＋多 BGP 出口，也有南亚、东南亚、欧美客户，所以我们决定在香港部署 “自建 CDN 边缘节点”＋全球 DNS＋缓存同步的架构，而不是盲目依赖第三方公有 CDN，这样能够细粒度控制带宽成本、缓存策略与硬件配置。

当我抵达香港A5IDC机房时，机架里已就位“主边缘服务器”――即上述配置：EPYC 7642 + 256 GB RAM + 2TB NVMe SSD +双 10 Gbps 出口（一个为 CN2 优化、一个为国际直连），以及 BGP 多线接入。温度、风道、UPS 监控数据我都拍照了，但出于客户保密，这里不展示机房细节。

一、项目背景 & 运维现场故事化开篇

部署目标明确：

静态资源缓存：图片、JS、CSS、favicon、字体文件等
热门短视频片段预缓存／就近分发
边缘节点做负载承载，回源至香港主节点 / origin server
利用香港机房的带宽出口及海缆优势，在亚太、欧美用户访问时尽量降低 RTT
系统基础为 Debian 11，便于定制化系统内核参数、网络优化、缓存服务配置

接下来，我从硬件选型、系统调优、网络配置、CDN 软件栈、监控告警、缓存失效机制、落地部署、遇到坑及解决方法依次展开。

二、硬件与系统选型细节

硬件配置清单

系统软件基础

操作系统：Debian 11 (Bullseye)
内核建议：原生 Debian 11 内核 + 自行编译或安装最新稳定内核（如 5.x 系列）以提升网络性能
安全、监控、日志基础已先完成（见初始安全定制指南）([Zack's][2])

为什么选择这套硬件＋地点

EPYC 7642 的多核心、多线程、高缓存（L3 256 MB）结构，非常适合处理大量并发缓存请求。([Accelerator][3])
香港机房在我国跨境出海环境下承载优势明显：离中国大陆近、网络退路有 CN2 路径、又靠近东南亚、南亚海缆节点，且能快速连通欧美。利用这些带宽优势是整个方案的核心。
自建 CDN 节点可控、灵活，可以根据客户业务负载调整缓存策略、回源逻辑、带宽路由，而非只依赖第三方。
Debian 11 系统成熟、稳定、社区支持好，适合长期运维。而对缓存与网络优化也有丰富资料。

三、部署流程：从系统初始化到 CDN 架构搭建

我下面按时间顺序叙述我在机房现场操作的关键步骤及对应代码／命令。

3.1 系统初始化

登陆服务器后，我作为 root 执行基础定制：

# 更新系统
apt update && apt upgrade -y
# 添加运维用户
adduser opsadmin
usermod -aG sudo opsadmin
# 禁止 root 密码登陆，强制 key‑ssh
sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload sshd
# 安装常用工具
apt install -y vim htop iotop iftop net-tools iperf3

上述步骤基本参照了 Debian 官方或社区的初始定制建议。([DigitalOcean][4])

3.2 系统内核 &网络参数优化

为发挥香港服务器的带宽低延迟优势、满足高并发访问，我在 `/etc/sysctl.d/99‑cdn.conf` 中增加如下配置（第一意识场景：用户并发大量、TCP 半开连接、缓存回源 I/O 需求高）：

# /etc/sysctl.d/99‑cdn.conf
# 网络性能
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_syn_backlog = 80960
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535

# 文件句柄
fs.file-max = 2000000

# TCP 缓冲区
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 65536 6291456

# 磁盘 I/O 优化（配合 SSD）
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# 启用 largepages 如果需要
vm.nr_hugepages = 512

然后执行 `sysctl ‑p /etc/sysctl.d/99‑cdn.conf` 生效。理由是：高并发下 TCP 半连接、队列、文件句柄可能成为瓶颈；SSD 回源 I/O 也需控制脏页比例以免突发延迟。

3.3 存储与文件系统优化

将 2 TB NVMe 设定为 `/var/cache/cdn` 专用目录。
推荐使用 XFS 或 ext4（配合 noop 调度器或者 mq-deadline 调度器）。我这里选用 XFS，因为在大文件高速读多数场景下表现更稳。

mkfs.xfs /dev/nvme0n1
mount /dev/nvme0n1 /var/cache/cdn
echo '/dev/nvme0n1 /var/cache/cdn xfs defaults,noatime,allocsize=4m 0 2' >> /etc/fstab

将 I/O 调度器切换为 `mq-deadline`：

echo mq-deadline > /sys/block/nvme0n1/queue/scheduler

设置日志轮转与监控 I/O 延迟（使用 `iostat`, `fio` 做基准测试）。

3.4 网络带宽 &出口路由配置

由于香港机房已配备双 10 Gbps 出口：1 条 CN2 优化、1 条国际多 BGP，我在路由器/交换机上做了如下配置：

确保 BGP 多线已经启用，并配置流量策略优先国内访问走 CN2 优化线路，海外访问优先走国际直连。
在服务器内部设置IP route表，用 `ip rule` + `ip route` 来区分源地址或目的地走不同出口。
配置流量监控，使用 `iftop` 或 `vnstat` 监控接口流量、丢包、延迟变化。
在机房 IPEX 上下行测试：我使用 `iperf3` 从香港机房向美国洛杉矶节点测量10 Gbps管道，实测 RTT ≈ 120 ms，丢包 < 0.1%。这个结果给了我们信心。

3.5 CDN 节点软件栈部署

我选择的是一套“轻量 + 高效”的自建 CDN 架构：

边缘节点服务器（香港）使用 `nginx` + `ngx_cache_purge` + `microcaching` + `HTTP/2 + TLS1.3`。
回源 origin 设在香港，也是同样硬件（但后端），并且采用 `Varnish Cache` 做回源缓存/加速。参考文章 “How to Build a Self‑Hosted CDN” 说明：可使用 NGINX、Varnish、Squid 等工具。([DEV Community][5])
DNS 层面使用 GeoDNS（例如 `bind9` + 策略或者第三方 GeoDNS 服务），用户访问时根据所在地区指向最近的边缘节点（目前只有香港一个，但未来可扩展至东南亚、北美）。参考 “How to Build a CDN” 文章中提到：需至少两个区域节点 + GeoDNS。([DEV Community][6])

具体部署命令（在边缘节点）如下：

# 安装 nginx
apt install -y nginx
# 安装必要模块（基于 Debian 11 自编译或使用 apt 源提供版本）
# 修改 /etc/nginx/nginx.conf（片段）
user www-data;
worker_processes auto;
worker_rlimit_nofile 200000;

events {
    worker_connections 65535;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30;
    types_hash_max_size 4096;

    # 缓存设置
    proxy_cache_path /var/cache/cdn/nginx levels=1:2 keys_zone=cdn_cache:100m max_size=500g inactive=24h use_temp_path=off;
    proxy_cache_key "$scheme$request_method$host$request_uri";

    upstream origin {
        server origin.backend.internal:80;
    }

    server {
        listen 443 ssl http2;
        server_name cdn.example.com;

        ssl_protocols TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers HIGH:!aNULL:!MD5;

        location / {
            proxy_pass http://origin;
            proxy_set_header Host $host;
            proxy_set_header X‑Real‑IP $remote_addr;
            proxy_cache cdn_cache;
            proxy_cache_valid 200 30m;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            add_header X‑Cache $upstream_cache_status;
        }
    }
}

在 origin（香港）节点，我安装 Varnish：

apt install -y varnish
# /etc/varnish/default.vcl 示例（片段）
vcl 4.0;

backend default {
    .host = "webserver.internal";
    .port = "80";
}

sub vcl_recv {
    if (req.url ~ "\.(png|jpg|jpeg|gif|webp|mp4|css|js)$") {
        return (hash);
    }
    # 缓存规则
    return (hash);
}

sub vcl_backend_response {
    if (beresp.ttl == 120s) {
        set beresp.ttl = 30m;
    }
    if (beresp.http.Content-Type ~ "text|application/javascript") {
        set beresp.ttl = 1h;
    }
}

3.6 缓存同步机制与失效策略

由于只有一个香港节点，未来可能扩展，但当前仍需处理缓存失效、回源热点文件同步的问题。我采用如下策略：

热点资源（如促销页 JS、CSS）通过 `rsync + cron` 每 5 分钟推送到边缘节点 ` /var/cache/cdn` 目录。
对于超过 24 小时未访问的内容，自动清理机制。
利用 Nginx `proxy_cache_use_stale` 参数允许边缘节点在回源失败时仍服务缓存内容，提高可用性。
DNS TTL 设置较短（如 300 秒）以便未来扩容节点；但缓存控制头（Cache‑Control）设置为合理值（静态资源 6 小时到 24 小时）。

3.7 监控、日志与报警

使用 `Prometheus + node_exporter + nginx_exporter + varnish_exporter` 在边缘节点收集指标：请求数、命中率、回源率、延迟、缓存容量占用、SSD I/O 延迟、网络丢包率。
使用 Grafana 建立仪表盘，设定告警规则：如回源占比 > 20%、SSD延迟 > 5ms 持续超 1 分钟、网络丢包率 > 0.5%。
日志方面，启用 Nginx 的 `access_log` + `error_log`，并每日归档。也监控系统 `dmesg`、`smartmontools` 检测 SSD 健康状态。

四、在香港服务器场景下“优化带宽优势、解决全球用户访问延迟”的关键技巧

4.1 利用香港机房带宽与地理优势

香港位于东亚海缆枢纽，连接中国大陆、东南亚、南亚、欧美的 latency 相对较优。部署边缘节点于此，可减少跨洋 RTT。
配置多 BGP 出口 + CN2 优化线路，确保从中国大陆用户访问时，绕用墙控更少、丢包更低。
在 DNS 层面，将用户区域划分为“大陆／港澳／台湾”走 CN2 出口，“东南亚＋南亚”走最近机房，“欧美”同样通过香港节点直连。虽然仍有跨洋，但香港出口优化后的吞吐与带宽可支撑。

4.2 硬件配置如何发挥作用

EPYC 7642 多核高性能意味着在高并发缓存请求、TLS 卸载、回源处理上有充沛余量。实测在促销高峰（几万个并发请求）时，CPU 利用率 < 40%。
256 GB 内存使得操作系统能够大量使用页缓存，缓存服务用内存做加速而非频繁访问 SSD，从而降低 I/O 延迟。
高速 NVMe SSD 用于缓存热度资源、日志写入与回源峰值状况下高速写入需求。从机房实测读写延迟 < 0.2 ms。
双 10 Gbps 出口保证边缘节点在高并发用户访问时带宽不成为瓶颈。实际峰值出站达到 ~8.5 Gbps，仍余裕。

4.3 系统／网络参数调优总结

TCP 半开、连接追踪、keepalive、文件句柄、I/O 调度器这些“隐藏瓶颈”在高并发场景下尤为关键。
缓存服务响应快，回源少，降低跨洋访问的延迟显著：从用户角度测 RTT 时，在北美节点访问香港边缘缓存资源平均 ~180 ms（包括 TLS 握手），而直接访问原站北美回源 ~250 ms。
对于静态资源，建议使用 HTTP/2 + TLS1.3，这可减少握手延迟＋复用连接。上述 nginx 配置中已启用。
缓存命中率高能极大减少回源请求，从而提升全球访问速度。实际测得边缘命中率达 92% 以上，促销高峰期间仍能维持 ~88%。

五、表格数据支撑：部署前 vs 部署后对比

这些数据是我在实际运维促销高峰期间，从监控系统和日志中汇总的真实情况。能够说明香港服务器＋带宽＋自建 CDN 在全球访问场景下的优势。

六、现场遇到的坑 & 我如何解决

在部署过程中，我也遇到若干突发问题、几度现场“坑”来了，再分享出来给大家参考：

1.坑‑1：SSD 卡顿、高 I/O 延迟

初期监控中发现，某次促销开始时，SSD 一直处于高 I/O wait 状态，延迟从 < 0.2 ms 突变为 ~5‑8 ms，导致缓存响应变慢，回源比例跳高。排查发现是由于文件系统选用了 ext4 默认调度器（cfq），在并发大量写入日志＋缓存淘汰时竞争严重。

解决：将调度器切换为 `mq‑deadline`，改用 XFS 文件系统，日志写入分区分离到另一块 SSD，并将 `vm.dirty_ratio` 降低。经过调整后 I/O 延迟恢复 < 0.4 ms。

2.坑‑2：缓存命中率下降，回源量陡增

在某次大型促销前，我发现边缘节点的缓存命中率从 ~90%跌至 ~70%。原因是促销中新上传了一批新图片资源（带有不同 URL 参数），但 rsync 推送脚本未及时同步这些新资源到 `/var/cache/cdn`，导致边缘每次先回源取。

解决：改进推送机制，加入 inotify 监控逻辑：当 origin 上有 `/promo/2025/11/` 目录新增文件时，立即通过 `rsync --delete` 同步至边缘，并强制执行 `nginx -s reload`，确保新资源立即可缓存。促销期间，新增资源同步延迟缩短至 < 2 分钟。

3.坑‑3：带宽出口优先策略失效，部分地区延迟反高

部署初期，我配置了路由策略：大陆用户优先走 CN2 出口。但实际监控中，来自中国某省的用户延迟却比直接走国际出口还高。经分析，发现该省 ISP CN2 路径在高峰期出现丢包 +跳数异常。

解决：调整逻辑：在 BGP 路由器上加入“监控抽样路由质量”（丢包率、跳数）模块；自动切换回国际直连出口。当 CN2 路径丢包率超过 1% 时，自动 fail‑over。调整后用户实际 RTT 降至 ~130 ms，从 ~160 ms 降低。

4.坑‑4：TLS 握手高延迟

虽然缓存命中率高，但一些用户仍反映首次访问静态资源时延较高。分析发现：TLS 握手涉及香港边缘节点回源 origin，增加了回程。

解决：在边缘节点启用了 TLS 卸载 + session resumption（设置 `ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;`）并启用 HTTP/2。这样首次资源响应时间从 ~220 ms 降至 ~160 ms。

七、具体部署方法：从头到尾的步骤

1.系统初始化与配置

部署开始之前，我们需要先对服务器进行基本的操作系统初始化，包括系统更新、软件安装、用户配置、安全性设置等步骤。以 Debian 11 为例，执行以下步骤：

# 更新系统
apt update && apt upgrade -y
# 安装必要的依赖工具
apt install -y vim htop iftop iotop net-tools iperf3 curl rsync
# 添加运维用户并赋予 sudo 权限
adduser opsadmin
usermod -aG sudo opsadmin
# 配置 SSH 安全，禁用 root 用户直接登录
sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload sshd

目的：

系统更新和必要的工具安装，确保操作环境整洁和安全。
禁用 root 登录并创建独立运维用户 `opsadmin`，提高系统安全性。

2.网络调优与内核参数设置

接下来，我们进行网络参数调优，特别是在高并发场景下，网络和内核参数的优化至关重要。以下是我在这台机器上配置的部分网络调优参数：

# /etc/sysctl.d/99-cdn.conf
# 设置最大连接数
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_syn_backlog = 80960
# 启用 TCP 序列化
net.ipv4.tcp_syncookies = 1
# 设置传输层的内存
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 65536 6291456
# 启用更高效的磁盘 I/O 设置
vm.swappiness = 10
vm.dirty_ratio = 15

目的：

增加系统的最大连接数和网络缓冲区，减少 TCP 连接的延迟。
使用低内存交换空间，保证 SSD 的高速读写。
调整网络带宽，以适应 CDN 大流量的传输需求。

执行以下命令使其生效：

sysctl -p /etc/sysctl.d/99-cdn.conf

3.存储优化与文件系统设置

对于高效的缓存与静态资源管理，存储的优化不可忽视。将缓存设置为专用磁盘并使用高效的文件系统（如 XFS）是我们的选择。首先，我对 NVMe SSD 进行格式化和挂载：

mkfs.xfs /dev/nvme0n1
mount /dev/nvme0n1 /var/cache/cdn
# 修改 /etc/fstab 使系统启动时自动挂载
echo '/dev/nvme0n1 /var/cache/cdn xfs defaults,noatime,allocsize=4m 0 2' >> /etc/fstab

目的：

使用高性能的 NVMe SSD 存储缓存数据，避免 I/O 瓶颈。
通过 XFS 文件系统的支持，进一步提高缓存性能，减少写延迟。

4.Nginx 与 Varnish 配置

为了提高静态资源的分发效率，我们采用了 `Nginx` 和 `Varnish` 的联合架构。Nginx 作为反向代理服务器，用于缓存和加速静态资源，而 Varnish 则负责更精细的缓存策略与回源管理。

Nginx 配置：

# /etc/nginx/nginx.conf
worker_processes auto;
worker_connections 65535;
multi_accept on;
http {
    # 启用缓存
    proxy_cache_path /var/cache/cdn/nginx levels=1:2 keys_zone=cdn_cache:100m max_size=500g inactive=24h use_temp_path=off;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    server {
        listen 443 ssl http2;
        server_name cdn.example.com;
        ssl_protocols TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers HIGH:!aNULL:!MD5;

        location / {
            proxy_pass http://origin;
            proxy_cache cdn_cache;
            proxy_cache_valid 200 30m;
            proxy_cache_valid 404 1m;
            add_header X-Cache $upstream_cache_status;
        }
    }
}

Varnish 配置：

# /etc/varnish/default.vcl
vcl 4.0;
backend default {
    .host = "origin.backend.internal";
    .port = "80";
}

sub vcl_recv {
    if (req.url ~ "\.(png|jpg|jpeg|gif|webp|css|js)$") {
        return (hash);
    }
}

sub vcl_backend_response {
    set beresp.ttl = 30m;
    if (beresp.http.Content-Type ~ "text|application/javascript") {
        set beresp.ttl = 1h;
    }
}

目的：

Nginx 用于反向代理与负载均衡，结合缓存机制提高资源分发速度。
Varnish 强化缓存管理，通过精细化配置缓存过期策略，最大化提升命中率。

5.部署 CDN 与 DNS 配置

对于全球用户访问优化，我们使用 `GeoDNS` 来智能路由用户流量，将用户流量指向离他们最近的 CDN 节点。这一过程通过第三方 DNS 提供商实现，结合地理位置信息调整 DNS 解析：

# 配置 GeoDNS 路由策略：将大陆用户指向 CN2 优化线路，其他地区通过国际直连出口
# 配置示例为 DNS 解析权重设置：大陆地区优先 CN2，海外地区使用国际直连

目的：

通过 DNS 层级的路由，动态分配流量至最优的 CDN 节点。
确保每个区域的用户能够连接到距离自己最近的节点，减少跨国访问的 RTT。

6.监控与报警配置

为了保障 CDN 服务的稳定性与实时性，我在服务器上配置了 Prometheus + Grafana 的监控平台，并设置了多项告警规则：

# 安装 Prometheus 和 Nginx exporter
apt install -y prometheus nginx-prometheus-exporter
# 配置 Prometheus 收集 Nginx 与 Varnish 的指标数据

Grafana 配置好仪表盘后，我设置了以下关键告警规则：

当回源延迟大于 500ms 时，触发告警。
缓存命中率低于 70% 时，告警提醒。

目的：

通过实时监控和告警，及时发现性能瓶颈或故障。
避免长时间的服务停滞，确保用户体验。

八、部署前后性能对比表

九、遇到的坑与解决方案

1.I/O 延迟问题

初期，我发现系统偶尔出现 I/O 卡顿，影响了缓存写入和读取速度。问题出在 SSD 存储的调度器选择上，`cfq` 会导致大量写入时的延迟波动。改为 `mq-deadline` 后，I/O 延迟显著降低。

2.缓存命中率下降

在某些特殊的促销页面上，Varnish 的缓存策略没有及时同步新内容，导致回源请求大幅上升。通过调整 `rsync` 推送策略，并使用 `inotify` 实时同步新的缓存文件，解决了这一问题。

十、总结 &推广建议

作为运维现场亲历者，我总结如下几点：

• 在香港部署边缘 CDN 节点，结合本地带宽优势、海缆位置优势，对亚太 +欧美用户访问均有显著好处。
• 硬件配置（如 EPYC 7642 + 256 GB RAM + NVMe SSD）为高并发服务提供充裕保障。
• 系统／网络参数必须提前调优、高并发场景才不“爆表”。
• 缓存命中率、出口路由质量、SSD I/O 延迟是关键指标，必须部署监控机制。
• 自建 CDN 虽然起步投入高于“直接用第三方 CDN”，但对客户“跨境电商＋独立站＋促销高峰”这种场景更有可控性、成本优化空间、性能调优空间。