Lumen + Swoole 探坑小记

注意:本文以 Lumen 为对象进行写作,部分内容适用于 Laravel 但考虑到 Lumen 和 Laravel 在部分实现上有所差异,所以不保证本文提到的内容都也适用于 Laravel。本文写作时间点 Lumen 的版本是 v5.7.4 ,laravel-swoole 的版本是 v2.5.0。
考虑到随着未来版本的更新,部分特性会发生变化,所述内容仅供参考。

Swoole 是一个已经被广泛验证过的生产级别的PHP高性能异步网络框架,其近期逐渐完善的协程特性,更是极大提高了编码的体验。

目前查到这方面的文章大多数 Swoole 非常好 , Swoole 的运行机制能够大幅改善 Laravel、Lumen 的性能,让我们一起装一下 Swoole ,引入一个库,Webbench 对比看一下吧。

但实际上手完成应用,而不仅仅是一个 echo server ,就不是这么美好的事情,将 Swoole 集成到先有的应用系统中,也不仅仅是单靠引入一个库就能完成的。因此作为探坑学习,相对来说轻量级,并不包含过多组件的 Lumen 就是一个不错的选择。

要玩 Swoole 首先还是需要为 PHP 安装 Swoole 扩展,Linux环境下,可以直接使用PECL进行安装。当然,考虑到环境的复杂性,最省心的做法还是使用 Docker。

目前为 Lumen 增加 Swoole 支持的库有 laravel-s 和 laravel-swoole 两个,由于laravel-s 方案默认关闭并且不推荐开启协程,因此这次探坑选择了 laravel-swoole 方案。

在开始探坑前,首先还是需要了解一下 Swoole 的运行机制,以及 laravel-swoole 这个库到底做了什么。这边借用 laravel-swoole 的 Wiki 上的图。

Swoole 服务 通过自行PHP脚本启动之后,Swoole 会创建主要的反射器和管理器,进行管理调度,其中 主反射器 的工作模式和 Nginx 类似。而管理器则用于调度 Woker 和 Task Worker。而实际请求处理逻辑则是在 Worker 里面完成的。

对于 Lumen 来说,它的 Application 会在 Worker 启动时被创建,并且常驻内存,而不会每次接收请求都重新创建,这会有很好的性能,但问题也显而易见,原先我们并不管新的 全局属性、类的静态属性、单例 都会成为问题。

对于 Lumen 来说,其核心的特性,则在于 Service Container,Container 中的单例不会重新创建,每次请求是复用之前的,那之前的请求过程势必会引入很多污染,这些污染如果不清理的话,被带入到之后的请求,就可能引起后面请求的结果和预期不一致。但作为最大单例的 Application 如果清理掉,重新创建的话,那就失去了其加载常驻内存的意义了,因此 laravel-swoole 库采用的方式是引入了 沙盒 Sandbox。

Sandbox 机制 与 静态访问安全

在前面提到 常驻内存 需要格外注意的有 类的静态属性 ,那是不是我们自己写的类注意了就好呢,并不全是,因为在 Lumen 实现本身,也再使用静态属性。最典型的地方便是 Container 和 Facade 。Lumen 借助 Container 类的 静态属性 $instance 实现单例。而 Facade 则使用 静态属性 $app 保存 Application 实例,使用 $resolvedInstance 保存已经通过 Container 解析好的 Facade 实例。

那么 laravel-swoole 的 Sandbox 机制是怎么运作的呢,首先 Swoole 实际请求执行都是在 Worker 中执行的,laravel-swoole 在 Worker 被创建时,创建了 Sandbox 并且对 Lumen 的 Application 进行了初始化,同时预解析了一些常用的,同时不会因为不同请求处理之间会产生污染的 单例,这个预解析部分在其配置文件中是可以配置的。

