基于Composer库构建支持自动化熔断降级的PHP服务网格

先说一个核心判断：Composer本身不提供服务网格能力，也不内置熔断降级逻辑——它只是依赖管理工具。所谓“基于Composer构建服务网格”，本质是用Composer安装和组织那些真正实现熔断、降级、通信的PHP库，再通过代码集成形成网格行为。

composer require 装的是什么？不是熔断器，而是熔断器的载体

执行 composer require hyperf/circuit-breaker 或 composer require mix/micro-hystrix，装进去的并不是开箱即用的“服务网格”，而是一个可编程的熔断组件。它不会自动拦截所有HTTP请求，也不会自己发现服务实例或路由流量。

• Hyperf 的 hyperf/circuit-breaker 依赖 PsrSimpleCache 接口，你得自己给它绑定一个Redis或者ArrayCache来实现状态持久化；缺了缓存驱动，isOpen() 永远返回 false
• Mix Micro Hystrix 的 CircuitBreaker::do() 必须显式包裹业务调用，不加这层包装，熔断逻辑根本不生效
• 所有这类库都不修改PHP的autoloader或请求生命周期——它们只在你调用的时候才起作用

为什么不能直接在 composer.json 里配“全局熔断”？

因为Composer压根不参与运行时控制。它的 autoload、scripts、repositories 都只在安装或更新阶段执行。想让每个Guzzle请求都自动走熔断，就得自己封装HTTP客户端，或者用AOP（比如 goaop/framework）织入逻辑——这一步，Composer只负责帮你装好GoAOP和熔断器，不会替你写一行拦截代码。

• 常见误操作："scripts": {"post-autoload-dump": "php bin/circuit-init.php"} ——这个脚本只在 dump-autoload 时跑一次，它根本没法维护运行时状态
• 真正的状态（失败计数、时间窗口、半开探测）必须放在进程内（Swoole）或外部存储（Redis），并且每次请求都得触发更新
• 如果用FPM，每次请求都是新进程，除非借助Redis，否则计数器没法跨请求累积，熔断基本形同虚设

Hyperf + circuit-breaker 的最小可行集成要点

Hyperf是目前PHP生态里对服务网格支持最直接的框架，但即便如此，还是需要手动串联几个关键点，熔断才能“动起来”。看一个实操场景：

• 安装后必须发布配置：php bin/hyperf.php vendor:publish hyperf/circuit-breaker，否则 circuit_breaker.php 配置文件不会自动生成
• 配置文件里的 default 策略只对 HyperfCircuitBreakerAnnotationCircuitBreaker 注解生效；没加注解的方法，哪怕用了HttpClient，也不受控制
• 如果要对Guzzle实例统一加熔断，得继承 GuzzleHttpClient，在 request() 方法里调用 CircuitBreaker::call()，并传入唯一 $name 标识下游服务
• 特别注意 sleepWindow 的单位：Hyperf默认是毫秒（60000），而Mix Hystrix是秒（默认10）——混用时很容易误设成10毫秒，导致刚熔断就立刻进入半开状态

降级逻辑不是自动 fallback，而是你写的那个 _demotion 方法

像 clevephp/la-limiting 这类库，声明一个 index_demotion() 就能触发降级，看起来很像自动化的魔法。但它背后依赖的是运行时方法名反射加命名约定，既不是语言特性，也不兼容PSR-4自动加载规则。

• 如果控制器类用了trait引入方法，_demotion 后缀方法可能找不到——PHP不会自动从trait中匹配命名
• Hyperf的 @CircuitBreaker(fallback="fallbackMethod") 要求 fallbackMethod 是同一个类中的public方法，且签名必须完全一致（包括参数类型和数量）
• 最容易忽略的一点：fallback方法里不能再次调用同一个熔断器保护的下游服务，否则很可能陷入嵌套熔断或死循环

说到底，真正难的地方从来不是装哪个包，而是把状态存在哪里、谁来负责重置计数、半开探测怎么选请求、降级数据要不要做缓存——这些决策靠 composer install 解决不了，只能靠你在代码里写清楚。