Webman未内置熔断器因其专注I/O高效与请求生命周期管理，不涵盖需跨进程共享、状态持久化及状态机切换的分布式容错能力；熔断须业务层基于Redis等外部存储手动实现。
Webman 本身不内置熔断，限流需靠 webman/rate-limiter 组件 + 外部熔断逻辑手动组合；直接套用“限流+熔断”一体化方案会踩坑。
为什么 Webman 没有开箱即用的熔断器？
Webman 是基于 Workerman 的常驻内存框架，核心设计聚焦在 I/O 高效和请求生命周期管理，不包含服务治理层能力。熔断属于分布式容错范畴，需要状态持久化（如失败计数、时间窗口）、跨进程共享（多 worker 间同步）和状态机切换（Closed/Open/Half-Open），而 Webman 默认的 memory 驱动限流器只在单进程内有效，无法支撑熔断所需的全局观测。
常见误判是以为装了 webman/rate-limiter 就能自动熔断 —— 实际它只做请求放行/拒绝，不记录下游调用结果，也不触发状态切换。
- 限流组件职责：控制入口流量速率（QPS/并发数）
- 熔断逻辑必须由业务代码显式实现：捕获异常 → 记录失败 → 判断阈值 → 修改状态 → 跳过调用
- 若要用 Redis 驱动限流，也得额外用 Redis 存储熔断状态（如
circuit_breaker:service_bhash 结构）
webman/rate-limiter 的三种驱动怎么选？
组件支持 memory、apcu、redis 三类存储，选错会导致限流失效或不准：
-
memory：仅限单 worker 进程内计数，多 worker 场景下实际 QPS 是配置值 × worker 数，极易超限 -
apcu：进程间共享，但仅限同一 PHP-FPM 池或 CLI 进程组，Webman 常驻模式下多个 worker 可用，但重启后状态丢失，不适合错误率类熔断统计 -
redis：唯一推荐用于生产环境的驱动，支持原子增减、过期时间、跨机器共享，是实现“错误率熔断”和“响应时间熔断”的基础
示例配置（config/plugin/webman/rate-limiter.php）：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
return [
'default' => [
'driver' => 'redis',
'options' => [
'host' => '127.0.0.1',
'port' => 6379,
'database' => 0,
]
]
];
如何在 Webman 中手动集成熔断逻辑？
不能依赖注解自动熔断，必须在业务方法里显式检查 + 记录 + 跳过调用。典型流程是：checkCircuitState() → 允许才 callDownstream() → recordResult()。
- 状态存储建议用 Redis Hash：
HINCRBY circuit_breaker:order_service failed 1，配合EXPIRE重置窗口 - 半开状态需加随机概率试探，例如失败率 60s 时，允许 10% 请求穿透
- 避免在
onException全局钩子里统一处理熔断 —— 会丢失调用上下文（比如不知道是哪个下游服务失败） - 注意异步调用场景：Workerman 的
AsyncTcpConnection或协程 HTTP 客户端返回的是 Promise，异常可能不在当前栈抛出，需在回调中recordResult()
简化的状态检查片段：
// 伪代码，非完整实现
$state = $redis->hGet('circuit_breaker:payment', 'state'); // 'closed' / 'open' / 'half-open'
if ($state === 'open') {
return ApiResponse::circuitBreak();
}
if ($state === 'half-open' && mt_rand(1, 100) > 10) {
return ApiResponse::circuitBreak();
}
限流和熔断在 Webman 中的执行顺序不能颠倒
必须先做限流，再做熔断判断。否则在流量洪峰下，大量请求卡在熔断状态检查环节，反而加剧 CPU 和 Redis 压力。
- 限流拦截在网关层（如
app/middleware/RateLimitMiddleware.php），在控制器执行前就拒绝超额请求 - 熔断检查放在具体服务调用前（如
OrderService::create()内部），只对已放行的请求做下游健康判断 - 两者共用 Redis 时，要分开 key 前缀：限流用
rate_limit:api:/v1/order，熔断用circuit_breaker:payment，避免误覆盖
最易被忽略的一点：Webman 的多 worker 进程模型下，Redis 连接数容易被打满。务必在 config/container.php 中复用连接实例，而不是每次 new Predis\Client。