接下来对于每一次请求来说,Sandbox 都会克隆一个已经创建好的 Application 的副本,并且通过预设的 重置器(Resetter) 对确保克隆的 Application 内已经创建的单例如果有已经绑定 Application 的,重新都绑定到当前克隆后的 Application 上,接着由这个克隆后的副本来处理本次请求的内容。这样看着很完美,但还有什么需要注意的呢,那便是前面说的 Lumen 的静态属性。Container 和 Facede。静态属性在同一个 Worker 中是公共的,不会因为不同请求有 独立的 Application ,静态属性就能被隔离。这个问题无解的话,laravel-swoole 目前的做法是在每一次创建时把当前的 Application 设置到 Container 的 $instance 上,同时清空 Facade 的 $resolvedInstance 。这对于同一时间一个Worker只处理一个请求来说是没问题的,但是 Swoole 的协程特性,使得在协程切换时,Worker 是可以接受并处理下一个分配的请求的。这就使得但凡涉及到 访问 Container 单例 和 Facade 进行服务解析都需要被格外注意。而最典型的就是 服务扩展,以及最为敏感的每次服务的鉴权问题。

对于 Lumen来说,Lumen 提供 app 帮助函数进行的服务解析依赖于 Container 单例,而不管使用哪个 Facade 都依赖于 Facade 的静态属性,因此这两种使用方式是需要被注意的。

比较多见的一种情况是在 Service Provider 中对 某个 Application 的 AuthManager 扩展了 guard 或者 guard driver。但如果使用时,通过Container得到的 AuthManager是新创建的,没有被 Service Provider扩展,则可能会遇到 guard 或者 drive 找不到的错误。

Auth guard [{$name}] is not defined.
Auth driver [{$config[‘driver’]}] for guard [{$name}] is not defined.

laravel-swoole 的文档的 Debug Guideline 会建议,如果遇到授权问题时,需要检查每一次请求的 AuthManager 是不是会被重新解析。但是不是重新解析的关键并不是解析本身,而是何时使用何种方式触发解析,怎么样才是安全的。

前面提到 Sandbox 对于 每一个请求 都会创建一个对应的 Application 的副本,Lumen 的 Application 也充当 Service Container 的功能,因此对于每一个请求都需要单独解析的服务类来说,使用 请求本身的 Application 副本 而不是 公共的 Container 单例、或者 Facade ,是一个相对来说安全的做法。

对于 Service Provider 来说,如果需要获取请求本身的 Application 副本,做法是将 Service Provider 添加到 laravel-swoole 配置文件中的 providers 中,从而laravel-swoole在每次重置 Application 的时候,会重新把新的Application关联到 Service Provider 中,并重新执行 Service Provider 。而在 Service Provider 中,则需要使用 $this->app 来访问被重新关联上的当前请求的  Application 副本。

对于其他类来说,如果需要获取请求本身的 Application 副本,那么最常见的做法就是在构造函数接受参数中接受 Application,并且使用 Application 副本的 Service Container 进行解析,通过依赖注入的方式进行获取。

当然,对于全局公共的,并不涉及到限定于本次请求的类来说,保持原来的方式,不管是用 Sandbox 一开始初始化的 Application 中获取,还是从 某一次请求的 Application 中获取,都是没有问题的。

MySQL 中 ONLY_FULL_GROUP_BY 模式

ONLY_FULL_GROUP_BY 对 GROUP BY 查询的限制

在 SQL 中 利用 GROUP BY 聚合 可以起到将字段相同的记录合并的目的。但也常常被滥用,以及使用不当出现结果与预期不一致的情况。

在 sql_mode 中提供了 ONLY_FULL_GROUP_BY 用以限制在 select 字段中 使用 group by 之外的字段 但没有使用聚合函数的情况。

例如:

select type, price from products group by type 

结果根据 type 聚合,但 price 未使用聚合函数,在未开启 ONLY_FULL_GROUP_BY 的情况下 mysql 会依照聚合顺序 返回默认的结果,而开启之后,则会返回错误:

ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column ‘db.tbs.price’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

当前所使用的 sql_mode 可以使用 show variables 查看

show variables like 'sql_mode';

MySQL 5.7 新增 ANY_VALUE()

从 MySQL 5.7 版本开始 默认将 ONLY_FULL_GROUP_BY 设置为启用状态。因此 如果依旧按照原先的方式进行查询 将会出现错误,在开启 ONLY_FULL_GROUP_BY 时 如果对非 GROUP BY 字段需要获取同原先一样的结果,5.7 版本开始则提供了一个 ANY_VALUE() 函数:

