来源 /腾讯课堂Coding学院(ID:ke_coding)
在FastCGI协议下工作的php-fpm, 使用持续的进程来处理一连串的请求, 具体到某个请求的解析流程的时候, 如果不考虑扩展的方式, 基本上都是顺序的解析处理.
所以就算复杂如Laravel框架, 他也是一个顺序的加载解析过程.
本地打断点可以完整的走一遍框架的加载逻辑. 但是你可能并不一定十分理解为什么框架要这么做? 或者他这一步究竟是干嘛的?
本文就尽可能的提取Laravel处理http请求过程中一些关键的路径跟大家分享一下Laravel框架工作的原理, 也方便后面大家自己排错或者对于框架进行改造.
首先跟大家说的是后续在解析源码的时候比较核心的两个东西(某种意义上我觉得也是Laravel框架的骨架)——Container和Pipeline, 一个负责各种类实例的管理, 另一个负责流程的配置, 理解清楚了这两个东西, Laravel框架的主体逻辑就会很好理解了. (如果之前已经有了解过的就可以略过了哈~)
后面会介绍到的Application类就是继承自Container的一个框架运行过程中的实例的大总管.
大概的意思就类似如下的代码:
所以后面在看源码的时候凡是看到类似$app->make等都是在向大总管要一个对应的类示例.
这里说的是Laravel作者taylor自己开发的Pipeline 不是thephpleague的Pipeline
但是这两个pipeline的库都是很好的抽象库——用来装配定义对于某个数据源的解析流程
我们看下laravel框架里的Pipeline的核心类Pipeline:可以看到该类实现了PipelineContract, 而该接口源码如下
那么这个接口主要描述的就是一个流水线需要实现的方法:
那么我们Pipeline类最终实现之后又有哪些调整呢?
先看下源码:
第一行: 调用getInitialSlice传入$destination得到最终车间对于$passable的处理方法$firstSlice
第二行: 倒转中间的$pipes的顺序
第三行的代码分开解析:
[第三行]$this->getSlice()
这里得到的是一个车间的堆栈$stack以及当前车间$pipe对于$passable的一个处理逻辑:
如果$pipe是个闭包, 则直接调用传入($passable, $stack)
如果$pipe是个对象, 则向大总管初始化, 然后调用handle方法处理($passable, $stack)
[第三行]array_reduce($pipes, $this->getSlice(), $firstSlice)
核心的概要可以看如下的代码:
那么很明显这里我们就能得到一个已经装配好的流水线——$this->getSlice()不断的将最终的目的处理逻辑$firstSlice以及$pipes压入这个处理流程的堆栈里面, 最后得到这个按照顺序的对于$passable的处理流程.
[第三行]return call_user_func( array_reduce($pipes, $this->getSlice(), $firstSlice), $this->passable);
最终将$passable放到这个流水线上处理并返回处理的结果
理解清楚了Pipeline之后我们下面分析源代码就会快了很多, 因为核心的逻辑都是依赖Pipeline来装配的.
这里就顺序的逐层来带大家看下Laravel的http请求处理流程.
对你没有看错, 其实Laravel处理http请求就这么”几行”代码:
$app = require_once __DIR__.'/../bootstrap/app.php';
这里引用这个文件得到一个Container的子类Application的示例,
同时app.php里面还声明了3个重要的抽象的实现
http请求的处理器Illuminate\Contracts\Http\Kernel::class实现为App\Http\Kernel::class
console(命令行)请求的处理器Illuminate\Contracts\Console\Kernel::class实现为App\Console\Kernel::class
异常Exception的处理器
$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);
之前只是配置, 这里是真正得到一个new好的实例
下面就是比较关键的代码了——处理器Kernel调用handle方法处理当前的请求$request得到\$response
我们从这个断点深入看下处理器的handle方法
App\Http\Kernel没有handle方法, handle方法逻辑在他的父类Illuminate\Foundation\Http\Kernel里面
大概扫了一眼, 正常逻辑的话其实就是这句——$response = $this->sendRequestThroughRouter($request);//将请求放到Router上面过一遍
所以我们继续挖:
这里就看到我们之前说的Pipiline的使用了——将请求$request放在可能有的$middleware中间件车间上处理, 最终送到$this->dispatchToRouter()上面处理, 那么这个最终的目的车间不难想到应该就是当前请求匹配到的路由规则了, 所以我们继续深挖:
这里利用了本身的router示例来进一步分发处理$request, 所以我们再新开一节看下Router是怎么处理请求的
sendRequestThroughRouter中使用的中间件就是配置在App\Http\Kernel的全局中间件
然后我们看下文档中关于中间件的用法说明就很清楚了:
不难发现, handle方法其实就是一个处理$request数据的车间, 调用$next($request)之后就进入到了下一个车间, 所以中间件其实就是嵌套处理的逻辑, 通过划分不同的层次实现逻辑解耦.
Router主要的职责就是找出匹配当前$request规则的路由并执行然后返回
继续看正常流程逻辑:$response = $this->dispatchToRoute($request);
附:
在$route = $this->findRoute($request);有一个我觉得可以优化的逻辑, 大家有兴趣可以去看下
通过$route = $this->findRoute($request);我们得到了匹配当前请求的路由规则,
然后调用runRouteWithinStack来实际解析当前的请求
没有眼花!又一个Pipeline的处理逻辑, 这里的逻辑的就是:
真正的进入到了大家平时可能编写的Controller的特定方法里面去解析了
这里的middleware就是大家路由里面可能会配置的非全局的middleware了
正常的逻辑下就从这两个Pipeline顺利返回了$response
然后调用$response->send()将响应返回给客户端, 之后处理器也停止运行.
一次http请求顺利走完了整个Laravel框架
这就是我眼中Laravel的骨架——Container+PipeLine 以及 在这个骨架上搭建起来的一个处理http请求的流水线!
Laravel简单吗?——简单, 他把框架搭好, 只需要我们填充自己的车间进去
Laravel复杂吗?——复杂, Container后面的实现, PipeLine的沉淀, 都不是一下子凭空就能构造出来的.
通过Laravel框架的设计回过头来看业务开发其实也是一样的道理, 利用尽可能的高度简单的抽象来概括某个领域, 然后将灵活多变的需求限定在这一个个”车间”里面.
业界最顶尖的技术大咖/最权威的实战分享/最前沿的行业资讯/尽在腾讯课堂Coding学院
原文来自: 腾讯课堂Coding学院
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
根据给定的手机号、姓名、身份证、人像图片核验是否一致
通过企业关键词查询企业涉讼详情,如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能,它提供IP地址历史上绑定过的域名信息。
结合权威身份认证的精准人脸风险查询服务,提升人脸应用及身份认证生态的安全性。人脸风险情报库,覆盖范围广、准确性高,数据权威可靠。
全国城市和站点空气质量查询,污染物浓度及空气质量分指数、空气质量指数、首要污染物及空气质量级别、健康指引及建议采取的措施等。