PHP程序员学习使用Swoole的理由
最近两个月一直在研究 Swoole,研究成果即将在6.21正式开源发布,这段时间没有来水文章,趁着今天放假来水水吧。
借助这篇文章,我希望能够把 Swoole 安利给更多人。虽然 Swoole 可能目前定位是一些高级 phper 的玩具,让中低级望而生畏,可能对一些应用场景也一脸懵逼,但其实没这么难的。
在 Swoole 官网的自我介绍是“面向生产环境的 PHP 异步网络通信引擎”,首先 Swoole 它是一个网络应用的开发工具,它支持 Http、TCP、UDP、WebSocket。
Swoole 和我们传统的 PHP 开发差别是有的,需要理解的概念也是有的。使用目前一些基于 Swoole 的框架开发的话,从开发习惯上和传统的TP、LV 框架相差不多。
那为什么要使用 Swoole?
宇润认为有以下几点:
常驻内存,避免重复加载带来的性能损耗,提升海量性能
协程异步,提高对 I/O 密集型场景并发处理能力(如:微信开发、支付、登录等)
方便地开发 Http、WebSocket、TCP、UDP 等应用,可以与硬件通信
PHP 高性能微服务架构成为现实
常驻内存
目前传统 PHP框架,在处理每个请求之前,都要做一遍加载框架文件、配置的操作。这可能已经成为性能问题的一大原因,而使用 Swoole 则没有这个问题,一次加载多次使用。
协程
如下图所示,这是同一个线程处理并发请求的场景,比如你某个接口中需要调用其它 api 接口或读写大文件,传统同步阻塞和协程异步的优势就体现了出来。
说到协程,就得先简单说说进程和线程,众所周知进程是很占用资源的,为了处理请求大量创建进程肯定是得不偿失的。而多线程应用就比较多了,在 CPU 层面有几个核心就会执行几个任务,线程一旦创建的多了,就会有线程调度的损耗。
协程是在单线程基础上实现的,它可以最大限度利用 CPU 资源,而不会在等待 I/O 时白白浪费。当然,协程数越多占用的内存也就越多,不过这个是可以接受的,相比进程和线程,占用的资源是相对较少的。
使用协程时,遇到读写文件、请求接口等场景,会自动挂起协程,把 CPU 让给其它协程执行任务,这样可以提升单线程的 CPU 资源利用率,减少浪费,从而提高性能。
协程代码示例:
<?php use Swoole\Coroutine as co; // 协程 $time = microtime(true); // 创建10个协程 for($i = 0; $i < 10; ++$i) { // 创建协程 go(function() use($i){ co::sleep(1.0); // 模拟请求接口、读写文件等I/O echo $i, PHP_EOL; }); } swoole_event_wait(); echo 'co time:', microtime(true) - $time, ' s', PHP_EOL; // 同步 $time = microtime(true); // 创建10个协程 for($i = 0; $i < 10; ++$i) { sleep(1); // 模拟请求接口、读写文件等I/O echo $i, PHP_EOL; } echo 'sync time:', microtime(true) - $time, ' s', PHP_EOL;
运行结果:
0 9 8 7 6 5 4 3 2 1 co time:1.0087130069733 s 0 1 2 3 4 5 6 7 8 9 sync time:10.010055065155 s
从上面结果可以看出,协程方式执行并不是顺序的,性能更高,在sleep时会把当前线程的任务执行权交给其他协程。
创建 Http 服务
其实也没想象中的难,看代码:
$http = new swoole_http_server("127.0.0.1", 9501); $http->on('request', function ($request, $response) { $response->end("<h1>Hello Swoole. #".rand(1000, 9999)."</h1>"); }); $http->start();
微服务
Tars是腾讯从2008年到今天一直在使用的后台逻辑层的统一应用框架TAF(Total Application Framework),目前支持C++,Java,PHP,Nodejs语言。该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案,帮助一个产品或者服务快速开发、部署、测试、上线。 它集可扩展协议编解码、高性能RPC通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体,通过它可以快速用微服务的方式构建自己的稳定可靠的分布式应用,并实现完整有效的服务治理。
最新评论