select type, ANY_VALUE(price) from products group by type 

Laravel 的 strictMode

对于 Laravel 框架 在 config/database.php 文件启用严格模式(strict 为 true )时 ONLY_FULL_GROUP_BY 设为启用状态

strict 为 true
strictMode 下启用 ONLY_FULL_GROUP_BY

如果使用的 MySQL 版本高于 5.7 则 优先考虑使用 ANY_VALUE() 函数
如果还在使用低版本 MySQL 又不方便升级,可以考虑将 strict 设为 false 关闭 strictMode

基于Docker 项目PHP环境运行 Composer 并使用国内镜像源

使用Docker可以快速在不同机器上运行构建好一致的运行环境,越来越多的被用在项目生产中。而 Composer 基本是PHP开发必不可少的包管理工具。

但在实际PHP开发部署过程中,Composer对于环境与依赖的判断源自于运行Composer的PHP环境,不同的运行方式,对于Composer的执行情况产生运行。

因为Composer限制root权限运行,因此Docker容器并不能直接shell运行Composer,如果直接在本机安装 Composer ,那么则依赖于机器本身的 PHP 环境,而使用Composer官方的镜像,则基于构建源的PHP版本环境。而在项目开发中,为了保证可靠,还是应用使用与项目一致的 PHP环境来运行 Composer。

首先 为项目 PHP 的 Dockerfile 增加 Composer 可以直接使用 Docker 的 multi-stage 功能直接从官方源复制

FROM php:7.1-fpm # 或者指定你自己build好的镜像
#
# .... 自身项目PHP环境配置 ... 建议直接基于已经 build 好的镜像
#

# 增加 TINI (这里直接使用二进制 也可以使用镜像对应的包管理安装)
ENV TINI_VERSION v0.17.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /sbin/tini
RUN chmod +x /sbin/tini

# COPY composer
ENV COMPOSER_ALLOW_SUPERUSER 1
COPY --from=composer:1.6 /usr/bin/composer /usr/bin/composer # 在镜像中增加 composer
COPY --from=composer:1.6 /docker-entrypoint.sh /composer-entrypoint.sh
WORKDIR /app
ENTRYPOINT ["/composer-entrypoint.sh"]
CMD ["composer"]

build 镜像 并标记 tag

docker build -t my-composer ./

在本地创建持续存储 composer 全局数据目录

mkdir ~/.composer

配置本地 .bash_composer 环境增加 composer 命令运行

composer () {
tty=
tty -s && tty=--tty
docker run \
$tty \
--interactive \
--rm \
--user $(id -u):$(id -g) \
--volume $(pwd):/app \
--volume $HOME/.composer:/tmp/composer \
-e "COMPOSER_HOME=/tmp/composer" \
my-composer "$@"
}

在 .bash_rc 或者引用 .bash_composer 文件,使用 source 命令引入

. "~/.bash_composer"

开始使用,并且配置中国镜像

composer config -g repo.packagist composer https://packagist.laravel-china.org

有顶天家族 舞台巡礼 Part.A

第一次来京都是在三年以前,走马观花转了很多热门景点,但对于这个传统和现代结合得很好的城市,依旧充满着诸多向往,但并不知道什么时候还能有机会再来。而看完「有顶天家族」之后,更是对于森见老师刻画下的古都更加的喜爱,「一定要再去看看」就算这么说,出远门总会想着要有一个主题,那么这次的主题大概就是「おもしろき古都は、良きことなり 」

