高并发的API接口选用什么PHP框架合适?

kimkit
  • 123

现在使用的是kohana。

回复
阅读 29.6k
26 个回答
✓ 已被采纳

可以考虑我写的 Blink Framework https://github.com/bixuehujin/blink,其设计意图便是用于构建高性能 API 服务。

Blink 是一个为构建 “long running” 服务而生的 Web 微型高性能框架,底层基于 Swoole 的 http server,性能有保障。

Blink 为构建 Web 应用程序提供简洁优雅的API,可扩展性好,允许开发者更加灵活自如的使用,提供了常见诸如路由、登陆认证、依赖注入、日志处理 等组件。

三种方案
1、大而全的框架
Yii laravel

2、轻路由框架
Lumen Slim

3、异步框架
ReactPHP
https://github.com/reactphp/react

考虑你的业务场景,业务场景复杂就用1,需要快速实现灵活度高可以尝试2、如果有大量IO操作的场景可以用3

谢顶道人
  • 4.4k

没有看到swoole的身影。实在忍不住出手。
要高并发,yaf实在是不合适。yar还稍微说的过去。
个人的建议是:
swoole + apache thrift

Yaf的其实本质上讲,是个基础框架,仅提供了一个简单粗暴的基础URI路由功能,完事了。
最关键是并发和多线程以及定时器等等,Yaf本身不能实现。
所以swoole这个时候,优势突显。swoole可以以deamon形式长期稳定的运行在server上,直接走socket,提供并发服务。
而集成了thrift后,就可以为各种其他端提供数据。比如app,web网页(这个时候,可以用yaf当作前端读取数据提供高性能),甚至为C,c++等端进行数据交互,非常方便。

yaf phalcon 都不错,c写的框架,性能上不错

huhuanming
  • 1.1k

高并发本质和框架是无关的。。。框架只是封装了一些组件,高并发还得看架构设计,异步消息队列怎么搞,缓存怎么搞,不能单单寄希望于框架,不然的话,最后你会发现加框架和不加框架会是一个效果。。

用你最熟悉的框架就好
高并发主要关注两点:
1,系统架构
2,业务逻辑 这个跟框架还算有点关系,不过关注点不在用什么框架

系统架构
主要是考虑的负载, 网络请求支持,运维轻松搞定,商量好方案,慢慢加机器就好

业务逻辑
这块做为开发人员,要知道业务本身压力是在数据库读写,文件读写
可以根据情况做缓存方案 和 异步处理方案

在真正的高并发下,程序逻辑本身和单点都会是瓶颈,做好负载均衡解决方案,才是支持无限增长高并发的终极解决方案

这和框架有多大关系?

eechen
  • 15.1k

高并发和框架无关吧

高并发的API性能取决于架构和缓存以及数据库!!!和框架没任何关系!!!

PHP 框架, 本来解决的问题就是开发效率, 相比 JAVA, C/C++ 来说, PHP 的执行效率够慢的, 框架还是一堆代码构建于 PHP 之上, 所以追求极致性能的话, 不建议用 PHP 来做

一般高并发php充当的是中间层的角色,java做一些基础架构会包掉大部分逻辑,所以其实php也就是从后端拿数据做这些数据的定制化给前端,并做一些鉴权处理,所以其实做的是接口包装的事情所以可以选择一些轻量高效的,如果考虑学习成本可以试着用类似于slim这种简单的框架,如果团队够强直接上鸟哥的yaf,还有一种场景就是php即是子应用也是服务,也就是soa的服务部分不是java了而是用了世界上最好的编程语言php那么他们之间的通信就是一个大问题,好在鸟哥还有一款yar的好东西,所以据了解微博用的就是yaf,yar,我不是微博的所以多了也不知道了,不过选什么根据自己的场景做个分析吧,不能拷贝其他公司的模式的

一般瓶颈不在PHP,在IO。所以选什么不重要。重要的是熟悉。出现问题,能快速修复

必须是鸟哥的yar

为什么逗谈框架

可以用yaf,推荐搭建hhvm或者php7 。

io密集型的高并发应该用epoll模型将并发调度到io层,然后就是进行db的设计了,理论上跟cgi关系不大了。如果你说的是CPU密集型的高并发请忽略我的回答

我要是说YII2会不会被打?

yaf 或者 lumen

Swoole+Lumen

基于Swoole加速Lumen,开发效率和性能二者兼得。

LaravelS

宣传栏