swoole框架有哪些？怎么选择？

Swoole

swoole是实现各种协议及实现异步高性能的一个库，不是框架。包括上层的编程API和底层的hack，协程只不过是实现异步的一种方式。

基于Swoole，PHP开发者可以轻松快速开发出支持高并发的应用，比如即时通讯类应用，甚至游戏服务器，进一步拓宽了PHP的应用场景。

越来越多的PHP项目已经享受到Swoole带来的技术红利。基于异步协程库Swoole的PHP框架越来越多了。

Swoole Framework

目前基于Swoole的都有哪些框架：

TSF: 腾讯基于协程和Swoole的PHP服务器框架

EasySwoole: 企业级服务框架

PHP-MSF: Camera360基于Swoole的协程企业级微服务框架

ZanPHP: 有赞基于Swoole的PHP框架

SwooleDistributed: 基于Swoole的分布式通讯框架

Group-Co: PHP异步协程框架

Swoft: 基于Swoole协程的框架

MixPHP: 基于Swoole的次世代PHP框架

FastD: 一个支持Swoole的轻量级Web开发框架

QueryPHP: 渐进式PHP常驻框架引擎

Hyperf: PHP企业级微服务协程框架

选择哪一个Swoole框架

我们先来看swoole+php与go的比较：

CSP 模型：swoole 与 go 只差一个 select，go还有多线程协程 runtime.GOMAXPROCS，当然单线程又有单线程的好处，少考虑很多线程安全问题。

抽象能力：php5之后 与 java 比较接近，面向对象能力更好，设计模式更好运用，业务实现用php会更好，如果是做中间件使用go更好一些。

错误处理：php 的 try/catch/finally 虽然内置不足，且传统但可以少写不少处理异常的代码，异常不容导致服务停止，go 则在错误处理的粒度更精细一些，需要要更加细心处理每个异常错误，否则一不小心服务就挂了，php确实适合快速实现业务。

组件库生态：php 现有的库分 c 扩展和 composer 包，其中 composer 包中有一些使用了一些全局变量/方法，导致无法在协程中使用，而很多老的c扩展都没有考虑到异步的场景，导致很多细粒度的功能实现不了，还有使用单独网络库无法 hook 为协程的，而 go 所有的库都天然的可以用协程，并且是用本身 go 编写的，没有用到c，也便于调试修改源码。显然在生态方面java和go是很占优的。

类型系统：强弱类型自有各自的优势，强类型执行效率肯定高，弱类型比较自由灵活。

性能：swoole主要提供了websocket/长链接的服务、协程异步实现，而协程异步主要是异步IO，解决以往php只能同步IO带来的低效，但对于密集运算的话，swoole解决不了cpu这块效率问题。swoole通过协程把原php磁盘IO、网络IO的同步阻塞方式升级为异步不阻塞的方式，提高CPU利用率，加快请求处理。

我们需要基于swoole的框架吗？还是可用在第三方框架上加入swoole扩展，比如laravel或thinkphp的swoole扩展？

项目不大，用户量不大，那本身就不会遇到性能瓶颈问题，那还是用自己熟悉的传统的mvc框架即可，效率高，容错率好，易维护。

项目大，用户量大，并发大，公司只有php技术栈，那就先考虑前端优化（代码逻辑优化、加载优化、资源优化等）、负载均衡、后端优化（业务逻辑或算法优化、流量限流、异步队列等）、数据层优化（适当缓存机制、数据库读写分离、sql语句优化、数据库索引优化等）等等

为了进一步优化，及可能还会考虑更完整的分布式，数据库主从与集群、缓存主从与集群、消息队列集群，再考虑服务剥离，慢慢发展成为微服务架构，一方面提高性能，还提高开发测试部署效率。

而微服务常用的RPC、API（RESTful）技术，如果要求提高新能，显然客户端（后端业务客户端）需要支持异步实现，RPC服务端也需要支持异步，才能保证连接快速处理并结束，避免系统连接太多最后导致三高宕机。

选择Swoole框架，EasySwoole从文档上看虽然没有像Swoft、Hyperf看起来高大上优雅，但他提供了不少phper需要的composer包或库，比如微信、支付宝、jwt、spider等一些常用工具和sdk二次封装，显然会提升开发的效率；Swoft和Hyper重点核心在微服务和websocket。

目前对于web服务，除非新项目，允许试验，否则不建议使用基于swoole的框架实现http服务。

以上就是“swoole框架有哪些？怎么选择？”的所有内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，想要获取更多swoole教程或者资讯欢迎关注编程学习网