拖了不知道多久的巡礼 report 毕竟是故事的舞台 处处都是实景 也不愧是京都旅游指南的(X

努力整理好了一部分 就先把 part A 发出来了

京都站

抵达京都之后首先当然是 JR京都站啦

出柳町车站附近

有顶天家族的巡礼 首先当然是要拜访 下鸭神社啦 乘坐电车前往下鸭神社 出柳町应该是最近的车站了

母亲大人常去的台球厅也就在这附近

出柳町商店街
司津屋

沿着商店街前行就能看到 笨蛋2兄弟伪装成的面馆 竹林亭的原型

继续阅读有顶天家族 舞台巡礼 Part.A

贪玩的 2016 的小结

比起前些年多多少少能有着些许成绩,2016年倒是相对平淡的,平淡到了作年终总结的时候,大概是要好好检讨检讨,这过去的一年到底都在干些什么,恩,也许就像标题所述主要就是贪玩吧 XD

游戏

如果非要说做了什么的话,那大概还是要把和同伴一块儿从2015年下半年开始到2016年中完成的游戏「Outbreak: Legacy」翻出来了吧,游戏的具体情况之前也简单写过一些介绍。以此为契机,接着IndiePlay的提名,暑假的时候去了趟魔都,感受了一下国内独立游戏的氛围,也体验了不少很有意思的独立游戏,顺带也见了见在魔都的朋友,虽然确实游戏还有很多做得不够的地方,也没有拿上奖,不过有这么一段经历,还是觉得十分开心。

电影

虽说电影已经是很多人的日常,但是平时基本都是SOLO状态,再加上国内上映的也没有什么特别喜欢的片子,所以过往电影看的是真不多

但想想2016年还真是看了不少片子呢,不管说是争议很大的tri,动作片的柯南,还是话题作的君名。也满心激动的感受了零点场以及初日舞台。

不管怎么说在大荧幕上看喜欢的作品,思来念去很多年,2016年真是很满足,希望未来在国内也能看到越来越多喜欢的片子呢,恩,如果还有人可以一块儿就更好了(想多了

旅行

想想这一两年,基本也都会有些出门的机会,所以这次出行在考虑行程的时候就想想除开常规路线之外还有什么特别的地方。于是决定去大山里探险,去了惦记了许久的狐狸村,和狐狸来了次近距离接触。

不管是躺着的“尸体”还是懒散的散步,亦或者打起架来,都好可爱 XD 以后有机会的话,还想换个季节再去转转呢

 

 

继续阅读贪玩的 2016 的小结

Lumen 5.4 修改 PDO Fetch Mode

项目需要采用了 Lumen 来开发 RESTful API 但又有需要修改 PDO 的 Fetch Mode 的需求

由于 Lumen 文档并没有关于此的特别说明 便参照 Laravel 过往的做法试图配置 config/database.php 并不起作用

在 翻阅 Laravel 文档中关于 升级变更的说明时才提到 在几周前发布的 5.4 版本 中不再支持 在配置文件中自定义 Fetch Mode (其实本身 Laravel 也一直不推荐修改)

如果需要这么做的话 目前采用的方案是 监听 Illuminate\Database\Events\StatementPrepared 事件 进行配置

对应到 Lumen 中也是一样的 可以在 EventServiceProvider 的 boot 方法中 设置

use Illuminate\Database\Events\StatementPrepared;
public function boot()
{
// 修改 PDO Fetch Mode
Event::listen(StatementPrepared::class, function($event) {
$event->statement->setFetchMode( ... );
});

// 其他自定义监听事件
}

当然 如果之前没有启用 EventServiceProvider 的话 还需要在 bootstrap/app.php 启用

// 去除前面的注释
$app->register(App\Providers\EventServiceProvider::class);

先导者卡牌资料站

恩 又开了一个新坑 这次是和 THE一灭寂 合作完成的先导者卡牌资料站

#卡片战斗先导者# 在线卡牌资料非官方中文综合站·《先导者卡牌资料站》今日开始公开测试!
地址:http://vgcard.yimieji.com
设计&资料:THE一灭寂
开发:@smdcn
PC与手机浏览器两者均可使用!具备卡片搜索、卡片详情查看、规则释疑(此项暂未填写完毕)等功能!
目前为开放测试期间,希望大家积极向我们反馈使用后的意见或建议。我们在完善暂未完成的项目的同时,也会根据大家的反馈尽可能进行优化!谢谢大家的支持!

继续阅读先导者卡牌资料站

数码兽大冒险 tri 第一章 再会 圣地巡礼

不知道为什么就是非常执着于跑实景 大概每次去东京 台场都会是必修课了吧

跑归跑 拖延症拖了不知道多久一直没有好好整理 于是先对着 Tri 第一章 把舞台实景探访整理了出来

虽然跑了很多地方 但还是没太做好功课 还是缺了一些场景 以往以后还能有机会再去了

0-のぞみ橋
0
首先是第一章BD的封面 这个在 のぞみ橋 桥上拍的

接下来的内容也基本顺延着 第一章 的故事推进整理的

Part 1. 太一从台场家上学

1-のぞみ橋
1
太一从台场出发上学沿途 位置是 のぞみ橋台场侧
2-晴海大桥
2
太一从台场出发上学沿途 位置是 在 晴海大桥
3-%e6%99%b4%e6%b5%b7%e5%a4%a7%e6%a1%a5
3
太一从台场出发上学沿途 位置是 在 晴海大桥
4-%e6%99%b4%e6%b5%b7%e5%a4%a7%e6%a1%a5
4
太一从台场出发上学沿途 位置是 在 晴海大桥
5-%e5%ad%a6%e6%a0%a1
5
太一上学学校外景 位置在 月島

Part 2. 岳、光从学校回家

继续阅读数码兽大冒险 tri 第一章 再会 圣地巡礼

iOS 创意打砖块游戏「Outbreak: Legacy」

我们小时候都玩过弹珠打方块的游戏,在新的时代,打方块游戏又能有怎么样的变化呢,于是从环形轨道出发,便开始游戏制作的探索。于是经过了和小伙伴一块儿一年多的努力,我们的游戏「Outbreak: Legacy」(中文:OO弹球 – 新式环形打砖块)目前终于在苹果App Store发布啦,同时获得“本周新游”推荐。

「Outbreak: Legacy」是一款以新奇砖块嘉年华为主题的环形弹球游戏,通过融入超多的独特创新元素,探索在环形轨道上,操控挡板,反弹共多种技能各异的小球。游戏包含了5个不同主题、数十个精心设计的关卡、并设置了BOSS关与无尽挑战。

更多丰富内容欢迎大家来体验试玩,游戏 App Store下载地址:https://appsto.re/cn/jaCxcb.i

appstore

继续阅读iOS 创意打砖块游戏「Outbreak: Legacy」

忙碌中的 2015 小结

忙忙碌碌,转眼就到了2016,就想着是不是要为已经过去的2015记录点什么。大概是2014过得太过于精彩,进入研究生之后的2015留下的大概就是无止境的瞎忙吧。

米兰行

虽说14年底的时候就开始参与米兰世博相关的项目,但是没有想到15年初能有机会去了一趟米兰。世博会开展前的一周到的米兰,然后虽然基本都在园区里,但是最大的感受不是世博会的宏大,更多的是「这各种没有完工的节奏,这世博真的能按时开始嘛」当然,最后确实是在大罢工和恐怖袭击之后,大门都没有完工的情况下顺利开始了,开园第一天盛大的庆典还是让人欣喜不已。恩,虽然意大利生活节奏出奇的慢,不过意大利面还是很好吃的,每天早上必须的意式浓缩和巧克力蛋糕也超好评(其实就光顾着吃了

expo-staff expo-china expo-event

日本语能力考

虽然一直说自己在努力的学习日语,但是也就一直很缓慢,基本都在学了丢,丢了又捡起来的状态。在一堆学日语的同学里面基本是方面典型。于是乎今年下了狠心,先去考考就跟玩一样的N3试试吧。结果也算是在意料之中,虽然听力和读解基本是满分,不过文法非常惨淡的得了B。唉,还是需要好好努力,正儿八经的去考个N1神马的 orz

jlpt-n3

论文发表

看着曾经的同学一个个在国外期刊发表论文,然而我却一直没敢投论文,在被老师开导了下,试着投了《计算机教育》,虽然在国内都算不上核心,但是收到录用函的那时依旧还是相当兴奋,接着就是在编辑和老师的建议下的反复修改,也算是好好体会了下「论文是改出来的」。

继续阅读忙碌中的 2015 小结