那天凌晨 2:17，Grafana 报警把我从床上拽起来：Checkout P95 > 5.2s（SG、MY、TH 全线飙红）。客服群里同时在刷屏，“结算页卡住，货到付款按钮点不动”“信用卡支付转圈 10 秒以上”。

我们的网站部署在香港机房（低时延辐射华南与东南亚），按理说 SG/马来 过来 40~70ms RTT，怎么会在结算页崩成这样？

我 SSH 到边缘 LB，看了两眼 Nginx 的 $upstream_response_time 和 HAProxy 的Tq/Tw/Tc/Tr，心里有数了：不是单点慢，是链路里有“慢变量”。我们得把问题掰开来，逐层掀盖板。

现状与目标

业务与流量画像

• 用户：东南亚为主（SG/MY/TH/VN/ID/PH），移动端占 78%。
• 核心路径：/cart → /checkout → /payment(第三方) → /order-confirmed
• 依赖：风控（大陆节点）、货币汇率（SG 节点）、税费查询（VN 节点）、短信 OTP（MY、ID 本地通道）。

香港机房与硬件

痛点 KPI（事发当夜）

目标：把东南亚核心国家 P95 降到 <2.0s，支付回调失败率 <0.3%。

诊断：从页面到内核，一层层“剥洋葱”

1）浏览器与前端水位

• PerformanceNavigationTiming 显示 TLS 握手耗时 ≈ 220~300ms，HTTP/1.1 多连接建连密集。
• 静态资源没问题（CDN 命中 98%），卡在结算页的 XHR 链。

发现两个关键 XHR：

• /risk/verify（同步阻塞渲染）→ 目的地在大陆华东，抖动大；
• /pricing/tax（同步）→ 目的地在越南，稳定但偶尔长尾。

2）边缘与 LB（Nginx/HAProxy）

• HAProxy Tc（TCP 连接时间）在 SEA 正常，Tr（服务器响应）拉长。
• Nginx 的 $upstream_connect_time 对 risk 接口显著偏高（>400ms），明显跨境链路问题。

3）应用与数据库

APM（Jaeger + OpenTelemetry）：coupon 校验链路出现 200~400ms 的慢查询峰，coupon_usage表缺组合索引（coupon_id, user_id, status）。

PHP-FPM 的pm.max_children不够（QPS 峰值时阻塞），Node.js 对第三方 API 没做熔断与退避。

4）网络链路

MTR（香港机房 → 华东风控）：绕行至公网骨干再回，RTT 直逼 220~350ms，且抖动明显。

我们虽然在香港，但访问大陆依赖时如果不走 CN2 三网直连，长尾会吃满。这正是“东南亚用户卡在跨境依赖”的典型场景。

改造方案（分层落地）

A. 操作系统与内核网络栈（CentOS 7）

1）升级内核开启 BBR（CentOS 7 默认内核太旧）

# 仅示例：线上先在灰度机器验证稳定性再全量
sudo yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
sudo yum --enablerepo=elrepo-kernel install -y kernel-ml
sudo grub2-set-default 0 && sudo reboot
# 重启后：
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -p

2）TCP/TLS 优化

cat >/etc/sysctl.d/99-tune.conf <<'EOF'
net.core.somaxconn=1024
net.ipv4.ip_local_port_range=10240 65535
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 65536 134217728
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_mtu_probing=1
EOF
sysctl --system

说明：BBR 对长肥管道和抖动链路收敛效果好；mtu_probing能减少路径 MTU 不一致导致的重传。

B. CN2 三网直连的接入与路由策略

核心思路：

• 东南亚 → 香港 走本地优质运营商（PCCW/HGC）以缩短访问我们站点的 RTT；
• 香港 → 大陆依赖（风控/短信回落）强制经 CN2（CT/CU/CM 三网直连），把跨境长尾压掉。

我们做了两件事：

• 和香港的上游拿了 CN2（CT GIA/ CU AS9929/ CMI AS58453）三网直连的专线/通道，在边缘路由器上根据目的网段策略路由：
• 目的地在华东/华南的风控网段 → 走 CT/CU 优先；
• 国内移动系网段 → 走 CMI；
• 其余默认 → HGC/PCCW（SEA 方向）。

对关键依赖（风控）做IPSec/GRE 隧道兜底，固定下一跳为 CN2 出口，避免 BGP 抖动引起的路径漂移。

这里不贴 BGP communities 的具体值（各上游不同），但思路是基于目标前缀做 Policy-Based Routing，把“去哪儿”的决定握在自己手上。

