Heim  >  Artikel  >  Backend-Entwicklung  >  高并发的API接口选用什么PHP框架合适?

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

WBOY
WBOYOriginal
2016-06-06 20:25:352969Durchsuche

现在使用的是kohana。

回复内容:

现在使用的是kohana。

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

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

2、轻路由框架
Lumen Slim

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

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

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

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

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

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

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

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

这和框架有多大关系?

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

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

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

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

高并发和框架无关吧

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

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

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

必须是鸟哥的yar

Yaf是鸟哥的成名作,要用框架又要追求高性能就用Yaf吧,据说百度内部用的也是Yaf的修改版.
Yaf最新版本是2015-09-06发布的2.3.5:
http://pecl.php.net/package/yaf
http://php.net/manual/zh/book.yaf.php

lumen.

Swoole

php7...

为什么逗谈框架

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

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

我要是说YII2会不会被打?

yaf 或者 lumen

公司目前用yaf

BulletPHP

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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn