swoole框架选择

1、需求背景

目前在开发过程中因需要调用其他第三方的接口，但是第三方的接口功能存在一些局限性，比如：

数据一次只能获取10条，但业务实际需要展示30或40条
没有根据数据id获取收藏状态的接口，但列表上却需要展示收藏状态

并且数据在第三方app上用户还有可能更新，将数据完全存在本地也不合适。因此想对接口数据做预获取。想到了利用swoole的异步、监听事件及并发处理的特性。

因此想选择一个swoole的框架，目前是只针对这个需求使用，后续别的需求也有可能会用到。

2、框架选择思考

为什么要使用框架，使用框架的目的是什么
什么样的框架才是好的框架

个人认为在选择框架时首先要明确这2个问题，心中定义一个标准，如此才能选择出合适的框架。对于这2个问题，我先说下自己的看法。

为什么要使用框架，使用框架的目的是什么

使用框架的目的在于简化开发，让我们不必将精力用于路由、配置、加载文件等这些基本的处理方面，将精力专注于业务、专注于我们要完成的功能。所以说框架只是一种工具，关键看我们用得是不是顺手。

什么样的框架才是好的框架

窃以为，好的框架不是说在github上有多少star、多少fork。而应该是，首先框架能够满足使用要求，和项目本身要建立的架构是匹配的；其次框架应该是具备很好的扩展性，能够满足业务不断变化的需求；再者，就是框架应该是易于理解的，甚至是源码能够容易读懂和改进的，对于框架引起的报错能够比较容易的解决，否则如果框架本身就很复杂，使用框架没有达到简化开发的目的，反而成了一种负担，那这便违背了使用框架的初衷。

3、框架备选方案

1、swoft

https://github.com/swoft-cloud/swoft （star：4.7k fork: 721）

swoft 偏向 java 的注释型写法，适合有java背景。

Swoft 能像 Go 一样，内置协程网络服务器及常用的协程客户端且常驻内存，不依赖传统的 PHP-FPM。有类似 Go 语言的协程操作方式，有类似 Spring Cloud 框架灵活的注解、强大的全局依赖注入容器、完善的服务治理、灵活强大的 AOP、标准的 PSR 规范实现等等。

Swoft的注释路由AOP实体Bean等都明显源自于Java，个人感觉Swoft框架很全面，而且组件化的设计让他系统结构清晰而且很好选择使用所需的模块。但是太不PHP了，开发个人感觉是不敏捷的

文档：https://www.swoft.org/documents/v2/quick-start/directory-struct/

2、easyswoole

https://github.com/easy-swoole/easyswoole (star: 3.3k fork: 436)

EasySwoole 是一款基于Swoole Server 开发的常驻内存型的分布式PHP框架，专为API而生，摆脱传统PHP运行模式在进程唤起和文件加载上带来的性能损失。 EasySwoole 高度封装了 Swoole Server 而依旧维持 Swoole Server 原有特性，支持同时混合监听HTTP、自定义TCP、UDP协议，让开发者以最低的学习成本和精力编写出多进程，可异步，高可用的应用服务。

easyswoole更像是一个为了便于开发的助手类，框架的上手难度低，适合团队快速适应，如果你的项目不是很复杂，有希望精简快速的开发，es是一个不错的选择

文档：https://www.easyswoole.com/Cn/Components/Component/waitGroup.html

3、hyperf

https://github.com/hyperf/hyperf (star:2.3k fork: 401)

hyperf 偏向 laravel 的写法，适合有laravel背景

对于hyperf，是swoft开发组中的几位的成员出来开发的一个框架，也是拥有了swoft优秀的基因基础上，不再强制注释，集成大量企业级开发的组件，hyperf的入门难度是有的，环境的部署最好使用docker，对于初学的小白来说，需要花费一些时间进行研究学习，对于团队的接受需要花费时间进行学习和消化，大型的集群项目相对来说比较适合hyperf。

文档：https://doc.hyperf.io/#/