C. LB 与 TLS/HTTP 升级（Nginx + HAProxy）

Nginx 终 TLS + HTTP/2/3，OCSP Stapling，Session Resumption：

# /etc/nginx/conf.d/ssl.conf（片段）
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:...';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 10m;
ssl_session_tickets off;   # 避免会话票据泄漏风险
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

# HTTP/2 + HTTP/3（QUIC）
listen 443 ssl http2;
listen 443 quic reuseport;   # 1.25+ 支持
add_header Alt-Svc 'h3=":443"; ma=86400';

上游超时与连接重用：

proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_connect_timeout 2s;
proxy_send_timeout 15s;
proxy_read_timeout 30s;
keepalive_timeout 65s;
keepalive_requests 10000;

HAProxy（边缘 2 层七层混合）：

# /etc/haproxy/haproxy.cfg（片段）
defaults
  timeout connect 3s
  timeout client  30s
  timeout server  30s
  option http-keep-alive

backend app_nodes
  balance leastconn
  option httpchk GET /healthz
  server app1 10.0.1.11:8080 check maxconn 800
  server app2 10.0.1.12:8080 check maxconn 800

关键点：TLS 1.3 + 会话复用显著降低 SEA 移动端的握手开销；HTTP/3 对弱网下的丢包恢复更友好（但要做 H2 回退）。

D. 应用层：解耦“跨境慢变量”，加熔断与缓存

1）Risk 验证改为异步＋降级

结算页不再同步阻塞等待风控；改成后置校验（下单前最终核验）+ 前置快速校验缓存。

为所有外部依赖加 熔断（circuit breaker）、指数退避重试、超时统一（<800ms）。

Node.js（Nest/Fastify）示意：

// circuit.ts
import CircuitBreaker from 'opossum';

const riskRequest = async (payload) => {
  const res = await fetch(RISK_URL, { method:'POST', body: JSON.stringify(payload), timeout: 800 });
  if (!res.ok) throw new Error(`risk ${res.status}`);
  return res.json();
};

export const riskBreaker = new CircuitBreaker(riskRequest, {
  timeout: 900, errorThresholdPercentage: 50, resetTimeout: 10000,
});

// 调用处：先读本地缓存，命中则快速放行，未命中走 breaker

2）汇率/税费：增加 Redis 缓存与“看门狗刷新”

新增 Key：fx:rate:<ccy> TTL 120s，命中率 >95%。

税费根据 SKU+地区 做细粒度缓存，TTL 300s，后台异步刷新。

3）前端优化

结算页移除阻塞性脚本，对第三方 JS 统一 defer，关键路径只保留 2 个同步 XHR；

preconnect 到支付域名，dns-prefetch 到风控域名；

尽量 SSR 首屏组件，减少水合阻塞。

4）PHP-FPM & Node 资源池（CentOS 7）

; /etc/php-fpm.d/www.conf（片段）
pm = dynamic
pm.max_children = 80
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
; 慢日志
request_slowlog_timeout = 1s
slowlog = /var/log/php-fpm/slow.log

Node 侧用 pm2 启多进程 + keep-alive agent 减少上游建连。

E. 数据库：索引与事务边界

问题 SQL（简化）：

SELECT id FROM coupon_usage
WHERE coupon_id = ? AND user_id = ? AND status = 'UNUSED'
ORDER BY created_at DESC LIMIT 1;

缺乏组合索引导致回表与 filesort。

修复：

ALTER TABLE coupon_usage
  ADD INDEX idx_coupon_user_status_created (coupon_id, user_id, status, created_at);

参数与池化：

# my.cnf（片段）
innodb_buffer_pool_size=160G
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=4G
max_connections=2000

事务要短小，把与外部 API 的交互从事务外移，避免锁等待撑大尾部。

F. 可观测与回归保障

• APM 采样率从 3% 提至 10%，专盯 /checkout 链；
• Nginx var log输出 $request_time $upstream_connect_time $upstream_response_time $ssl_protocol $ssl_cipher;
• k6/wrk 压测：压混合流量（移动端 UA + 80% H2/20% H3），对灰度与全量分别测；
• 合规：严格屏蔽结算页缓存用户数据；0-RTT 只对白名单 GET 开启。

关键配置与脚本（可直接参考）

Nginx（结算页后端 upstream 与缓存策略）

