PHP-FPM
1.1 传统Nginx+FPM架构
1.1.1 PHP-FPM 并发模型
图1.1.1 一个HTTP申请的流转过程在网络应用场景下，PHP并没有像Golang那样实现http网络库，而是实现了FastCGI协定，而后与web服务器配合实现了http的解决，web服务器来解决http申请，而后将解析的后果再通过FastCGI协定转发给处理程序，处理程序解决实现后将后果返回给web服务器，web服务器再返回给用户。PHP-FPM是经典的多过程并发模型，Master/Worker模型。Master过程与Worker过程之间不会间接进行通信，Master过程只负责Fork和治理子过程，网络申请由子过程解决，一个Worker过程同时只能解决一个申请。Master通过共享内存获取worker过程的信息，比方worker过程以后状态、已解决申请数等，当master过程要杀掉一个worker过程时则通过发送信号的形式告诉worker过程。
1.1.2 PHP-FPM 初始化启动 及 Worker 申请解决
PHP-FPM从初始化启动到Worker申请解决大略波及到以下步骤：fpm_init() Master读取php-fpm.conf文件初始化内存配置变量、创立管道、套接字、启动事件治理 fpm_run() Master过程fork出子过程后阻塞，worker进城去accept申请，执行php脚本(1)期待申请： worker过程阻塞在fcgi_accept_request()期待申请；(2)解析申请： fastcgi申请达到后被worker接管，而后开始接管并解析申请数据，直到request数据齐全达到；(3)申请初始化： 执行php_request_startup()，此阶段会调用每个扩大的：PHP_RINIT_FUNCTION()；(4)编译、执行： 由php_execute_script()实现PHP脚本的编译、执行；(5)敞开申请： 申请实现后执行php_request_shutdown()，此阶段会调用每个扩大的：PHP_RSHUTDOWN_FUNCTION()，而后进入步骤(1)期待下一个申请。
图1.1.2 php生命周期生成的语法树和opcode，同一个PHP脚本每次运行的后果都是一样的，在PHP-FPM模式下，每次申请都要解决一遍，是对系统资源极大的节约
1.2 Laravel框架的性能问题
laravel是fpm社区外面十分受欢迎的一款web框架，联合composer治理开发组件，能够帮忙开发者在框架提供的多种优良组件（ORM，Router，Middleware，Artisan等）和解决方案在PSR-4标准下高效的进行Web服务端开发。所以有人说，如果Wordpress让php焕发第一春，那么Laravel+Composer让PHP焕发第二春。尽管laravel框架开发起来简略高效，中文社区也十分沉闷，生态丰盛。然而用laravel开发的利用性能问题却始终被重复提及。造成Laravel性能问题的次要起因有以下几点：框架代码的深度封装，导致把fpm模式下框架启动须要加载大量类和文件的性能问题放大（须要new太多类，每次new一个类都要autoloader找到类所在文件再require）每一次申请都会将所有的路由和配置全副加在到内存中，即使这次申请可能用不到（这其实也要归咎于fpm一次申请完结后就会销毁内存的个性）在框架启动时会调用composer autoload，依照classmap、prs-4、psr-0等标准生成所有类的引入门路所以针对Laravel进行性能优化的方向也就是针对以上几点来进行的：服务器启用 PHP OPcache 扩大缓存 opcodephp artisan route:cache php artisan config:cache等缓存命令通过 composer install --optimize-autoloader --no-dev 初始化我的项目依赖，以便减速 Composer 定位指定类对应的加载文件，同时不装置开发环境应用的依赖
1.3 FPM架构的局限
并发模型带来的单台服务器性能局限只能开发HTTP服务器，如果须要WebSocket，TCP等其余协定的服务器怎么办服务解决中的内存状态无奈长久化，绝大多数只能开发无状态服务，有状态服务须要借助本地文件或者mmap形式来实现Swoole-PHP的高性能通信引擎扩大
2.1 什么是Swoole
Swoole 是一个应用 C++ 语言编写的基于异步事件驱动和协程的并行网络通信引擎，为 PHP 提供协程、高性能网络编程反对。提供了多种通信协议的网络服务器和客户端模块，能够不便疾速的实现 TCP/UDP服务、高性能Web、WebSocket服务、物联网、实时通信、游戏、微服务等，使 PHP 不再局限于传统的 Web 畛域。Swoole的呈现能够关上上述FPM所面临的局限Swoole是通过cli模式启动的常驻内存服务，通过本身提供的异步/协程服务端能够进步单机服务的并发性能（即使是同步I/O的服务性能也会有较大晋升）Swoole提供了多种通信协议的网络服务器，包含TCP、UDP、HTTP、WebSocket、MQTTSwoole提供该性能共享内存SwooleTable、过程间无锁计数器Atomic、过程间API等形式保障有状态服务过程间的同步底层hook原生PHP函数，使其可能更好的运行在协程server内（底层替换了ZendVM Stream的函数指针，所有应用php_stream进行socket操作均变成协程调度的异步IO）
2.2 如何应用Swoole
2.2.1 协程格调HTTP服务端
<?php
use Swoole\Coroutine\Http\Server;
use function Swoole\Coroutine\run;
run(function () {
$server = new Server('127.0.0.1', 9502, false);$server->handle('/test', function ($request, $response) { Co::sleep(1); $response->end("test");});$server->handle('/stop', function ($request, $response) use ($server) { $response->end("<h1>Stop</h1>"); $server->shutdown();});$server->start();});
2.2.2 协程格调TCP服务端
<?php
use Swoole\Process;
use Swoole\Coroutine;
use Swoole\Coroutine\Server\Connection;
//多过程治理模块
$pool = new Process\Pool(2);
//让每个OnWorkerStart回调都主动创立一个协程
$pool->set(['enable_coroutine' => true]);
$pool->on('workerStart', function ($pool, $id) {
//每个过程都监听9501端口$server = new Swoole\Coroutine\Server('127.0.0.1', 9501, false, true);//收到15信号敞开服务Process::signal(SIGTERM, function () use ($server) { $server->shutdown();});//接管到新的连贯申请 并主动创立一个协程$server->handle(function (Connection $conn) { while (true) { //接收数据 $data = $conn->recv(10); if ($data === '' || $data === false) { $errCode = swoole_last_error(); $errMsg = socket_strerror($errCode); echo "errCode: {$errCode}, errMsg: {$errMsg}\n"; $conn->close(); break; } //发送数据 $conn->send('hello'); Coroutine::sleep(1); }});//开始监听端口$server->start();});
$pool->start();
2.3 Swoole并发模型
Swoole服务端过程线程结图2.3.1 swoole_processSWOOLE_PROCESS 模式的 Server 所有客户端的 TCP 连贯都是和主过程建设的，外部实现比较复杂，用了大量的过程间通信、过程管理机制。适宜业务逻辑非常复杂的场景。Swoole 提供了欠缺的过程治理、内存保护机制。 在业务逻辑非常复杂的状况下，也能够长期稳固运行。长处：连贯与数据申请发送是拆散的，不会因为某些连贯数据量大某些连贯数据量小导致 Worker 过程不平衡Worker 过程产生致命谬误时，连贯并不会被切断可实现单连贯并发，仅放弃大量 TCP 连贯，申请能够并发地在多个 Worker 过程中解决毛病：存在 2 次 IPC 的开销，master 过程与 worker 过程须要应用 unixSocket 进行通信2.3.2 swoole_baseSWOOLE_BASE 这种模式就是传统的异步非阻塞 Server。与 Nginx 和 Node.js 等程序是完全一致的。BASE 模式下没有 Master 过程的角色，只有 Manager 过程的角色。每个 Worker 过程同时承当了 SWOOLE_PROCESS 模式下 Reactor 线程和 Worker 过程两局部职责。长处：BASE 模式没有 IPC 开销，性能更好BASE 模式代码更简略，不容易出错毛病TCP 连贯是在 Worker 过程中维持的，所以当某个 Worker 过程挂掉时，此 Worker 内的所有连贯都将被敞开大量 TCP 长连贯无奈利用到所有 Worker 过程TCP 连贯与 Worker 是绑定的，长连贯利用中某些连贯的数据量大，这些连贯所在的 Worker 过程负载会十分高。但某些连贯数据量小，所以在 Worker 过程的负载会非常低，不同的 Worker 过程无奈实现平衡。如果回调函数中有阻塞操作会导致 Server 进化为同步模式，此时容易导致 TCP 的 backlog 队列塞满问题。
2.4 Swoole Coroutine和 Go Goroutine的区别
swoole的协程须要再协程上下文中应用swoole的协程是通过hook底层php函数实现的，go是原生反对的swoole是单线程协程，同一时间只会调度一个协程，而go是多线程实现的<?php
$n = 4;
for ($i = 0; $i < $n; $i++) {
go(function () use ($i) { // 模仿 IO 期待 Co::sleep(1); echo microtime(true) . ": hello $i " . PHP_EOL;});};
echo "hello main \n";
\Swoole\Event::wait();2.5 Swoole 和 Go HTTP服务器性能比照2.5.1 压测代码Swoole HTTP 代码如下应用Swoole/Server 设置 2个worker过程$http = new Swoole\Http\Server("127.0.0.1", 9502, SWOOLE_PROCESS);
$http->set(array(
'worker_num' => 2, // worker process num));
$http->on('request', function ($request, $response) {
$response->end("test");});
$http->start();Go HTTP 代码如下package main
import (
"fmt""time""net/http""log")
func test(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "test") //这个写入到w的是输入到客户端的}
func main(){
http.HandleFunc("/test", test) //设置拜访的路由err := http.ListenAndServe(":9502", nil) //设置监听的端口if err != nil { log.Fatal("ListenAndServe: ", err)}}
2.5.2 压测命令wrk -t8 -c200 -d30s --latency "http://127.0.0.1:9502/test"2.5.3 压测后果Running 30s test @ http://127.0.0.1:9502/test
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.42ms 318.83us 11.60ms 75.70%Req/Sec 17.62k 1.70k 20.29k 62.75%Latency Distribution
50% 1.35ms 75% 1.58ms 90% 1.82ms 99% 2.29ms4222085 requests in 30.10s, 628.13MB read
Socket errors: connect 0, read 60, write 0, timeout 0
Requests/sec: 140262.55
Transfer/sec: 20.87MBRunning 30s test @ http://127.0.0.1:9502/test
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.29ms 0.90ms 33.35ms 86.15%Req/Sec 10.99k 1.74k 17.86k 71.76%Latency Distribution
50% 2.36ms 75% 2.70ms 90% 2.97ms 99% 3.50ms2632268 requests in 30.10s, 301.24MB read
Socket errors: connect 0, read 51, write 0, timeout 0
Requests/sec: 87441.90
Transfer/sec: 10.01MB注：压测后果上Swoole和Golang的差距次要体现在go是应用单线程eventloop解决IO事件，多线程实现协程调度，执行用户层代码swoole应用多线程eventloop解决IO事件，多过程执行用户层php代码Hyperf-基于Swoole的PHP协程框架Hyperf 的呈现是为了解决Swoole门槛高，上手难的问题。联合Composer组件，帮忙使用者以低成本打造一套高性能的灵便的应用服务。
3.1 Hyperf个性
Hyperf内置大量的协程组件，以保障申请不回进化到阻塞模式。Hyperf反对多端口监听，可同时启动HTTP和WebSocket端口反对jsonRPC，gRPC微服务配套设施（熔断、降级、配置核心、链路追踪、Metric监控等）因为是常驻内存的服务，所以引入连接池（Mysql、Redis、GuzzleHttp）ORM 基于Laravel ORM进行革新，从Laravel/Lumen 移植过去十分顺畅3.2 Hyperf框架外围3.2.1 依赖注入Hyperf/DI 是框架中治理对象类创立和依赖关系的组件，也是实现 注解 和 AOP 性能的要害。DI中治理的对象都是用于服务长生命周期的单例对象，短生命周期应用make()办法创立。根据创建对象的需要不同可分为以下三种注入形式简略对象注入形象对象注入工厂对象注入3.2.2 注解 和 AOPHyperf基于AOP和注解实现了诸多框架根底性能，如依赖注入 @Inject()路由定义 @AutoController()中间件 @Middleware(FooMiddleware::class) 缓存 @Cacheable(prefix="user", ttl=9000, listener="user-update")3.2.3 事件机制 和 生命周期Hyperf的事件机制存在于框架启动时，可能帮忙用户更好的和框架配合实现逻辑的解耦，例如DBqueryLisenner。在解决每个连贯时，会默认创立一个协程去解决，次要体现在 onRequest、onReceive、onConnect 事件，所以能够了解为每个申请都是一个协程，因为创立协程也是个惯例操作，所以一个申请协程外面可能会蕴含很多个协程，同一个过程内协程之间是内存共享的，但调度程序是非程序的，且协程间实质上是互相独立的没有父子关系，所以对每个协程的状态解决都须要通过 协程上下文 来治理。
最初这次分享不是不是为了比拟一个高下，不是说FPM模式下的开发方式和我的项目就不好，而是想表白fpm可能曾经不适宜当下谋求并发，尽可能榨取服务器CPU性能的要求了。Swoole在php原生语法简略高效的根底上，为php搭建了基于协程（异步非阻塞）的运行模式，再加上Hyperf这样组件化的成熟框架，使得上手Swoole不在艰难。让大家理解到这种开发方式的可能性就能够了。