环境初始化与安装
在受限的网络环境中，我们通常需要提前下载好对应架构的二进制文件进行离线安装。
首先，初始化目录结构并分配执行权限： 我们创建了专门的应用程序、配置和日志目录，并将上传好的 Linux amd64 版本二进制文件进行重命名和赋权。
# 初始化目录 mkdir -p /app/imadc/toxiproxy/{app,conf,logs} # 简化文件名并赋予执行权限 mv /app/imadc/toxiproxy/app/toxiproxy-server-linux-amd64 /app/imadc/toxiproxy/app/toxiproxy-server mv /app/imadc/toxiproxy/app/toxiproxy-cli-linux-amd64 /app/imadc/toxiproxy/app/toxiproxy-cli chmod +x /app/imadc/toxiproxy/app/toxiproxy-server chmod +x /app/imadc/toxiproxy/app/toxiproxy-cli紧接着，创建代理规则配置文件config.json。这里的目标是将本地18092端口的流量接管，并代理转发至真实的后端 API 端口8092（命名为api_slow）。
[ { "name": "api_slow", "listen": "0.0.0.0:18092", "upstream": "127.0.0.1:8092", "enabled": true } ]注：实际微服务架构中，我们会根据依赖项配置多个代理节点（例如配置
redis_slow代理 6379 端口，配置api_slow代理 8092 端口等）。为了行文与演示方便，本文后续的各个延迟注入场景，将统一在api_slow这个代理节点上进行逻辑复现。
二、 服务启停脚本配置
为了便于日常维护，我们需要编写标准的启停脚本，并将 CLI 工具链加入到环境变量中。
1. 启动脚本 (start.sh)
启动脚本使用nohup将 Toxiproxy Server 挂载至后台运行，监听8474控制端口，并输出日志。同时，脚本会精准捕获进程号并写入toxiproxy.pid文件中。
#!/bin/bash cd /app/imadc/toxiproxy nohup ./app/toxiproxy-server \ -host 0.0.0.0 \ -port 8474 \ -config ./conf/config.json \ > ./logs/toxiproxy.log 2>&1 & echo $! > ./toxiproxy.pid echo "Toxiproxy started with PID $(cat ./toxiproxy.pid)"2. 停止脚本 (stop.sh)
停止脚本优先判断 PID 文件是否存在，若存在则精准终止进程并清理残留的 PID 文件。若文件丢失，则降级使用pkill根据进程名进行批量清理。
#!/bin/bash cd /app/imadc/toxiproxy if [ -f ./toxiproxy.pid ]; then PID=$(cat ./toxiproxy.pid) kill $PID && echo "Toxiproxy (PID $PID) stopped." rm -f ./toxiproxy.pid else echo "No PID file found. Attempting to kill by name..." pkill -f "toxiproxy-server" fi环境配置提示：配置完成后，强烈建议将工具路径追加至
~/.bashrc中 (export PATH=$PATH:/app/imadc/toxiproxy/app)，以便在任意路径下全局调用toxiproxy-cli命令。
三、 核心概念：Upstream 与 Downstream
Toxiproxy 注入故障时，方向的选择至关重要。理解这两个维度的差异，才能精准还原实际生产中的网络拓扑故障。
- Upstream（上游注入）：延迟发生在“请求期”。客户端发出请求后，Toxiproxy 先将请求挂起等待指定时间，然后再将请求放行给对端服务。这种模式常用于测试客户端的连接超时（Connect Timeout）或是服务端针对慢请求的拥塞控制。
- Downstream（下游注入）：延迟发生在“响应期”。流量正常进入对端服务，对端服务也正常处理完毕，但在数据包返回给客户端之前，被 Toxiproxy 强行拦下并挂起指定的时间。这种模式常用于测试客户端针对长耗时响应的读超时（Read Timeout）断开与断路器逻辑。
四、 短信网关场景延迟注入实操
服务启动后，我们可以先通过curl -s http://localhost:8474/proxies检查代理列表是否正常加载。确认无误后，即可开始注入混沌以验证业务逻辑。
场景一：模拟外部缓存网络抖动（Upstream 注入）
频控的核心是时间窗口计数，通常强依赖 Redis 的原子操作。如果 Redis 发生网络拥塞，网关的兜底策略至关重要：是触发降级放行（保障核心验证码送达），还是阻断拦截（防止短信轰炸）？
我们可以在网关与缓存的链路上注入上游延迟。追加-u（即--upstream）参数，即可精准模拟客户端向后端发起请求时的阻塞：
# 注入 30 秒的上游延迟 toxiproxy-cli toxic add -t latency -a latency=30000 -u api_slow # 验证结束后恢复链路 toxiproxy-cli toxic remove -n latency_upstream api_slow验证目标：观察网关客户端能否精准触发连接超时异常，并进入预设的降级放行/阻断拦截 Fail-safe 流程。
场景二：内部风控接口超时（Downstream 注入）
除了基础频控，网关还需要调用内部其他微服务（如黑白名单校验、画像风险评估）。如果这些接口变慢，极易耗尽网关的主线程池。我们给api_slow节点注入长达 30 秒（30000 毫秒）的下游延迟，模拟对端处理缓慢的情景。
注入命令：可以通过 CLI 添加（注意 CLI 参数顺序，选项参数必须在代理名称之前），或者通过 REST API 添加。
# 使用 CLI 工具 toxiproxy-cli toxic add -t latency -a latency=30000 api_slow # 或者使用 HTTP 请求动态注入 curl -X POST http://localhost:8474/proxies/api_slow/toxics \ -H "Content-Type: application/json" \ -d '{"name":"slow_30s","type":"latency","stream":"downstream","toxicity":1.0,"attributes":{"latency":30000}}'此时通过time curl -s -o /dev/null http://localhost:18092/验证，可以看到请求会精准耗时约 30 秒。
恢复链路：
toxiproxy-cli toxic remove -n latency_downstream api_slow验证目标：测试断路器能否在达到慢调用比例阈值后迅速熔断，保护主业务线程池不被拖垮。
场景三：高并发临界点与竞态条件测试
在 UAT 环境中，很难徒手构造出极端的并发请求来测试频控锁的严谨性。利用 Toxiproxy，我们可以人为制造一个“时间膨胀”的窗口期。
在频控规则判断前注入 2-3 秒的延迟，将原本毫秒级完成的动作拉长。在这几秒内，通过压测工具向网关并发数十次甚至上百次针对同一手机号的发信请求。
验证目标：极大地暴露系统中潜在的并发竞态问题（例如：分布式锁未生效导致多个线程同时读到未超限的旧缓存，最终突破了频控限制发出多条短信）。