upstream app_backend {
    zone app_backend 64k;
    keepalive 256;
    server 10.0.1.11:8080 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=2 fail_timeout=10s;
}

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

    location /checkout {
        proxy_pass http://app_backend;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Request-Id $request_id;
        proxy_read_timeout 30s;
    }

    # 静态资源强缓存
    location /assets/ {
        expires 7d;
        add_header Cache-Control "public, max-age=604800, immutable";
        try_files $uri =404;
    }
}

HAProxy（对外健康检查与慢后端摘除）

backend risk_outbound
  mode tcp
  option tcp-check
  tcp-check connect
  server risk1 203.0.113.10:443 check fall 2 rise 3 inter 2000
  server risk2 203.0.113.11:443 check backup

Redis（结算页学名“热点 KV”）

# redis.conf（片段）
maxmemory 48gb
maxmemory-policy allkeys-lru
tcp-keepalive 60

MTR/路由观察脚本（简化）

#!/bin/bash
targets=("risk.example.cn" "sms.my.example" "tax.vn.example")
for t in "${targets[@]}"; do
  echo ">>> $t"
  mtr -rwzbc 20 $t | tail -n +2 | awk '{printf "%-40s %s\n", $2, $8}'
done

上线与结果

我们用金丝雀发布：先 10% 流量（SG/MY），观察 1 小时，再 50%，最后全量。上线后的 7 天指标：

指标对比（P95）

核心收益来自两点：

1）CN2 三网直连把香港→大陆依赖的跨境长尾砍了；

2）应用解耦 + 熔断 + 缓存把“慢变量”从主链路中挪走。

坑与避坑清单（都是血泪教训）

1. HTTP/3 与部分支付网关回调：有的网关回调端不支持 H3，Nginx 需要确保 H2 回退且 server_tokens off，避免兼容性探测失败。
2. 0-RTT：只对白名单 GET 开；结算页涉及敏感信息与幂等性，POST 禁止 0-RTT。
3. CN2 通道容量：别只看平均 RTT，看 95/99 分位；并发峰值下注意带宽承诺（CIR），否则尖峰还是会丢包。
4. DNS 解析：移动端运营商 DNS 有时会“聪明”地给你奇怪答案；我们把关键依赖域名改为固定 A/备用 SVC，并在应用里做IP 直连兜底（仅应急）。
5. PHP-FPM 阻塞：忘了调 pm.max_children 就会在峰值把你卡住；配合 慢日志抓热点。
6. MySQL 索引顺序：组合索引里的列顺序要按过滤性与排序来排；别把 created_at 放前面。
7. Redis key 爆炸：税费缓存维度太细会内存爆炸；我们对 SKU 分桶，结合 LRU 与 TTL 叠加。
8. 策略路由回环：PBR 配错会导致回环或不对称路由；上线前用 tracepath 双向验证。
9. 日志脱敏：结算链路日志务必脱敏（卡号、地址、电话），同时保证可观测字段齐全（request_id、trace_id）。
10. 黑白名单：风控降级不是放飞自我。我们做了地域 + 账户画像的限权降级策略，降低风控放松带来的风险。

复盘与可复用的“打法”

如果你也把跨境电商放在香港，需要解决东南亚结算页卡顿，可以按这条路径走：

先测出来：前端 RUM + APM + $upstream_*_time，定位“慢变量”属于哪里（跨境依赖？数据库？TLS？）。

把跨境慢变量“隔离”：

• 业务上：异步化、熔断、缓存、幂等；
• 网络上：CN2 三网直连用于 HK↔大陆，SEA 走本地优质出口；必要时对关键域名做固定隧道。

把握细节：TLS 1.3、会话缓存、HTTP/2/3 回退、BBR、内核与 socket 参数、索引顺序、FPM/Node 池。

保留回滚与兜底：金丝雀发布、特征开关、回滚脚本、熔断默认值、安全阈值报警。

上线后一周，我们赶上地区大促。零点一到，在线人数飙了 3 倍。
Checkout P95 1.8s 稳稳地贴着横线，支付回调也没再报警。客服群出奇安静，运营在群里发了杯奶茶的表情。我把监控面板截了个图，给团队里每个人都发了一份。

老实说，这些优化没有“银弹”。是把网络、系统、应用、数据库每一层的螺丝都拧紧了一圈，尤其是CN2 三网直连把跨境依赖的“慢变量”给按住了。
如果你也在香港为东南亚做电商，愿这篇能给你一个可落地的样板。出了新坑，也欢迎来交流，我们继续一起填