Hyperf(企业级协程框架)

　　Hyperf是一款协程框架，可以帮助用户配置多种数据请求方式，让中间件读取数据更快速，方便在不同的设备上读取数据，提升数据处理效率，解决异步非阻塞系统的开发问题，帮助平台扩展数据访问线程，避免访问人数过多导致服务器出现阻塞；您可以通过这款软件快速创建新的协程，可以配置协程工作方案，可以构建协程环境，可以配置协程运行控制方案，可以限制 Parallel 最大同时运行的协程数，帮助用户更好开发数据处理端，快速配置数据读取线程，结合Hyperf提供的框架组件和其他组件就可以设计新的服务系统！

软件功能

　　Hyperf 是基于 Swoole 4.5+ 实现的高性能、高灵活性的 PHP 协程框架，内置协程服务器及大量常用的组件，性能较传统基于 PHP-FPM 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均基于 PSR 标准 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是可替换与可复用的。

　　框架组件库除了常见的协程版的 MySQL客户端、Redis客户端，还为您准备了协程版的 Eloquent ORM、WebSocket 服务端及客户端、JSON RPC 服务端及客户端、GRPC 服务端及客户端、Zipkin/Jaeger (OpenTracing) 客户端、Guzzle HTTP 客户端、Elasticsearch 客户端、Consul 客户端、ETCD 客户端、AMQP 组件、Apollo 配置中心、阿里云 ACM 应用配置管理、ETCD 配置中心、基于令牌桶算法的限流器、通用连接池、熔断器、Swagger 文档生成、Swoole Tracker、视图引擎、Snowflake 全局 ID 生成器 等组件，省去了自己实现对应协程版本的麻烦。

　　Hyperf 还提供了 基于 PSR-11 的依赖注入容器、注解、AOP 面向切面编程、基于 PSR-15 的中间件、自定义进程、基于 PSR-14 的事件管理器、Redis/RabbitMQ 消息队列、自动模型缓存、基于 PSR-16 的缓存、Crontab 秒级定时任务、国际化、Validation 表单验证器 等非常便捷的功能，满足丰富的技术场景和业务场景，开箱即用。

软件特色

　　Hyperspeed + Flexibility = Hyperf，从名字上我们就将 超高速 和 灵活性 作为 Hyperf 的基因。

　　对于超高速，我们基于 Swoole 协程并在框架设计上进行大量的优化以确保超高性能的输出。

　　对于灵活性，我们基于 Hyperf 强大的依赖注入组件，组件均基于 PSR 标准 的契约和由 Hyperf 定义的契约实现，达到框架内的绝大部分的组件或类都是可替换的。

　　基于以上的特点，Hyperf 将存在丰富的可能性，如实现 Web 服务，网关服务，分布式中间件，微服务架构，游戏服务器，物联网（IOT）等。

官方教程

　　依赖自动注入

　　依赖自动注入是 Hyperf 提供的一个非常强大的功能，也是保持框架灵活性的根基。

　　Hyperf 提供了两种注入方式，一种是大家常见的通过构造函数注入，另一种是通过 @Inject 注解注入，下面我们举个例子并分别以两种方式展示注入的实现；

　　假设我们存在一个 \App\Service\UserService 类，类中存在一个 getInfoById(int $id) 方法通过传递一个 id 并最终返回一个用户实体，由于返回值并不是我们这里所需要关注的，所以不做过多阐述，我们要关注的是在任意的类中获取 UserService 并调用里面的方法，一般的方法是通过 new UserService() 来实例化该服务类，但在 Hyperf 下，我们有更优的解决方法。

　　通过构造函数注入只需在构造函数的参数内声明参数的类型，Hyperf 会自动注入对应的对象或值。

　　通过 @Inject 注解注入

　　只需对对应的类属性通过 @var 声明参数的类型，并使用 @Inject 注解标记属性 ，Hyperf 会自动注入对应的对象或值。

　　使用 @Inject 注解时需 use Hyperf\Di\Annotation\Inject; 命名空间；

　　通过上面的示例我们不难发现 $userService 在没有实例化的情况下， 属性对应的类对象被自动注入了。

