Merge pull request #657 from huangzhhui/upgrade

v1.1 Upgrade Guide and Documentation
2024-12-02 03:37:44 +08:00 · 2019-10-08 01:28:34 +08:00 · 2019-10-08 01:28:34 +08:00 · ea2ace4076
commit ea2ace4076
parent 8827575474 27698f21a8
14 changed files with 677 additions and 52 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -12,7 +12,7 @@
 - [#500](https://github.com/hyperf-cloud/hyperf/pull/499) Added fluent method calls of `Hyperf\HttpServer\Contract\ResponseInterface`.
 - [#523](https://github.com/hyperf-cloud/hyperf/pull/523) Added option `table-mapping` for command `db:model`.
 - [#555](https://github.com/hyperf-cloud/hyperf/pull/555) Added global function `swoole_hook_flags` to get the hook flags by constant `SWOOLE_HOOK_FLAGS`, and you could define in `bin/hyperf.php` via `! defined('SWOOLE_HOOK_FLAGS') && define('SWOOLE_HOOK_FLAGS', SWOOLE_HOOK_ALL);` to define the constant.
- [#596](https://github.com/hyperf-cloud/hyperf/pull/596) [#658](https://github.com/hyperf-cloud/hyperf/pull/658) Added `required` parameter for `@Inject`, if you define `@Inject(required=false)` annotation to a property, therefore the DI container will not throw an `Hyperf\Di\Exception\NotFoundException` when the dependency of the property does not exists, the default value of `required` parameter is `true`. In constructor injection mode, you could define the parameter of the `__construct` as `nullable`, this will not throw the exception too.
+- [#596](https://github.com/hyperf-cloud/hyperf/pull/596) [#658](https://github.com/hyperf-cloud/hyperf/pull/658) Added `required` parameter for `@Inject`, if you define `@Inject(required=false)` annotation to a property, therefore the DI container will not throw an `Hyperf\Di\Exception\NotFoundException` when the dependency of the property does not exists, the default value of `required` parameter is `true`. In constructor injection mode, you could define the default value of the parameter of the `__construct` to `null` or define the parameter as a `nullable` parameter , this means this parameter is nullable and will not throw the exception too.
 - [#597](https://github.com/hyperf-cloud/hyperf/pull/597) Added concurrent for async-queue.
 - [#599](https://github.com/hyperf-cloud/hyperf/pull/599) Allows set the retry seconds according to attempt times of async queue consumer.
 - [#619](https://github.com/hyperf-cloud/hyperf/pull/619) Added HandlerStackFactory of guzzle.
--- a/doc/README.md
+++ b/doc/README.md
@ -2,9 +2,9 @@

 Hyperf 是基于 `Swoole 4.3+` 实现的高性能、高灵活性的 PHP 协程框架，内置协程服务器及大量常用的组件，性能较传统基于 `PHP-FPM` 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均基于 [PSR 标准](https://www.php-fig.org/psr) 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是 `可替换` 与 `可复用` 的。
   
-框架组件库除了常见的协程版的 `MySQL 客户端`、`Redis 客户端`，还为您准备了协程版的 `Eloquent ORM`、`JSON RPC 服务端及客户端`、`GRPC 服务端及客户端`、`WebSocket 服务端和客户端`、`Zipkin (OpenTracing) 客户端`、`Guzzle HTTP 客户端`、`Elasticsearch 客户端`、`Consul 客户端`、`ETCD 客户端`、`AMQP 组件`、`基于 Redis 实现的消息队列`、`Apollo 配置中心`、`ETCD 配置中心`、`阿里云 ACM 配置中心`、`基于令牌桶算法的限流器`、`通用连接池`、`熔断器`、`Swagger 文档自动生成`、`Swoole Tracker (Swoole Enterprise)`、`Blade 和 Smarty 视图引擎` 等组件的提供也省去了自己去实现对应协程版本的麻烦。
+框架组件库除了常见的协程版的 `MySQL 客户端`、`Redis 客户端`，还为您准备了协程版的 `Eloquent ORM`、`WebSocket 服务端及客户端`、`JSON RPC 服务端及客户端`、`GRPC 服务端及客户端`、`Zipkin/Jaeger (OpenTracing) 客户端`、`Guzzle HTTP 客户端`、`Elasticsearch 客户端`、`Consul 客户端`、`ETCD 客户端`、`AMQP 组件`、`Apollo 配置中心`、`阿里云 ACM 应用配置管理`、`ETCD 配置中心`、`基于令牌桶算法的限流器`、`通用连接池`、`熔断器`、`Swagger 文档生成`、`Swoole Tracker`、`Blade 和 Smarty 视图引擎`、`Snowflake 全局ID生成器` 等组件，省去了自己实现对应协程版本的麻烦。   

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

 # 框架初衷

@ -21,4 +21,4 @@ Hyperf 还提供了 `依赖注入`、`注解`、`AOP 面向切面编程`、`中

 # 生产可用

-我们为组件进行了大量的单元测试以保证逻辑的正确，同时维护了高质量的文档，在 Hyperf 正式对外开放之前，便已在一家 C轮 和一家 B轮 互联网公司上线了多个服务并以稳定的姿态完美的运行了超过半年时间，经过了严酷的生产环境的考验，我们才正式的对外开放该项目。
+我们为组件进行了大量的单元测试以保证逻辑的正确，同时维护了高质量的文档，在 Hyperf 正式对外开放之前，便已经过了严酷的生产环境的考验，我们才正式的对外开放该项目，至今，已有很多的大型/中小型互联网公司在生产环境使用 Hyperf。
--- a/doc/zh/README.md
+++ b/doc/zh/README.md
@ -1,12 +1,14 @@
 # 介绍

-Hyperf 是基于 `Swoole 4.3+` 实现的高性能、高灵活性的 PHP 协程框架，内置协程服务器及大量常用的组件，性能较传统基于 `PHP-FPM` 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均均基于 [PSR 标准](https://www.php-fig.org/psr) 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是 `可替换` 与 `可复用` 的。
+Hyperf 是基于 `Swoole 4.3+` 实现的高性能、高灵活性的 PHP 协程框架，内置协程服务器及大量常用的组件，性能较传统基于 `PHP-FPM` 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均基于 [PSR 标准](https://www.php-fig.org/psr) 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是 `可替换` 与 `可复用` 的。
   
-框架组件库除了常见的协程版的 `MySQL 客户端`、`Redis 客户端`，还为您准备了协程版的 `Eloquent ORM`、`JSON RPC 服务的及客户端`、`GRPC 服务端及客户端`、`Zipkin (OpenTracing) 客户端`、`Guzzle HTTP 客户端`、`Elasticsearch 客户端`、`Consul 客户端`、`ETCD 客户端`、`AMQP 组件`、`Apollo 配置中心`、`阿里云 ACM 应用配置管理`、`基于令牌桶算法的限流器`、`通用连接池`、`熔断器`、`Swagger 文档生成` 等组件，省去了自己实现对应协程版本的麻烦，Hyperf 还提供了 `依赖注入`、`注解`、`AOP 面向切面编程`、`中间件`、`自定义进程`、`事件管理器`、`Redis/RabbitMQ 消息队列`、`自动模型缓存` 等非常便捷的功能，满足丰富的技术场景和业务场景，开箱即用。
+框架组件库除了常见的协程版的 `MySQL 客户端`、`Redis 客户端`，还为您准备了协程版的 `Eloquent ORM`、`WebSocket 服务端及客户端`、`JSON RPC 服务端及客户端`、`GRPC 服务端及客户端`、`Zipkin/Jaeger (OpenTracing) 客户端`、`Guzzle HTTP 客户端`、`Elasticsearch 客户端`、`Consul 客户端`、`ETCD 客户端`、`AMQP 组件`、`Apollo 配置中心`、`阿里云 ACM 应用配置管理`、`ETCD 配置中心`、`基于令牌桶算法的限流器`、`通用连接池`、`熔断器`、`Swagger 文档生成`、`Swoole Tracker`、`Blade 和 Smarty 视图引擎`、`Snowflake 全局ID生成器` 等组件，省去了自己实现对应协程版本的麻烦。   
+
+Hyperf 还提供了 `基于 PSR-11 的依赖注入容器`、`注解`、`AOP 面向切面编程`、`基于 PSR-15 的中间件`、`自定义进程`、`基于 PSR-14 的事件管理器`、`Redis/RabbitMQ 消息队列`、`自动模型缓存`、`基于 PSR-16 的缓存`、`Crontab 秒级定时任务`、`国际化`、`Validation 表单验证器` 等非常便捷的功能，满足丰富的技术场景和业务场景，开箱即用。

 # 框架初衷

-尽管现在基于 PHP 语言开发的框架处于一个百花争鸣的时代，但仍旧未能看到一个优雅的设计与超高性能的共存的完美框架，亦没有看到一个真正为 PHP 微服务铺路的框架，此为 Hyperf 及其团队成员的初衷，我们将持续投入并为此付出努力，也欢迎你加入我们参与开源建设。
+尽管现在基于 PHP 语言开发的框架处于一个百家争鸣的时代，但仍旧未能看到一个优雅的设计与超高性能的共存的完美框架，亦没有看到一个真正为 PHP 微服务铺路的框架，此为 Hyperf 及其团队成员的初衷，我们将持续投入并为此付出努力，也欢迎你加入我们参与开源建设。

 # 设计理念

@ -19,4 +21,4 @@ Hyperf 是基于 `Swoole 4.3+` 实现的高性能、高灵活性的 PHP 协程

 # 生产可用

-我们为组件进行了大量的单元测试以保证逻辑的正确，同时维护了高质量的文档，在 Hyperf 正式对外开放之前，便已在一家 C轮 和一家 B轮 互联网公司上线了多个服务并以稳定的姿态完美的运行了超过半年时间，经过了严酷的生产环境的考验，我们才正式的对外开放该项目。
+我们为组件进行了大量的单元测试以保证逻辑的正确，同时维护了高质量的文档，在 Hyperf 正式对外开放之前，便已经过了严酷的生产环境的考验，我们才正式的对外开放该项目，至今，已有很多的大型/中小型互联网公司在生产环境使用 Hyperf。
--- a/doc/zh/amqp.md
+++ b/doc/zh/amqp.md
@ -48,15 +48,18 @@ return [

 ## 投递消息

-使用 `generator` 工具新建一个 `producer`
-```
+使用 `gen:producer` 命令创建一个 `producer`
+
+```bash
 php bin/hyperf.php gen:amqp-producer DemoProducer
 ```

-在DemoProducer文件中，我们可以修改Producer注解对应的字段来替换对应的 `exchange` 和 `routingKey`。
+在 DemoProducer 文件中，我们可以修改 `@Producer` 注解对应的字段来替换对应的 `exchange` 和 `routingKey`。
 其中 `payload` 就是最终投递到消息队列中的数据，所以我们可以随意改写 `__construct` 方法，只要最后赋值 `payload` 即可。
 示例如下。

+> 使用 `@Producer` 注解时需 `use Hyperf\Amqp\Annotation\Producer;` 命名空间；   
+
 ```php
 <?php

@ -89,7 +92,7 @@ class DemoProducer extends ProducerMessage

 ```

-通过container获取Producer实例，即可投递消息。以下实例直接使用ApplicationContext获取Producer其实并不合理，container具体使用请到di模块中查看。
+通过 DI Container 获取 `Hyperf\Amqp\Producer` 实例，即可投递消息。以下实例直接使用 `ApplicationContext` 获取 `Hyperf\Amqp\Producer` 其实并不合理，DI Container 具体使用请到 [依赖注入](zh/di.md) 章节中查看。

 ```php
 <?php
@ -105,15 +108,18 @@ $result = $producer->produce($message);

 ## 消费消息

-使用 `generator` 工具新建一个 `consumer`。
-```
+使用 `gen:amqp-consumer` 命令创建一个 `consumer`。
+
+```bash
 php bin/hyperf.php gen:amqp-consumer DemoConsumer
 ```

-在DemoConsumer文件中，我们可以修改Consumer注解对应的字段来替换对应的 `exchange`、`routingKey` 和 `queue`。
-其中 `$data` 就是解析后的元数据。
+在 DemoConsumer 文件中，我们可以修改 `@Consumer` 注解对应的字段来替换对应的 `exchange`、`routingKey` 和 `queue`。
+其中 `$data` 就是解析后的消息数据。
 示例如下。

+> 使用 `@Consumer` 注解时需 `use Hyperf\Amqp\Annotation\Consumer;` 命名空间；   
+
 ```php
 <?php

@ -138,4 +144,15 @@ class DemoConsumer extends ConsumerMessage
 }
 ```

-框架会根据Consumer注解自动创建Process进程，进程意外退出后会被重新拉起。
+框架会根据 `@Consumer` 注解自动创建 `Process 进程`，进程意外退出后会被重新拉起。
+
+### 消费结果
+
+框架会根据 `Consumer` 内的 `consume` 方法所返回的结果来决定该消息的响应行为，共有 4 中响应结果，分别为 `\Hyperf\Amqp\Result::ACK`、`\Hyperf\Amqp\Result::NACK`、`\Hyperf\Amqp\Result::REQUEUE`、`\Hyperf\Amqp\Result::DROP`，每个返回值分别代表如下行为：
+
+| 返回值                         | 行为 |
+|-------------------------------|-----|
+| \Hyperf\Amqp\Result::ACK      | 确认消息正确被消费掉了  |
+| \Hyperf\Amqp\Result::NACK     | 消息没有被正确消费掉，以 `basic_nack` 方法来响应 |
+| \Hyperf\Amqp\Result::REQUEUE  | 消息没有被正确消费掉，以 `basic_reject` 方法来响应，并使消息重新入列  |
+| \Hyperf\Amqp\Result::DROP     | 消息没有被正确消费掉，以 `basic_reject` 方法来响应  |
--- a/doc/zh/changelog.md
+++ b/doc/zh/changelog.md
@ -0,0 +1,409 @@
+# 版本更新记录
+
+# v1.1.0 - 2019-10-08
+
+## 新增
+
+- [#401](https://github.com/hyperf-cloud/hyperf/pull/401) 新增了 `Hyperf\HttpServer\Router\Dispatched` 对象来储存解析的路由信息，在用户中间件之前便解析完成以便后续的使用，同时也修复了路由里带参时中间件失效的问题；
+- [#402](https://github.com/hyperf-cloud/hyperf/pull/402) 新增 `@AsyncQueueMessage` 注解，通过定义此注解在方法上，表明这个方法的实际运行逻辑是投递给 Async-Queue 队列去消费；
+- [#418](https://github.com/hyperf-cloud/hyperf/pull/418) 允许发送 WebSocket 消息到任意的 fd，即使当前的 Worker 进程不持有对应的 fd，框架会自动进行进程间通讯来实现发送；
+- [#420](https://github.com/hyperf-cloud/hyperf/pull/420) 为数据库模型增加新的事件机制，与 PSR-15 的事件调度器相配合，可以解耦的定义 Listener 来监听模型事件；
+- [#429](https://github.com/hyperf-cloud/hyperf/pull/429) [#643](https://github.com/hyperf-cloud/hyperf/pull/643) 新增 Validation 表单验证器组件，这是一个衍生于 [illuminate/validation](https://github.com/illuminate/validation) 的组件，感谢 Laravel 开发组提供如此好用的验证器组件，；
+- [#441](https://github.com/hyperf-cloud/hyperf/pull/441) 当 Redis 连接处于低使用频率的情况下自动关闭空闲连接；
+- [#478](https://github.com/hyperf-cloud/hyperf/pull/441) 更好的适配 OpenTracing 协议，同时适配 [Jaeger](https://www.jaegertracing.io/)，Jaeger 是一款优秀的开源的端对端分布式调用链追踪系统；
+- [#500](https://github.com/hyperf-cloud/hyperf/pull/499) 为 `Hyperf\HttpServer\Contract\ResponseInterface` 增加链式方法调用支持，解决调用了代理方法的方法后无法再调用原始方法的问题；
+- [#523](https://github.com/hyperf-cloud/hyperf/pull/523) 为  `gen:model` 命令新增了 `table-mapping` 选项；
+- [#555](https://github.com/hyperf-cloud/hyperf/pull/555) 新增了一个全局函数 `swoole_hook_flags` 来获取由常量 `SWOOLE_HOOK_FLAGS` 所定义的 Runtime Hook 等级，您可以在 `bin/hyperf.php` 通过 `! defined('SWOOLE_HOOK_FLAGS') && define('SWOOLE_HOOK_FLAGS', SWOOLE_HOOK_ALL);` 的方式来定义该常量，即 Runtime Hook 等级；
+- [#596](https://github.com/hyperf-cloud/hyperf/pull/596)  为`@Inject` 注解增加了  `required` 参数，当您定义 `@Inject(required=false)` 注解到一个成员属性上，那么当该依赖项不存在时也不会抛出 `Hyperf\Di\Exception\NotFoundException` 异常，而是以默认值 `null` 来注入， `required` 参数的默认值为 `true`，当在构造器注入的情况下，您可以通过对构造器的参数定义为 `nullable` 来达到同样的目的；
+- [#597](https://github.com/hyperf-cloud/hyperf/pull/597) 为 AsyncQueue 组件的消费者增加 `Concurrent` 来控制消费速率；
+- [#599](https://github.com/hyperf-cloud/hyperf/pull/599) 为 AsyncQueue 组件的消费者增加根据当前重试次数来设定该消息的重试等待时长的功能，可以为消息设置阶梯式的重试等待；
+- [#619](https://github.com/hyperf-cloud/hyperf/pull/619) 为 Guzzle 客户端增加 HandlerStackFactory 类，以便更便捷地创建一个 HandlerStack；
+- [#620](https://github.com/hyperf-cloud/hyperf/pull/620) 为 AsyncQueue 组件的消费者增加自动重启的机制；
+- [#629](https://github.com/hyperf-cloud/hyperf/pull/629) 允许通过配置文件的形式为 Apollo 客户端定义  `clientIp`, `pullTimeout`, `intervalTimeout` 配置；
+- [#647](https://github.com/hyperf-cloud/hyperf/pull/647) 根据 server 的配置，自动为 TCP Response 追加 `eof`；
+- [#648](https://github.com/hyperf-cloud/hyperf/pull/648) 为 AMQP Consumer 增加 `nack` 的返回类型，当消费逻辑返回 `Hyperf\Amqp\Result::NACK` 时抽象消费者会以 `basic_nack` 方法来响应消息；
+- [#654](https://github.com/hyperf-cloud/hyperf/pull/654) 增加所有 Swoole Event 的默认回调和对应的 Hyperf 事件；
+
+## 变更
+
+- [#437](https://github.com/hyperf-cloud/hyperf/pull/437) `Hyperf\Testing\Client` 在遇到异常时不再直接抛出异常而是交给 ExceptionHandler 流程处理；
+- [#463](https://github.com/hyperf-cloud/hyperf/pull/463) 简化了 `container.php` 文件及优化了注解缓存机制；
+
+新的 config/container.php 文件内容如下：
+
+```php
+<?php
+
+use Hyperf\Di\Container;
+use Hyperf\Di\Definition\DefinitionSourceFactory;
+use Hyperf\Utils\ApplicationContext;
+
+$container = new Container((new DefinitionSourceFactory(true))());
+
+if (! $container instanceof \Psr\Container\ContainerInterface) {
+    throw new RuntimeException('The dependency injection container is invalid.');
+}
+return ApplicationContext::setContainer($container);
+```
+
+- [#486](https://github.com/hyperf-cloud/hyperf/pull/486) `Hyperf\HttpMessage\Server\Request` 的 `getParsedBody` 方法现在可以直接处理 JSON 格式的数据了；
+- [#523](https://github.com/hyperf-cloud/hyperf/pull/523) 调整 `gen:model` 命令生成的模型类名默认为单数，如果表名为复数，则默认生成的类名为单数；
+- [#614](https://github.com/hyperf-cloud/hyperf/pull/614) [#617](https://github.com/hyperf-cloud/hyperf/pull/617) 调整了 ConfigProvider 类的结构, 同时将 `config/dependencies.php` 文件移动到了 `config/autoload/dependencies.php` 内，且文件结构去除了 `dependencies` 层，此后也意味着您也可以将 `dependencies` 配置写到 `config/config.php` 文件内；
+
+Config Provider 内数据结构的变化：
+之前：
+
+```php
+'scan' => [
+    'paths' => [
+        __DIR__,
+    ],
+    'collectors' => [],
+],
+```
+
+现在：
+
+```php
+'annotations' => [
+    'scan' => [
+        'paths' => [
+            __DIR__,
+        ],
+        'collectors' => [],
+    ],
+],
+```
+
+> 增加了一层 annotations，这样将与配置文件结构一致，不再特殊
+
+- [#630](https://github.com/hyperf-cloud/hyperf/pull/630) 变更了 `Hyperf\HttpServer\CoreMiddleware` 类的实例化方式，使用 `make()` 来替代了 `new`；
+- [#631](https://github.com/hyperf-cloud/hyperf/pull/631) 变更了 AMQP Consumer 的实例化方式，使用 `make()` 来替代了 `new`；
+- [#637](https://github.com/hyperf-cloud/hyperf/pull/637) 调整了Hyperf\Contract\OnMessageInterface` 和 `Hyperf\Contract\OnOpenInterface` 的第一个参数的类型约束， 使用 `Swoole\WebSocket\Server` 替代 `Swoole\Server`；
+- [#638](https://github.com/hyperf-cloud/hyperf/pull/638) 重命名了 `db:model` 命令为 `gen:model` 命令，同时增加了一个 Visitor 来优化创建的 `$connection` 成员属性，如果要创建的模型类的 `$connection` 属性的值与继承的父类一致，那么创建的模型类将不会包含此属性；
+
+## 移除
+
+- [#401](https://github.com/hyperf-cloud/hyperf/pull/401) 移除了 `Hyperf\JsonRpc\HttpServerFactory`, `Hyperf\HttpServer\ServerFactory`, `Hyperf\GrpcServer\ServerFactory` 类；
+- [#402](https://github.com/hyperf-cloud/hyperf/pull/402) 移除了弃用的 `AsyncQueue::delay` 方法；
+- [#563](https://github.com/hyperf-cloud/hyperf/pull/563) 移除了弃用的 `Hyperf\Server\ServerInterface::SERVER_TCP` 常量，使用 `Hyperf\Server\ServerInterface::SERVER_BASE` 来替代；
+- [#602](https://github.com/hyperf-cloud/hyperf/pull/602) 移除了 `Hyperf\Utils\Coroutine\Concurrent` 的 `timeout` 参数；
+- [#612](https://github.com/hyperf-cloud/hyperf/pull/612) 移除了 RingPHP Handler 里没有使用到的 `$url` 变量；
+- [#616](https://github.com/hyperf-cloud/hyperf/pull/616) [#618](https://github.com/hyperf-cloud/hyperf/pull/618) 移除了 Guzzle 里一些无用的代码；
+
+## 优化
+
+- [#644](https://github.com/hyperf-cloud/hyperf/pull/644) 优化了注解扫描的流程，分开 `app` 和 `vendor` 两部分来扫描注解，大大减少了用户的扫描耗时；
+- [#653](https://github.com/hyperf-cloud/hyperf/pull/653) 优化了 Swoole shortname 的检测逻辑，现在的检测逻辑更加贴合 Swoole 的实际配置场景，也不只是 `swoole.use_shortname = "Off"` 才能通过检测了；
+
+## 修复
+
+- [#448](https://github.com/hyperf-cloud/hyperf/pull/448) 修复了当 HTTP Server 或 WebSocket Server 存在时，TCP Server 有可能无法启动的问题；
+- [#623](https://github.com/hyperf-cloud/hyperf/pull/623) 修复了当传递一个 `null` 值到代理类的方法参数时，方法仍然会获取方法默认值的问题；
+
+# v1.0.16 - 2019-09-20
+
+## 新增
+
+- [#565](https://github.com/hyperf-cloud/hyperf/pull/565) 增加对 Redis 客户端的 `options` 配置参数支持；
+- [#580](https://github.com/hyperf-cloud/hyperf/pull/580) 增加协程并发控制特性，通过 `Hyperf\Utils\Coroutine\Concurrent` 可以实现一个代码块内限制同时最多运行的协程数量；
+
+## 变更
+
+- [#583](https://github.com/hyperf-cloud/hyperf/pull/583) 当 `BaseClient::start` 失败时会抛出 `Hyperf\GrpcClient\Exception\GrpcClientException` 异常；
+- [#585](https://github.com/hyperf-cloud/hyperf/pull/585) 当投递到 TaskWorker 执行的 Task 失败时，会回传异常到 Worker 进程中；
+
+## 修复
+
+- [#564](https://github.com/hyperf-cloud/hyperf/pull/564) 修复某些情况下 `Coroutine\Http2\Client->send` 返回值不正确的问题；
+- [#567](https://github.com/hyperf-cloud/hyperf/pull/567) 修复当 JSON RPC 消费者配置 name 不是接口时，无法生成代理类的问题；
+- [#571](https://github.com/hyperf-cloud/hyperf/pull/571) 修复 ExceptionHandler 的 `stopPropagation` 的协程变量污染的问题；
+- [#579](https://github.com/hyperf-cloud/hyperf/pull/579) 动态初始化 `snowflake`  的 MetaData，主要修复当在命令模式下使用 Snowflake 时，比如 `di:init-proxy` 命令，会连接到 Redis 服务器至超时；
+
+# v1.0.15 - 2019-09-11
+
+## 修复
+
+- [#534](https://github.com/hyperf-cloud/hyperf/pull/534) 修复 Guzzle HTTP 客户端的 `CoroutineHanlder` 没有处理状态码为 `-3` 的情况；
+- [#541](https://github.com/hyperf-cloud/hyperf/pull/541) 修复 gRPC 客户端的 `$client` 参数设置错误的问题；
+- [#542](https://github.com/hyperf-cloud/hyperf/pull/542) 修复 `Hyperf\Grpc\Parser::parseResponse` 无法支持 gRPC 标准状态码的问题；
+- [#551](https://github.com/hyperf-cloud/hyperf/pull/551) 修复当服务端关闭了 gRPC 连接时，gRPC 客户端会残留一个死循环的协程；
+- [#558](https://github.com/hyperf-cloud/hyperf/pull/558) 修复 `UDP Server` 无法正确配置启动的问题；
+
+## 优化
+
+- [#549](https://github.com/hyperf-cloud/hyperf/pull/549) 优化了 `Hyperf\Amqp\Connection\SwooleIO` 的 `read` 和 `write` 方法，减少不必要的重试；
+- [#559](https://github.com/hyperf-cloud/hyperf/pull/559) 优化 `Hyperf\HttpServer\Response::redirect()` 方法，自动识别链接首位是否为斜杠并合理修正参数；
+- [#560](https://github.com/hyperf-cloud/hyperf/pull/560) 优化 `Hyperf\WebSocketServer\CoreMiddleware`，移除了不必要的代码；
+
+## 移除
+
+- [#545](https://github.com/hyperf-cloud/hyperf/pull/545) 移除了 `Hyperf\Database\Model\SoftDeletes` 内无用的 `restoring` 和 `restored` 静态方法； 
+
+## 即将移除
+
+- [#558](https://github.com/hyperf-cloud/hyperf/pull/558) 标记了 `Hyperf\Server\ServerInterface::SERVER_TCP` 常量为 `弃用` 状态，该常量将于 `v1.1` 移除，由更合理的 `Hyperf\Server\ServerInterface::SERVER_BASE` 常量替代；
+
+# v1.0.14 - 2019-09-05
+
+## 新增
+
+- [#389](https://github.com/hyperf-cloud/hyperf/pull/389) [#419](https://github.com/hyperf-cloud/hyperf/pull/419) [#432](https://github.com/hyperf-cloud/hyperf/pull/432) [#524](https://github.com/hyperf-cloud/hyperf/pull/524) 新增 Snowflake 官方组件, Snowflake 是一个由 Twitter 提出的分布式全局唯一 ID 生成算法，[hyperf/snowflake](https://github.com/hyperf-cloud/snowflake) 组件实现了该算法并设计得易于使用，同时在设计上提供了很好的可扩展性，可以很轻易的将该组件转换成其它基于 Snowflake 算法的变体算法；
+- [#525](https://github.com/hyperf-cloud/hyperf/pull/525) 为 `Hyperf\HttpServer\Contract\ResponseInterface` 增加一个 `download()` 方法，提供便捷的下载响应返回；
+
+## 变更
+
+- [#482](https://github.com/hyperf-cloud/hyperf/pull/482) 生成模型文件时，当设置了 `refresh-fillable` 选项时重新生成模型的 `fillable` 属性，同时该命令的默认情况下将不会再覆盖生成 `fillable` 属性；
+- [#501](https://github.com/hyperf-cloud/hyperf/pull/501) 当 `Mapping` 注解的 `path` 属性为一个空字符串时，那么该路由则为 `/prefix`；
+- [#513](https://github.com/hyperf-cloud/hyperf/pull/513) 如果项目设置了 `app_name` 属性，则进程名称会自动带上该名称；
+- [#508](https://github.com/hyperf-cloud/hyperf/pull/508) [#526](https://github.com/hyperf-cloud/hyperf/pull/526) 当在非协程环境下执行 `Hyperf\Utils\Coroutine::parentId()` 方法时会返回一个 `null` 值；
+
+## 修复
+
+- [#479](https://github.com/hyperf-cloud/hyperf/pull/479) 修复了当 Elasticsearch client 的 `host` 属性设置有误时，返回类型错误的问题；
+- [#514](https://github.com/hyperf-cloud/hyperf/pull/514) 修复当 Redis 密码配置为空字符串时鉴权失败的问题；
+- [#527](https://github.com/hyperf-cloud/hyperf/pull/527) 修复 Translator 无法重复翻译的问题；
+
+# v1.0.13 - 2019-08-28
+
+## 新增
+
+- [#449](https://github.com/hyperf-cloud/hyperf/pull/428) 新增一个独立组件 [hyperf/translation](https://github.com/hyperf-cloud/translation)， 衍生于 [illuminate/translation](https://github.com/illuminate/translation)；
+- [#449](https://github.com/hyperf-cloud/hyperf/pull/449) 为 GRPC-Server 增加标准错误码；
+- [#450](https://github.com/hyperf-cloud/hyperf/pull/450) 为 `Hyperf\Database\Schema\Schema` 类的魔术方法增加对应的静态方法注释，为 IDE 提供代码提醒的支持；
+
+## 变更
+
+- [#451](https://github.com/hyperf-cloud/hyperf/pull/451) 在使用 `@AutoController` 注解时不再会自动为魔术方法生成对应的路由；
+- [#468](https://github.com/hyperf-cloud/hyperf/pull/468) 让 GRPC-Server 和 HTTP-Server 提供的异常处理器处理所有的异常，而不只是 `ServerException`；
+
+## 修复 
+
+- [#466](https://github.com/hyperf-cloud/hyperf/pull/466) 修复分页时数据不足时返回类型错误的问题；
+- [#466](https://github.com/hyperf-cloud/hyperf/pull/470) 优化了 `vendor:publish` 命令，当要生成的目标文件夹存在时，不再重复生成；
+
+# v1.0.12 - 2019-08-21
+
+## 新增
+
+- [#405](https://github.com/hyperf-cloud/hyperf/pull/405) 增加 `Hyperf\Utils\Context::override()` 方法，现在你可以通过 `override` 方法获取某些协程上下文的值并修改覆盖它；
+- [#415](https://github.com/hyperf-cloud/hyperf/pull/415) 对 Logger 的配置文件增加多个 Handler 的配置支持；
+
+## 变更
+
+- [#431](https://github.com/hyperf-cloud/hyperf/pull/431) 移除了 `Hyperf\GrpcClient\GrpcClient::openStream()` 的第 3 个参数，这个参数不会影响实际使用；
+
+## 修复
+
+- [#414](https://github.com/hyperf-cloud/hyperf/pull/414) 修复 `Hyperf\WebSockerServer\Exception\Handler\WebSocketExceptionHandler` 内的变量名称错误的问题；
+- [#424](https://github.com/hyperf-cloud/hyperf/pull/424) 修复 Guzzle 在使用 `Hyperf\Guzzle\CoroutineHandler` 时配置 `proxy` 参数时不支持数组传值的问题；
+- [#430](https://github.com/hyperf-cloud/hyperf/pull/430) 修复 `Hyperf\HttpServer\Request::file()` 当以一个 Name 上传多个文件时，返回格式不正确的问题；
+- [#431](https://github.com/hyperf-cloud/hyperf/pull/431) 修复 GRPC Client 的 Request 对象在发送 Force-Close 请求时缺少参数的问题；
+
+# v1.0.11 - 2019-08-15
+
+## 新增
+
+- [#366](https://github.com/hyperf-cloud/hyperf/pull/366) 增加 `Hyperf\Server\Listener\InitProcessTitleListener` 监听者来设置进程名称， 同时增加了 `Hyperf\Framework\Event\OnStart` 和 `Hyperf\Framework\Event\OnManagerStart` 事件；
+
+## 修复
+
+- [#361](https://github.com/hyperf-cloud/hyperf/pull/361) 修复 `db:model`命令在 MySQL 8 下不能正常运行；
+- [#369](https://github.com/hyperf-cloud/hyperf/pull/369) 修复实现 `\Serializable` 接口的自定义异常类不能正确的序列化和反序列化问题；
+- [#384](https://github.com/hyperf-cloud/hyperf/pull/384) 修复用户自定义的 `ExceptionHandler` 在 JSON RPC Server 下无法正常工作的问题，因为框架默认自动处理了对应的异常；
+- [#370](https://github.com/hyperf-cloud/hyperf/pull/370) 修复了 `Hyperf\GrpcClient\BaseClient` 的 `$client` 属性在流式传输的时候设置了错误的类型的值的问题, 同时增加了默认的 `content-type`  为 `application/grpc+proto`，以及允许用户通过自定义 `Request` 对象来重写 `buildRequest()` 方法；
+
+## 变更
+
+- [#356](https://github.com/hyperf-cloud/hyperf/pull/356) [#390](https://github.com/hyperf-cloud/hyperf/pull/390) 优化 aysnc-queue 组件当生成 Job 时，如果 Job 实现了 `Hyperf\Contract\CompressInterface`，那么 Job 对象会被压缩为一个更小的对象；
+- [#358](https://github.com/hyperf-cloud/hyperf/pull/358) 只有当 `$enableCache` 为 `true` 时才生成注解缓存文件；
+- [#359](https://github.com/hyperf-cloud/hyperf/pull/359) [#390](https://github.com/hyperf-cloud/hyperf/pull/390) 为 `Collection` 和 `Model` 增加压缩能力，当类实现 `Hyperf\Contract\CompressInterface` 可通过 `compress` 方法生成一个更小的对象；
+
+# v1.0.10 - 2019-08-09
+
+## 新增
+
+- [#321](https://github.com/hyperf-cloud/hyperf/pull/321) 为 HTTP Server 的 Controller/RequestHandler 参数增加自定义对象类型的数组支持，特别适用于 JSON RPC 下，现在你可以通过在方法上定义 `@var Object[]` 来获得框架自动反序列化对应对象的支持；
+- [#324](https://github.com/hyperf-cloud/hyperf/pull/324) 增加一个实现于 `Hyperf\Contract\IdGeneratorInterface` 的 ID 生成器 `NodeRequestIdGenerator`；
+- [#336](https://github.com/hyperf-cloud/hyperf/pull/336) 增加动态代理的 RPC 客户端功能；
+- [#346](https://github.com/hyperf-cloud/hyperf/pull/346) [#348](https://github.com/hyperf-cloud/hyperf/pull/348) 为 `hyperf/cache` 缓存组件增加文件驱动；
+
+## 变更
+
+- [#330](https://github.com/hyperf-cloud/hyperf/pull/330) 当扫描的 $paths 为空时，不输出扫描信息；
+- [#328](https://github.com/hyperf-cloud/hyperf/pull/328) 根据 Composer 的 PSR-4 定义的规则加载业务项目；
+- [#329](https://github.com/hyperf-cloud/hyperf/pull/329) 优化 JSON RPC 服务端和客户端的异常消息处理；
+- [#340](https://github.com/hyperf-cloud/hyperf/pull/340) 为 `make` 函数增加索引数组的传参方式；
+- [#349](https://github.com/hyperf-cloud/hyperf/pull/349) 重命名下列类，修正由于拼写错误导致的命名错误；
+
+|                     原类名                      |                  修改后的类名                     |
+|:----------------------------------------------|:-----------------------------------------------|
+| Hyperf\\Database\\Commands\\Ast\\ModelUpdateVistor | Hyperf\\Database\\Commands\\Ast\\ModelUpdateVisitor |
+|       Hyperf\\Di\\Aop\\ProxyClassNameVistor       |       Hyperf\\Di\\Aop\\ProxyClassNameVisitor       |
+|         Hyperf\\Di\\Aop\\ProxyCallVistor          |         Hyperf\\Di\\Aop\\ProxyCallVisitor          |
+
+## 修复
+
+- [#325](https://github.com/hyperf-cloud/hyperf/pull/325) 优化 RPC 服务注册时会多次调用 Consul Services 的问题；
+- [#332](https://github.com/hyperf-cloud/hyperf/pull/332) 修复 `Hyperf\Tracer\Middleware\TraceMiddeware` 在新版的 openzipkin/zipkin 下的类型约束错误；
+- [#333](https://github.com/hyperf-cloud/hyperf/pull/333) 修复 `Redis::delete()` 方法在 5.0 版不存在的问题；
+- [#334](https://github.com/hyperf-cloud/hyperf/pull/334) 修复向阿里云 ACM 配置中心拉取配置时，部分情况下部分配置无法更新的问题；
+- [#337](https://github.com/hyperf-cloud/hyperf/pull/337) 修复当 Header 的 key 为非字符串类型时，会返回 500 响应的问题；
+- [#338](https://github.com/hyperf-cloud/hyperf/pull/338) 修复 `ProviderConfig::load` 在遇到重复 key 时会导致在深度合并时将字符串转换成数组的问题；
+
+# v1.0.9 - 2019-08-03
+
+## 新增
+
+- [#317](https://github.com/hyperf-cloud/hyperf/pull/317) 增加 `composer-json-fixer` 来优化 composer.json 文件的内容；
+- [#320](https://github.com/hyperf-cloud/hyperf/pull/320) DI 定义 Definition 时，允许 value 为一个匿名函数；
+
+## 修复
+
+- [#300](https://github.com/hyperf-cloud/hyperf/pull/300) 让 AsyncQueue 的消息于子协程内来进行处理，修复 `attempts` 参数与实际重试次数不一致的问题；
+- [#305](https://github.com/hyperf-cloud/hyperf/pull/305) 修复 `Hyperf\Utils\Arr::set` 方法的 `$key` 参数不支持 `int` 个 `null` 的问题；
+- [#312](https://github.com/hyperf-cloud/hyperf/pull/312) 修复 `Hyperf\Amqp\BeforeMainServerStartListener` 监听器的优先级错误的问题；
+- [#315](https://github.com/hyperf-cloud/hyperf/pull/315) 修复 ETCD 配置中心在 Worker 进程重启后或在自定义进程内无法使用问题；
+- [#318](https://github.com/hyperf-cloud/hyperf/pull/318) 修复服务会持续注册到服务中心的问题；
+
+## 变更
+
+- [#323](https://github.com/hyperf-cloud/hyperf/pull/323) 强制转换 `Cacheable` 和 `CachePut` 注解的 `$ttl` 属性为 `int` 类型；
+
+# v1.0.8 - 2019-07-31
+
+## 新增
+
+- [#276](https://github.com/hyperf-cloud/hyperf/pull/276) AMQP 消费者支持配置及绑定多个 `routing_key`；
+- [#277](https://github.com/hyperf-cloud/hyperf/pull/277) 增加 ETCD 客户端组件及 ETCD 配置中心组件；
+
+## 变更
+
+- [#297](https://github.com/hyperf-cloud/hyperf/pull/297) 如果服务注册失败，会于 10 秒后重试注册，且屏蔽了连接不上服务中心(Consul)而抛出的异常；
+- [#298](https://github.com/hyperf-cloud/hyperf/pull/298) [#301](https://github.com/hyperf-cloud/hyperf/pull/301) 适配 `openzipkin/zipkin` v1.3.3+ 版本；
+
+## 修复
+
+- [#271](https://github.com/hyperf-cloud/hyperf/pull/271) 修复了 AOP 在 `classes` 只会策略下配置同一个类的多个方法只会实现第一个方法的代理方法的问题；
+- [#285](https://github.com/hyperf-cloud/hyperf/pull/285) 修复了 AOP 在匿名类下生成节点存在丢失的问题；
+- [#286](https://github.com/hyperf-cloud/hyperf/pull/286) 自动 `rollback` 没有 `commit` 或 `rollback` 的 MySQL 连接；
+- [#292](https://github.com/hyperf-cloud/hyperf/pull/292) 修复了 `Request::header` 方法的 `$default` 参数无效的问题；
+- [#293](https://github.com/hyperf-cloud/hyperf/pull/293) 修复了 `Arr::get` 方法的 `$key` 参数不支持 `int` and `null` 传值的问题；
+
+# v1.0.7 - 2019-07-26
+
+## 修复
+
+- [#266](https://github.com/hyperf-cloud/hyperf/pull/266) 修复投递 AMQP 消息时的超时逻辑；
+- [#273](https://github.com/hyperf-cloud/hyperf/pull/273) 修复当有一个服务注册到服务中心的时候所有服务会被移除的问题；
+- [#274](https://github.com/hyperf-cloud/hyperf/pull/274) 修复视图响应的 Content-Type ；
+
+# v1.0.6 - 2019-07-24
+
+## 新增
+
+- [#203](https://github.com/hyperf-cloud/hyperf/pull/203) [#236](https://github.com/hyperf-cloud/hyperf/pull/236) [#247](https://github.com/hyperf-cloud/hyperf/pull/247) [#252](https://github.com/hyperf-cloud/hyperf/pull/252) 增加视图组件，支持 Blade 引擎和 Smarty 引擎； 
+- [#203](https://github.com/hyperf-cloud/hyperf/pull/203) 增加 Task 组件，适配 Swoole Task 机制；
+- [#245](https://github.com/hyperf-cloud/hyperf/pull/245) 增加 TaskWorkerStrategy 和 WorkerStrategy 两种定时任务调度策略.
+- [#251](https://github.com/hyperf-cloud/hyperf/pull/251) 增加用协程上下文作为储存的缓存驱动；
+- [#254](https://github.com/hyperf-cloud/hyperf/pull/254) 增加 `RequestMapping::$methods` 对数组传值的支持, 现在可以通过 `@RequestMapping(methods={"GET"})` 和 `@RequestMapping(methods={RequestMapping::GET})` 两种新的方式定义方法；
+- [#255](https://github.com/hyperf-cloud/hyperf/pull/255) 控制器返回 `Hyperf\Utils\Contracts\Arrayable` 会自动转换为 Response 对象, 同时对返回字符串的响应对象增加  `text/plain` Content-Type;
+- [#256](https://github.com/hyperf-cloud/hyperf/pull/256) 如果 `Hyperf\Contract\IdGeneratorInterface` 存在容器绑定关系, 那么 `json-rpc` 客户端会根据该类自动生成一个请求 ID 并储存在 Request attribute 里，同时完善了 `JSON RPC` 在 TCP 协议下的服务注册及健康检查；
+
+## 变更
+
+- [#247](https://github.com/hyperf-cloud/hyperf/pull/247) 使用 `WorkerStrategy` 作为默认的计划任务调度策略；
+- [#256](https://github.com/hyperf-cloud/hyperf/pull/256) 优化 `JSON RPC` 的错误处理，现在当方法不存在时也会返回一个标准的 `JSON RPC` 错误对象；
+
+## 修复
+
+- [#235](https://github.com/hyperf-cloud/hyperf/pull/235) 为 `grpc-server` 增加了默认的错误处理器，防止错误抛出.
+- [#240](https://github.com/hyperf-cloud/hyperf/pull/240) 优化了 OnPipeMessage 事件的触发，修复会被多个监听器获取错误数据的问题；
+- [#257](https://github.com/hyperf-cloud/hyperf/pull/257) 修复了在某些环境下无法获得内网 IP 的问题；
+
+# v1.0.5 - 2019-07-17
+
+## 新增
+
+- [#185](https://github.com/hyperf-cloud/hyperf/pull/185) `响应(Response)` 增加 `xml` 格式支持；
+- [#202](https://github.com/hyperf-cloud/hyperf/pull/202) 在协程内抛出未捕获的异常时，默认输出异常的 trace 信息；
+- [#138](https://github.com/hyperf-cloud/hyperf/pull/138) [#197](https://github.com/hyperf-cloud/hyperf/pull/197) 增加秒级定时任务组件；
+
+# 变更
+
+- [#195](https://github.com/hyperf-cloud/hyperf/pull/195) 变更 `retry()` 函数的 `$times` 参数的行为意义, 表示重试的次数而不是执行的次数；
+- [#198](https://github.com/hyperf-cloud/hyperf/pull/198) 优化 `Hyperf\Di\Container` 的 `has()` 方法, 当传递一个不可实例化的示例（如接口）至 `$container->has($interface)` 方法时，会返回 `false`；
+- [#199](https://github.com/hyperf-cloud/hyperf/pull/199) 当生产 AMQP 消息失败时，会自动重试一次；
+- [#200](https://github.com/hyperf-cloud/hyperf/pull/200) 通过 Git 打包项目的部署包时，不再包含 `tests` 文件夹；
+
+## 修复
+
+- [#176](https://github.com/hyperf-cloud/hyperf/pull/176) 修复 `LengthAwarePaginator::nextPageUrl()` 方法返回值的类型约束；
+- [#188](https://github.com/hyperf-cloud/hyperf/pull/188) 修复 Guzzle Client 的代理设置不生效的问题；
+- [#211](https://github.com/hyperf-cloud/hyperf/pull/211) 修复 RPC Client 存在多个时会被最后一个覆盖的问题；
+- [#212](https://github.com/hyperf-cloud/hyperf/pull/212) 修复 Guzzle Client 的 `ssl_key` 和 `cert` 配置项不能正常工作的问题；
+
+# v1.0.4 - 2019-07-08
+
+## 新增
+
+- [#140](https://github.com/hyperf-cloud/hyperf/pull/140) 支持 Swoole v4.4.0.
+- [#152](https://github.com/hyperf-cloud/hyperf/pull/152) 数据库连接在低使用率时连接池会自动释放连接
+- [#163](https://github.com/hyperf-cloud/hyperf/pull/163) constants 组件的`AbstractConstants::__callStatic` 支持自定义参数
+
+## 变更
+
+- [#124](https://github.com/hyperf-cloud/hyperf/pull/124) `DriverInterface::push` 增加 `$delay` 参数用于设置延迟时间, 同时 `DriverInterface::delay` 将标记为弃用的，将于 1.1 版本移除 
+- [#125](https://github.com/hyperf-cloud/hyperf/pull/125) 更改 `config()` 函数的 `$default` 参数的默认值为 `null`.
+
+## 修复
+
+- [#110](https://github.com/hyperf-cloud/hyperf/pull/110) [#111](https://github.com/hyperf-cloud/hyperf/pull/111) 修复 `Redis::select` 无法正常切换数据库的问题
+- [#131](https://github.com/hyperf-cloud/hyperf/pull/131) 修复 `middlewares` 配置在 `Router::addGroup` 下无法正常设置的问题
+- [#132](https://github.com/hyperf-cloud/hyperf/pull/132) 修复 `request->hasFile` 判断条件错误的问题
+- [#135](https://github.com/hyperf-cloud/hyperf/pull/135) 修复 `response->redirect` 在调整外链时无法正确生成链接的问题
+- [#139](https://github.com/hyperf-cloud/hyperf/pull/139) 修复 ConsulAgent 的 URI 无法自定义设置的问题
+- [#148](https://github.com/hyperf-cloud/hyperf/pull/148) 修复当 `migrates` 文件夹不存在时无法生成迁移模板的问题
+- [#169](https://github.com/hyperf-cloud/hyperf/pull/169) 修复处理请求时没法正确处理数组类型的参数
+- [#170](https://github.com/hyperf-cloud/hyperf/pull/170) 修复当路由不存在时 WebSocket Server 无法正确捕获异常的问题
+
+## 移除
+
+- [#131](https://github.com/hyperf-cloud/hyperf/pull/131) 移除 `Router` `options` 里的 `server` 参数
+
+# v1.0.3 - 2019-07-02
+
+## 新增
+
+- [#48](https://github.com/hyperf-cloud/hyperf/pull/48) 增加 WebSocket 协程客户端及服务端
+- [#51](https://github.com/hyperf-cloud/hyperf/pull/51) 增加了 `enableCache` 参数去控制 `DefinitionSource` 是否启用注解扫描缓存 
+- [#61](https://github.com/hyperf-cloud/hyperf/pull/61) 通过 `db:model` 命令创建模型时增加属性类型
+- [#65](https://github.com/hyperf-cloud/hyperf/pull/65) 模型缓存增加 JSON 格式支持
+
+## 变更
+
+- [#46](https://github.com/hyperf-cloud/hyperf/pull/46) 移除了 `hyperf/di`, `hyperf/command` and `hyperf/dispatcher` 组件对 `hyperf/framework` 组件的依赖
+
+## 修复
+
+- [#45](https://github.com/hyperf-cloud/hyperf/pull/55) 修复当引用了 `hyperf/websocket-server` 组件时有可能会导致 HTTP Server 启动失败的问题
+- [#55](https://github.com/hyperf-cloud/hyperf/pull/55) 修复方法级别的 `@Middleware` 注解可能会被覆盖的问题
+- [#73](https://github.com/hyperf-cloud/hyperf/pull/73) 修复 `db:model` 命令对短属性处理不正确的问题
+- [#88](https://github.com/hyperf-cloud/hyperf/pull/88) 修复当控制器存在多层文件夹时生成的路由可能不正确的问题
+- [#101](https://github.com/hyperf-cloud/hyperf/pull/101) 修复常量不存在 `@Message` 注解时会报错的问题
+
+# v1.0.2 - 2019-06-25
+
+## 新增
+
+- 接入 Travis CI，目前 Hyperf 共存在 426 个单测，1124 个断言； [#25](https://github.com/hyperf-cloud/hyperf/pull/25)
+- 完善了对 `Redis::connect` 方法的参数支持； [#29](https://github.com/hyperf-cloud/hyperf/pull/29)
+
+## 修复
+
+- 修复了 HTTP Server 会被 WebSocket Server 影响的问题（WebSocket Server 尚未发布）；
+- 修复了代理类部分注解没有生成的问题；
+- 修复了数据库连接池在单测环境下会无法获取连接的问题；
+- 修复了 co-phpunit 在某些情况下不能按预期运行的问题；
+- 修复了模型事件 `creating`, `updating` ... 运行与预期不一致的问题；
+- 修复了 `flushContext` 方法在单测环境下不能按预期运行的问题；
--- a/doc/zh/component-guide/configprovider.md
+++ b/doc/zh/component-guide/configprovider.md
@ -4,7 +4,7 @@ ConfigProvider 机制对于 Hyperf 组件化来说是个非常重要的机制，

 # 什么是 ConfigProvider 机制 ？

-简单来说，就是每个组件都会提供一个 `ConfigProvider`，通常是在组件的根目录提供一个 `ConfigProvider` 的类，`ConfigProvider` 会提供对应组件的所有配置信息，这些信息都会被 Hyperf 框架在启动时加载，最终`ConfigProvider` 内的配置信息会被合并到 `Hyperf\Contract\ConfigInterface` 对应的实现类去，而 `dependencies` 信息则会合并到 `Hyperf\Di\Definition\DefinitionSource` 去，从而实现该组件在 Hyperf 框架下使用时要进行的配置初始化。   
+简单来说，就是每个组件都会提供一个 `ConfigProvider`，通常是在组件的根目录提供一个 `ConfigProvider` 的类，`ConfigProvider` 会提供对应组件的所有配置信息，这些信息都会被 Hyperf 框架在启动时加载，最终`ConfigProvider` 内的配置信息会被合并到 `Hyperf\Contract\ConfigInterface` 对应的实现类去，从而实现各个组件在 Hyperf 框架下使用时要进行的配置初始化。   

 `ConfigProvider` 本身不具备任何依赖，不继承任何的抽象类和不要求实现任何的接口，只需提供一个 `__invoke` 方法并返回一个对应配置结构的数组即可。

@ -22,18 +22,21 @@ class ConfigProvider
    public function __invoke(): array
    {
        return [
-            // 合并到  config/dependencies.php 文件
+            // 合并到  config/autoload/dependencies.php 文件
            'dependencies' => [],
            // 合并到  config/autoload/annotations.php 文件
-            'scan' => [
-                'paths' => [
-                    __DIR__,
+            'annotations' => [
+                'scan' => [
+                    'paths' => [
+                        __DIR__,
+                    ],
                ],
            ],
            // 默认 Command 的定义，合并到 Hyperf\Contract\ConfigInterface 内，换个方式理解也就是与 config/autoload/commands.php 对应
            'commands' => [],
            // 与 commands 类似
            'listeners' => [],
+            // 亦可继续定义其它配置，最终都会何必到与 ConfigInterface 对应的配置储存器中
        ];
    }
 }
--- a/doc/zh/coroutine.md
+++ b/doc/zh/coroutine.md
@ -212,4 +212,58 @@ for ($i = 0; $i < 15; ++$i) {
 ### 协程上下文

 由于同一个进程内协程间是内存共享的，但协程的执行/切换是非顺序的，也就意味着我们很难掌控当前的协程是哪一个*(事实上可以，但通常没人这么干)*，所以我们需要在发生协程切换时能够同时切换对应的上下文。   
-在 Hyperf 里实现协程的上下文管理将非常简单，基于 `Hyperf\Utils\Context` 类的 `set(string $id, $value)`、`get(string $id, $default = null)`、`has(string $id)` 静态方法即可完成上下文数据的管理，通过这些方法设置和获取的值，都仅限于当前的协程，在协程结束时，对应的上下文也会自动跟随释放掉，无需手动管理，无需担忧内存泄漏的风险。
+在 Hyperf 里实现协程的上下文管理将非常简单，基于 `Hyperf\Utils\Context` 类的 `set(string $id, $value)`、`get(string $id, $default = null)`、`has(string $id)`、`override(string $id, \Closure $closure)` 静态方法即可完成上下文数据的管理，通过这些方法设置和获取的值，都仅限于当前的协程，在协程结束时，对应的上下文也会自动跟随释放掉，无需手动管理，无需担忧内存泄漏的风险。
+
+#### Hyperf\Utils\Context::set()
+
+通过调用 `set(string $id, $value)` 方法储存一个值到当前协程的上下文中，如下：
+
+```php
+<?php
+use Hyperf\Utils\Context;
+
+// 将 bar 字符串以 foo 为 key 储存到当前协程上下文中
+$foo = Context::set('foo', 'bar');
+// set 方法会再将 value 作为方法的返回值返回回来，所以 $foo 的值为 bar
+```
+
+#### Hyperf\Utils\Context::get()
+
+通过调用 `get(string $id, $default = null)` 方法可从当前协程的上下文中取出一个以 `$id` 为 key 储存的值，如不存在则返回 `$default` ，如下：
+
+```php
+<?php
+use Hyperf\Utils\Context;
+
+// 从当前协程上下文中取出 key 为 foo 的值，如不存在则返回 bar 字符串
+$foo = Context::get('foo', 'bar');
+```
+
+#### Hyperf\Utils\Context::has()
+
+通过调用 `has(string $id)` 方法可判断当前协程的上下文中是否存在以 `$id` 为 key 储存的值，如存在则返回 `true`，不存在则返回 `false`，如下：
+
+```php
+<?php
+use Hyperf\Utils\Context;
+
+// 从当前协程上下文中判断 key 为 foo 的值是否存在
+$foo = Context::has('foo');
+```
+
+#### Hyperf\Utils\Context::override()
+
+> Override 方法仅可在 1.0.12 版本或更高版本使用
+
+当我们需要做一些复杂的上下文处理，比如先判断一个 key 是否存在，如果存在则取出 value 来再对 value 进行某些修改，然后再将 value 设置回上下文容器中，此时会有比较繁杂的判断条件，可直接通过调用 `override` 方法来实现这个逻辑，如下：
+
+```php
+<?php
+use Hyperf\HttpServer\Contract\RequestInterface;
+use Hyperf\Utils\Context;
+
+// 从协程上下文取出 $request 对象并设置 key 为 foo 的 Header，然后再保存到协程上下文中
+$request = Context::override(RequestInterface::class, function (RequestInterface $request) {
+    return $request->withAddedHeader('foo', 'bar');
+});
+```
--- a/doc/zh/crontab.md
+++ b/doc/zh/crontab.md
@ -106,14 +106,12 @@ class FooTask

 #### 更改调度分发策略

-通过在 `config/dependencies.php` 更改 `Hyperf\Crontab\Strategy\StrategyInterface` 接口类所对应的实例来更改目前所使用的策略，默认情况下使用 `多进程执行策略`，对应的类为 `Hyperf\Crontab\Strategy\ProcessStrategy`，如我们希望更改策略为一个新的策略，比如为 `App\Crontab\Strategy\FooStrategy`，那么如下：
+通过在 `config/autoload/dependencies.php` 更改 `Hyperf\Crontab\Strategy\StrategyInterface` 接口类所对应的实例来更改目前所使用的策略，默认情况下使用 `多进程执行策略`，对应的类为 `Hyperf\Crontab\Strategy\ProcessStrategy`，如我们希望更改策略为一个新的策略，比如为 `App\Crontab\Strategy\FooStrategy`，那么如下：

 ```php
 <?php
 return [
-    'dependencies' => [
-        \Hyperf\Crontab\Strategy\StrategyInterface::class => \App\Crontab\Strategy\FooStrategy::class,
-    ],
+    \Hyperf\Crontab\Strategy\StrategyInterface::class => \App\Crontab\Strategy\FooStrategy::class,
 ];
 ```

--- a/doc/zh/di.md
+++ b/doc/zh/di.md
@ -40,7 +40,6 @@ class UserService
 namespace App\Controller;

 use App\Service\UserService;
-use Hyperf\HttpServer\Annotation\AutoController;

 class IndexController
 {
@ -64,7 +63,40 @@ class IndexController
 }
 ```

-> 注意调用方也就是 `IndexController` 必须是由 DI 创建的对象才能完成自动注入，Controller 默认是由 DI 创建的
+> 注意调用方也就是 `IndexController` 必须是由 DI 创建的对象才能完成自动注入，而 Controller 默认是由 DI 创建的，所以可以直接使用构造函数注入
+
+当您希望定义一个可选的依赖项时，可以通过给参数定义为 `nullable` 或将参数的默认值定义为 `null`，即表示该参数如果在 DI 容器中没有找到或无法创建对应的对象时，不抛出异常而是直接使用 `null` 来注入。*(该功能仅在 1.1.0 或更高版本可用)*
+
+```php
+<?php
+namespace App\Controller;
+
+use App\Service\UserService;
+
+class IndexController
+{
+    /**
+     * @var null|UserService
+     */
+    private $userService;
+    
+    // 通过设置参数为 nullable，表明该参数为一个可选参数
+    public function __construct(?UserService $userService)
+    {
+        $this->userService = $userService;
+    }
+    
+    public function index()
+    {
+        $id = 1;
+        if ($this->userService instanceof UserService) {
+            // 仅值存在时 $userService 可用
+            return $this->userService->getInfoById($id);    
+        }
+        return null;
+    }
+}
+```

 #### 通过 `@Inject` 注解注入

@ -74,7 +106,6 @@ namespace App\Controller;

 use App\Service\UserService;
 use Hyperf\Di\Annotation\Inject;
-use Hyperf\HttpServer\Annotation\AutoController;

 class IndexController
 {
@ -99,9 +130,45 @@ class IndexController

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

+##### Required 参数
+
+> Required 参数仅可在 1.1.0 版本或更高版本使用
+
+`@Inject` 注解存在一个 `required` 参数，默认值为 `true`，当将该参数定义为 `false` 时，则表明该成员属性为一个可选依赖，当对应 `@var` 的对象不存在于 DI 容器或不可创建时，将不会抛出异常而是注入一个 `null`，如下：
+
+```php
+<?php
+namespace App\Controller;
+
+use App\Service\UserService;
+use Hyperf\Di\Annotation\Inject;
+
+class IndexController
+{
+    /**
+     * 通过 `@Inject` 注解注入由 `@var` 注解声明的属性类型对象
+     * 当 UserService 不存在于 DI 容器内或不可创建时，则注入 null
+     * 
+     * @Inject(required=false) 
+     * @var UserService
+     */
+    private $userService;
+    
+    public function index()
+    {
+        $id = 1;
+        if ($this->userService instanceof UserService) {
+            // 仅值存在时 $userService 可用
+            return $this->userService->getInfoById($id);    
+        }
+        return null;
+    }
+}
+```
+
 ### 抽象对象注入

-基于上面的例子，从合理的角度上来说，Controller 面向的不应该直接是一个 `UserService` 类，可能更多的是一个 `UserServiceInterface` 的接口类，此时我们可以通过 `config/dependencies.php` 来绑定对象关系达到目的，我们还是通过代码来解释一下。
+基于上面的例子，从合理的角度上来说，Controller 面向的不应该直接是一个 `UserService` 类，可能更多的是一个 `UserServiceInterface` 的接口类，此时我们可以通过 `config/autoload/dependencies.php` 来绑定对象关系达到目的，我们还是通过代码来解释一下。

 定义一个接口类：

@ -131,14 +198,12 @@ class UserService implements UserServiceInterface
 }
 ```

-在 `config/dependencies.php` 内完成关系配置：
+在 `config/autoload/dependencies.php` 内完成关系配置：

 ```php
 <?php
 return [
-    'dependencies' => [
-        \App\Service\UserServiceInterface::class => \App\Service\UserService::class
-    ],
+    \App\Service\UserServiceInterface::class => \App\Service\UserService::class
 ];
 ```

@ -150,7 +215,6 @@ namespace App\Controller;

 use App\Service\UserServiceInterface;
 use Hyperf\Di\Annotation\Inject;
-use Hyperf\HttpServer\Annotation\AutoController;

 class IndexController
 {
@ -223,14 +287,12 @@ class UserService implements UserServiceInterface
 }
 ```

-在 `config/dependencies.php` 调整绑定关系：
+在 `config/autoload/dependencies.php` 调整绑定关系：

 ```php
 <?php
 return [
-    'dependencies' => [
-        \App\Service\UserServiceInterface::class => \App\Service\UserServiceFactory::class
-    ],
+    \App\Service\UserServiceInterface::class => \App\Service\UserServiceFactory::class
 ];
 ```

--- a/doc/zh/json-rpc.md
+++ b/doc/zh/json-rpc.md
@ -231,13 +231,11 @@ return [
 ```


-这样我们便可以通过 `CalculatorService` 类来实现对服务的消费了，为了让这里的关系逻辑更加的合理，还应该在 `config/dependencies.php` 内定义 `CalculatorServiceInterface` 和 `CalculatorServiceConsumer` 的关系，示例如下：
+这样我们便可以通过 `CalculatorService` 类来实现对服务的消费了，为了让这里的关系逻辑更加的合理，还应该在 `config/autoload/dependencies.php` 内定义 `CalculatorServiceInterface` 和 `CalculatorServiceConsumer` 的关系，示例如下：

 ```php
 return [
-    'dependencies' => [
-        App\JsonRpc\CalculatorServiceInterface::class => App\JsonRpc\CalculatorServiceConsumer::class,
-    ],
+    App\JsonRpc\CalculatorServiceInterface::class => App\JsonRpc\CalculatorServiceConsumer::class,
 ];
 ```

--- a/doc/zh/logger.md
+++ b/doc/zh/logger.md
@ -177,11 +177,9 @@ class StdoutLoggerFactory
 - 申明依赖, 使用 `StdoutLoggerInterface` 的地方, 由实际依赖的 `StdoutLoggerFactory` 实例化的类来完成

 ```php
-// config/dependencies.php
+// config/autoload/dependencies.php
 return [
-    'dependencies' => [
-        \Hyperf\Contract\StdoutLoggerInterface::class => \App\StdoutLoggerFactory::class,
-    ],
+    \Hyperf\Contract\StdoutLoggerInterface::class => \App\StdoutLoggerFactory::class,
 ];
 ```

--- a/doc/zh/quick-start/overview.md
+++ b/doc/zh/quick-start/overview.md
@ -236,15 +236,13 @@ class IndexController

 > WebSocket 和 TCP 等 Server 同理。

-`config/dependencies.php`
+`config/autoload/dependencies.php`

 ```php
 <?php

 return [
-    'dependencies' => [
-        'InnerHttp' => Hyperf\HttpServer\Server::class,
-    ],
+    'InnerHttp' => Hyperf\HttpServer\Server::class,
 ];
 ```

--- a/doc/zh/summary.md
+++ b/doc/zh/summary.md
@ -3,6 +3,7 @@
  * [项目介绍](zh/README.md)
  * [线上交流](zh/communication.md)
  * [捐献及赞助](zh/donate.md)
+  * [版本更新记录](zh/changelog.md)

 * 快速入门

@ -36,6 +37,7 @@
  * [自动化测试](zh/testing.md)
  * [视图](zh/view.md)
  * [国际化](zh/translation.md)
+  * [验证器](zh/validation.md)
  
 * 数据库模型

@ -98,3 +100,7 @@
  * [指南前言](zh/component-guide/intro.md)
  * [创建新的组件](zh/component-guide/create.md)
  * [ConfigProvider 机制](zh/component-guide/configprovider.md)
+
+* 版本升级指南
+  
+  * [1.1 升级指南](zh/upgrade/1.1.md)
--- a/doc/zh/upgrade/1.1.md
+++ b/doc/zh/upgrade/1.1.md
@ -0,0 +1,80 @@
+# 1.1 升级指南
+
+1.1 版新增了很多的功能，但一些改动也涉及到了对 Skeleton 骨架的调整，以及配置项的结构调整，如果您已经投入了业务使用的项目且是基于官方提供的 Skeleton 项目创建的 1.0 应用项目，那么可以根据下面的内容点来调整您的骨架项目，如果您是一个新的项目，按照文档通过 `composer create-project hyperf/hyperf-skeleton` 命令创建新的项目即可使用新的 skeleton 结构。
+
+## 升级 Swoole 到 4.4+
+
+1.1 版将最低的 Swoole 版本要求从 4.3+ 提升到了 4.4+，这两个版本之间有一些使用上的细节问题，Hyperf 已经在较早的版本便已适配了，对于 Hyperf 的用户而言无需理会这之间的差异，我们提升最低 Swoole 版本要求主要是为了减少我们的历史负担，而 Swoole 4.4 作为 Swoole 的 LTS(长期支持版本) 也意味着更加的稳定可靠。   
+
+Hyperf 在启动时会进行 Swoole 版本检测，但为了更好的统一各处对 Swoole 版本的依赖约束，我们建议您将 `composer.json` 内对 Swoole 的依赖条件改为 `"ext-swoole": ">=4.4"`。
+
+## 增加 SWOOLE_HOOK_FLAGS 常量
+
+在应用的入口文件 `bin/hyperf.php` 以及单测的入口文件 `test/bootstrap.php` 里增加一行常量定义如下：
+
+```php
+! defined('SWOOLE_HOOK_FLAGS') && define('SWOOLE_HOOK_FLAGS', SWOOLE_HOOK_ALL);
+```
+
+参考：[入口文件参考](https://github.com/hyperf-cloud/hyperf-skeleton/blob/70062b7bbf29e23cda2f30680e02aa3b26ebd6f7/bin/hyperf.php#L11) [单测入口文件参考](https://github.com/hyperf-cloud/hyperf-skeleton/blob/70062b7bbf29e23cda2f30680e02aa3b26ebd6f7/test/bootstrap.php#L20)
+
+## 移动 config/dependencies.php 文件并调整文件结构
+
+移动 `config/dependencies.php` → `config/autoload/dependencies.php`，并去除配置文件中的第一层 `dependencies`，如下：
+
+1.0 的文件结构：
+```php
+<?php
+// config/dependencies.php 文件
+
+return [
+    'dependencies' => [
+        FooInterface::class => Foo::class
+    ],
+];
+```
+
+1.1 的文件结构：
+```php
+<?php
+// config/autoload/dependencies.php 文件
+
+return [
+    FooInterface::class => Foo::class
+];
+```
+
+## 调整 config/container.php 文件的内容
+
+由于 1.1 版本调整了 `dependencies.php` 文件的位置和结构，所处我们还需要调整一下 `config/container.php` 文件，以便依赖注入容器能够正确的运行，与此同时，我们也为 `config/container.php` 提供了更加简便的写法，`DefinitionSourceFactory` 将很多默认的行为聚合了起来，您只需将 `config/container.php` 文件的内容更换成下面的内容即可：
+
+```php
+<?php
+/**
+ * Initial a dependency injection container that implemented PSR-11 and return the container.
+ */
+declare(strict_types=1);
+
+use Hyperf\Di\Container;
+use Hyperf\Di\Definition\DefinitionSourceFactory;
+use Hyperf\Utils\ApplicationContext;
+use Psr\Container\ContainerInterface;
+
+$container = new Container((new DefinitionSourceFactory(true))());
+if (! $container instanceof ContainerInterface) {
+    throw new RuntimeException('The dependency injection container is invalid.');
+}
+return ApplicationContext::setContainer($container);
+```
+
+## 调整 composer.json 的依赖
+
+由于要升级到 1.1 版本的组件，而原来 skeleton 项目默认情况下是依赖 1.1.x 版本的组件的，所以我们需要对依赖的约束条件进行一些调整，将原来所有 Hyperf 组件的依赖 `~1.0.0` 修改为 `~1.1.0`，修改完后需运行 `composer update` 来将依赖项升级到 1.1 版本。   
+
+必须将所有 Hyperf 依赖都升级到 1.1 版本才可用，因为 1.1 调整了组件适配的 ConfigProvider 机制。
+
+## 完成升级
+
+至此，1.1 升级即已完成，但由于 Hyperf 的各个底层文件都是可以通过 DI 来实现重写的，如您重写了某些本次升级调整到了的框架内部文件，您仍需再根据您的实际情况进行一定的调整。   
+
+如您在升级上或升级后遇到任何的问题，请前往 [Github Issue](https://github.com/hyperf-cloud/hyperf/issues) 提交您的 issue，说明您遇到的问题，我们会尽快帮助您解决。