　　不过这里的案例并未真正体现出依赖自动注入的好处及其强大之处，我们假设一下 UserService 也存在很多的依赖，而这些依赖同时又存在很多其它的依赖时，new 实例化的方式就需要手动实例化很多的对象并调整好对应的参数位，而在 Hyperf 里我们就无须手动管理这些依赖，只需要声明一下最终使用的类即可。

　　而当 UserService 需要发生替换等剧烈的内部变化时，比如从一个本地服务替换成了一个 RPC 远程服务，也只需要通过配置调整依赖中 UserService 这个键值对应的类为新的 RPC 服务类即可。

　　启动 Hyperf 服务

　　由于 Hyperf 内置了协程服务器，也就意味着 Hyperf 将以 CLI 的形式去运行，所以在定义好路由及实际的逻辑代码之后，我们需要在项目根目录并通过命令行运行 php bin/hyperf.php start 来启动服务。

　　当 Console 界面显示服务启动后便可通过 cURL 或 浏览器对服务正常发起访问了，默认服务会提供一个首页 http://127.0.0.1:9501/，对于本章示例引导的情况下，也就是上面的例子所对应的访问地址为 http://127.0.0.1:9501/index/info?id=1。

　　重新加载代码

　　由于 Hyperf 是持久化的 CLI 应用，也就意味着一旦进程启动，已解析的 PHP 代码会持久化在进程中，也就意味着启动服务后您再修改的 PHP 代码不会改变已启动的服务，如您希望服务重新加载您修改后的代码，您需要通过在启动的 Console 中键入 CTRL + C 终止服务，再重新执行启动命令 php bin/hyperf.php start 完成启动和重新加载。

　　多端口监听

　　Hyperf 支持监听多个端口，但因为 callbacks 中的对象直接从容器中获取，所以相同的 Hyperf\HttpServer\Server::class 会在容器中被覆盖。所以我们需要在依赖关系中，重新定义 Server，确保对象隔离。

　　WebSocket 和 TCP 等 Server 同理。

　　同时 路由文件，或者 注解 也需要指定对应的 server，如下：

　　路由文件 config/routes.php

　　注解

　　事件

　　除上述提到的 Event::ON_REQUEST 事件，框架还支持其他事件，所有事件名如下。

常见问题

　　Inject 或 Value 注解不生效

　　2.0 使用了构造函数中注入 Inject 和 Value 的功能，以下两种场景，可能会导致注入失效，请注意使用。

　　1、原类没有使用 Inject 或 Value，但父类使用了 Inject 或 Value，且原类写了构造函数，同时又没有调用父类构造函数的情况。

　　这样就会导致原类不会生成代理类，而实例化的时候又调用了自身的构造函数，故没办法执行到父类的构造函数。 所以父类代理类中的方法 __handlePropertyHandler 就不会执行，那么 Inject 或 Value 注解就不会生效。

　　2、原类没有使用 Inject 或 Value，但 Trait 中使用了 Inject 或 Value。

　　这样就会导致原类不会生成代理类，故没办法执行构造函数里的 __handlePropertyHandler，所以 Trait 的 Inject 或 Value 注解就不会生效

　　基于上述两种情况，可见 原类 是否生成代理类至关重要，所以，如果使用了带有 Inject 或 Value 的 Trait 和 父类 时，给原类添加一个 Inject，即可解决上述两种情况。

　　异步队列消息丢失

　　如果在使用 async-queue 组件时，发现 handle 中的方法没有执行，请先检查以下几种情况：

　　1、Redis 是否与其他人共用，消息被其他人消费走

　　2、本地进程是否存在残余，被其他进程消费掉

　　以下提供万无一失的解决办法：

　　1、killall php

　　2、修改 async-queue 配置 channel

　　使用 AMQP 组件报 Swoole\Error: API must be called in the coroutine 错误

　　可以在 config/autoload/amqp.php 配置文件中将 params.close_on_destruct 改为 false 即可。

　　使用 Swoole 4.5 版本和 view 组件时访问接口出现 404

　　使用 Swoole 4.5 版本和 view 组件如果出现接口 404 的问题，可以尝试删除 config/autoload/server.php 文件中的 static_handler_locations 配置项。

　　此配置下的路径都会被认为是静态文件路由，所以如果配置了/，就会导致所有接口都会被认为是文件路径，导致接口 404。