本一直想写些东西,却无从下笔。2017 年的总结立的 flag 还没完成,这一晃却已经是 2018 年年底了。难得今天没事儿,细细来回顾我这一年。

一月 工作

找了很久的工作,终于落地了。做 PHP 开发,定位中级,主要是二次开发和新功能开发。我所进入的产品组是独立于公司数信规则之外的项目组。

二月 结石、她、返程

二月份回家过年,本是喜庆的日子,却在大年初一的夜里结石发作,让这个年过得实在不踏实。初二一早祭祖的路上再次发作,撑到医院门口已经站不稳了,因为是过年,医院只有急诊有值班医生,排着长长的队伍。诊断过后,打了一剂解痉药,便回家蜷缩在被窝里了。

这里很感谢我的父母,在我疼得不省人事的时候一直照顾着我。这里还要感谢一位,我不知该如何介绍。

初四,向 HR 请了病假,返程的机票也退掉了。每天除了睡觉,别无他事。我如今每晚十点准时睡觉的规律作息时间和这次发病脱不了关系。

初七,本该是返程的日子,这天和家父上医院做核磁共振,因为我体内的结石 B 超、彩超 和 X 光一直都找不着,故父亲让我去做核磁共振看看能不能找到结石。上午做完核磁共振,下午取到结果,一颗小结石,已经掉下来了。

她是一个永远不可能的人。尽管相互爱慕,但挡在我们之间的是人生。

结石终于消停,在大年初七。买上返程深圳的机票,需要到云南转机。也目睹了云南的地貌。

云南

三月 DJ OKAWARI

这或许是唯一能让我悸动的音乐人,3 月 24 日在深圳的「后青年音乐节」终于见到了他,也解锁了第一次看现场演唱会的成就。

DJ OKAWARI

四月 搬家、赶项目

因为公司离家实在有点远,上下班在地铁上需要耗掉 3 小时。所以想着搬到公司附近。

找了很久的房子,不妨也有心仪的房子。期间也在自如和蛋壳上找过,看过房后发现刚装修后第一次出租。现在想起来真是庆幸没有租新房。

这次找房实属巧合,在某次看完自如的房后中午回公司在一旁的小卖部用泡面解决午餐的时候和店老板娘聊了一下,老板娘为了联系了一个房源,是她的儿媳妇儿租的房,打算租一间卧室给我,价格也挺好,离公司步行 10 分钟。Nice!

项目组临时立了一个项目,需要在六月前上线,需求不算太复杂,但是时间很赶,周末连着加了几次班。

五月 回家、Airpods、新域名

5 月初,回了一次家。因为春节回家结石发作的原因,丝毫没有体会到春节的气氛。反而这次回家心情好了很多,真的无病一身轻。

在各种测评上种草了 Airpods,故在狗东下单以¥999 的价格剁手一波。体验:外壳容易磨花,公司电磁干扰有点强,总是莫名奇妙的没声了。

wangmao.me 这个域名其实关注很久了,让我一直心里痒痒的另外还有一个 wangmao.io 的域名,贫穷让我选择了前者。

六月 新主题

六月的时候又写了一个主题,已经开源到 isecret/Hola,期间有朋友想要移植到 Typecho 联系了我,我很是开心,然后便没了后续。

七月 学习

在 PHP 框架里,Laravel 属于入门门槛较高的框架,我曾尝试看过几次文档,发现和之间所了解的框架思想都不太一样。在 慕课网Laravel China 逐步学习后慢慢的入门了。

在公司给我分配新项目,我框架选型也首次选用了 Laravel。这框架真是讨喜。

八月 一言 for Chrome

闲的蛋疼的时候写了一个 Chrome 的欢迎页。地址: isecret/hitokoto-newtabs,但是我想打包上架,谷歌开发者认证死活支付不了。

九月 修 Bug

人在家中坐,Bug 从天上来。

十月 新手机、信用卡

去年我哥给我送了一台 iPhone 6 32 G,如今有些吃力了,后台经常被杀掉。正好刚发售了 iPhone XR,我毫不犹豫的入手了——iPhone 7。贫穷再一次限制了我的购买力。

终于把我的信用卡激活了,这是一张广发银行的信用卡,是通过电话营销联系上我的,最开始额度只有 8000,我想着也不缺钱花加上附近没有营业网点则一直没有激活。直到最近短信告知我额度提升到了 12000。嗯?

十一月 戒烟

戒烟这件事儿从来都是一时心血来潮,强行逼着自己戒断 20 天后复吸,心里罪恶感让我感到羞耻。

后来入手了电子烟,RELX 的小烟,小烟与我之前对电子烟的认识有些出入,这款电子烟是抽烟弹。后来再也没碰过纸烟。

十二月 闲得慌

维护一个基于 OneDrive 的一个网盘程序 Oneindex,提交过几个 PR,除了一个修复代码风格的没有合并,其他都合并到了 master。不过这个 PR 作者并没有关闭,也不知道会不会合并,毕竟改动实在很大。

现状

前两天腹痛请了病假去医院检查,却又发现了双肾结石,左右各两颗。尼玛!

腹痛还没完全好,感觉不像是肠胃炎,再观察一下吧。另外医院给我开了几味药,其中有一味「左氧沙福星片」,本来一天吃一粒,结果下午吃过晚上又吃了一颗,看了过量症状是把我吓得不轻,有兴趣可以搜一下。

回家的票定好了,2 月 4 号到重庆,很想改到 2 月 3 号的,打电话问川航改签要多加很多钱。。

哦,对了,体重涨到了 140 了,我也不知道吃啥了。

Flag

年终总结从来都是立 Flag 的,有没有和会不会实现是两码事儿。梦想总要有的,万一实现了呢?

如下:

  • [ ] 跑步/健身让体重降回 135 左右
  • [ ] 学会游泳
  • [ ] 去一次香港
  • [ ] Github 贡献翻一倍
  • [ ] 熟练使用 Swoole

最后

这里年里成长了很多,技术和视野都有所见长。也不知道说些什么,那就给大家拜个早年吧。新年快乐~

Hello, 2019.

: )

紧接上次的 使用 Supervisor 守护 php-fpm 进程,在 Supervisor 控制台中能看见有 Nginx 的任务。这个任务并不是我加的,而是我拿到服务器就已经配好了,很可能是运维配置的。

今天调 Bug 的时候发现了问题,所以分为两篇来讲。

问题描述

上回使用 Laravel Admin 搭建了后台,功能看似一切正常,然而今天给同事演示导出功能的时候出了幺蛾子。问题也实在奇怪:当「导出当前页」能正常导出,「导出全部」则始终网络错误。

神操作

刚开始以为是 Laravel Admin 使用的 Excel 拓展类(maatwebsite/Laravel-Excel)的问题,将导出类替换为 league/csv,然鹅。我发现在测试环境无论是 Laravel-Excel 还是 csv 都能导出。也就是说我白忙活了半天?

日志!

一边安慰自己是在排除代码问题,一边去查看 Nginx 的错误日志。Nginxroot 用户安装的,查看日志必须加 sudo,忽然发现日志一直在输出错误:

2018/09/20 16:14:38 [emerg] 23817#0: bind() to 0.0.0.0:8800 failed (98: Address already in use)
2018/09/20 16:14:38 [emerg] 23817#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2018/09/20 16:14:38 [emerg] 23817#0: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/09/20 16:14:38 [emerg] 23817#0: bind() to 0.0.0.0:8800 failed (98: Address already in use)
2018/09/20 16:14:38 [emerg] 23817#0: still could not bind()

每秒都在输出,惊得我立马查看线上环境,然而一切正常。缓过神来,发现这个日志实在眼熟,我们是不是在哪儿见过?简直和 使用 Supervisor 守护 php-fpm 进程 的 php-fpm 的错误日志如出一辙啊。那我可大概知道是什么原因了。

查证

首先在 Nginx 中文文档 中找到 Nginx 主模块,找到 daemon 命令,官方给出的解释是:

语法: daemon on | off

缺省值: on

Do not use the "daemon" and "master_process" directives in a production mode, these options are mainly used for development only. You can use daemon off

大意:在生产环境中 daemonmaster_process 配置均不可使用,仅用于开发测试。

为了方便开发测试 Nginxdaemon 参数默认值为 on

然后找到 Nginx 的配置文件 /usr/local/nginx/conf/nginx.conf,检索 daemon 参数。然后是意料之中 Pattern not found: daemon

解决方案

第一种是直接在 nginx.conf 配置文件中增加 daemon off; 参数。

第二种则是在启动 Nginx 时追加命令,命令为:

/usr/local/nginx/sbin/nginx -g 'daemon off;'

由于线上环境 Nginx 配置文件由 Supervisor 守护,所以直接修改 supervisord.conf

[program:nginx]
command=/usr/local/nginx/sbin/nginx -g 'daemon off;'
directory=/usr/local/nginx
autostart=true
autorestart=true
redirect_stderr=true
priority=10
stdout_logfile=/data/logs/supervisord/nginx.log

修改后记得更新 Supervisor 以及重启 Nginx 进程,命令:

$ supervisorctl reread # 重新读取配置
$ supervisorctl update # 更新配置
$ supervisorctl restart nginx  # 重启 nginx
$ killall nginx  # 杀掉所有的 nginx 进程

至此 Nginx 日志终于消停下来,我也能慢慢的查问题了。

解决问题

如上文,解决完 Nginx 默认进程守护后,日志消停下来终于能看到报错信息。

错误日志:

2018/09/20 15:02:36 [crit] 3396#0: *10 open()
"/usr/local/nginx/fastcgi_temp/2/00/0000000002" failed (13: Permission denied)

看到 Permission denied 瞬间菊花一紧。

回想起来 Nginx 的运行用户是一个普通用户,对以 root 用户的目录确实是不可写的(Nginx 以 root 用户身份安装)。

找到 Nginx 的配置文件 nginx.conf,修改 user 参数为 root

重启 Nginx 后,导出功能正常。问题已经解决。

问题还原

但是,为什么会「导出当前页」能正常导出而「导出全部」就失败呢?刨根问底得去查 参考资料 找到解释:

先简单的说一下 Nginx 的 buffer 机制,对于来自 FastCGI Server 的 Response,Nginx 将其缓冲到内存中,然后依次发送到客户端浏览器。缓冲区的大小由 fastcgi_buffers 和 fastcgi_buffer_size 两个值控制。

Nginx 默认配置如下:

fastcgi_buffers      8 4/8K;
>
> fastcgi_buffers 控制 nginx 最多创建 8 个大小为 4K 的缓冲区,而 fastcgi_buffer_size 则是处理 Response 时第一个缓冲区的大小,不包含在前者中。所以总计能创建的最大内存缓冲区大小是 8*4K+4K = 36k。而这些缓冲区是根据实际的 Response 大小动态生成的,并不是一次性创建的。比如一个 8K 的页面,Nginx 会创建 2*4K 共 2 个 buffers。
>
> 当 Response 小于等于 36k 时,所有数据当然全部在内存中处理。如果 Response 大于 36k 呢?fastcgi_temp 的作用就在于此。多出来的数据会被临时写入到文件中,放在这个目录下面。

也就是说,当前几台服务器上的站点,一旦响应的数据超过 36 KB 超出的部分将写到 *fastcgi_temp* 目录,如果 *fastcgi_temp* 不可写的话将只返回前 36 KB 的内容,难怪手动将分页条数参数给到 *1000* 页面不完整。

## 参考资料

- [分析 fastcgi_temp 错误以及 Nginx 的 Buffer 机制](https://blog.csdn.net/crx05/article/details/70210323)

记一次被虐的经历

大概一年前左右,在一次面试的时候面试官问到了我跨域相关知识面。我当时错误并执拗的认为跨域请求是服务器响应的原因,因为在解决过程中增加一些 header 信息便能解决问题并没有深入的去探索过。面试当然挂了,而且感觉很丢脸。o(////▽////)q

在后来的开发过程中,遇到过不少跨域请求的问题。解决方式无非依葫芦画瓢,Ctrl + CCtrl + V 解决。

大概这样子:

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: *');
header('Access-Control-Allow-Methods: *');

我不知道各个参数的含义,但对于结果来说,确实能解决问题。

难得有空,在学习 Laravel / PHP 扩展包视频教程 时,无意发现了一个关于解决跨域的拓展 barryvdh/laravel-cors文章 (012. 解决跨域问题( CORS )——barryvdh/laravel-cors) 很好的解释了 CORS 及同源策略。

同源策略

同源策略一般是指浏览器的基本安全功能。同源的含义为:域名,协议,端口都相同。如果两个地址不同源,那么:

  1. CookieLocalStorageIndexDB 无法相互读取;
  2. DOM 无法相互获得;
  3. AJAX 请求不能相互发送。

其实这里不太准确,因为跨域请求并不能限制发送请求,有可能跨域请求能正常发起,只是结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击。参考:HTTP 访问控制(CORS)

跨域资源共享(CORS)

CORS 全称 跨域资源共享(Cross-origin resource sharing),是一种解决浏览器跨域问题的方法。CORS 请求 常用 的为两种,分别为:简单请求预检请求

简单请求

简单请求是指 不会触发预检请求的被称为简单请求,不触发的条件如下:

  • 使用以下请求方式之一:

    • GET
    • POST
    • HEAD
  • 同时请求头中不得设置以下字段之外的参数(CORS 安全的头部字段):

    • Accpet
    • Accpet-Language
    • Content-Language
    • Content-Type(仅限于以下值)

      • text/plain
      • multipart/form-data
      • application/x-www-form-urlencoded
    • DPR
    • Downlink
    • Save-Data
    • Viewport-Width
    • Width
  • 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器;XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问。
  • 请求中没有使用 ReadableStream 对象。

预检请求

预检请求是指在发送真实请求之前会向目标地址发送一个 OPTIONS 请求,用来从服务器获取获取头部信息。预检请求将携带头部信息 Access-Control-Request-MethodAccess-Control-Request-Headers,分别用于告知服务器当前的请求方式和自定义头部信息。

预检请求响应后,服务器将返回 Access-Control-Allow-Origin 用于告知浏览器允许请求的域,* 代表所有,Access-Control-Allow-Methods 用于告知浏览器允许请求的方法,Access-Control-Allow-Headers 用于告知浏览器允许携带的头部信息,Access-Control-Max-Age 表示预检信息的有效时间,在这段时间之类浏览器无需为同一请求发起多次预检请求。当预检请求通过后,再发送真实请求。

题外话

除了使用 CORS 来解决跨域问题,常规操作和曲线救国的操作我也收集了一些。

分为两种情况:对目标服务器有控制权限对目标服务器没有控制权限

有控制权限

有操作权限就很简单,除开上文所讲的 CORS 解决方案外,还有一个解决方案为:JSONP,是利用加载外链资源加载目标服务器内容,JSONP 不属于 AJAX 请求,所以不需要遵循同源策略。

一个简单 JSONP 的实现。

// getLocation.php
<?php
echo "var __IP ='$_SERVER['REMOTE_ADDR']';";

// home.html
...
<script src="getLocation.php"></script>
<script>
    console.log(__IP);
</script>
...

当然,你还可以在服务器端输出回调地址,使前端调用时能拉起回调(callback)。

// getLocation.php
<?php
$callback = $_GET['callback'];
echo "$callback($_SERVER['REMOTE_ADDR']);";

// home.html
...
<script>
    function say(something) {
        console.log(someting);
    }
</script>
<script src="getLocation.php?callback=say"></script>
...

没用控制权限

对于没有控制权限的,还想使用目标接口的,我能想到的只有通过服务器做转发。原理为:前端请求转发服务器,由转发服务器采集接口内容,然后通过 CORS 返回。绕来绕去又回到了 CORS

上回的 Laravel 应用开发完成上线之后,稳定的跑了一个月。业务一切正常,就这最近一周应用负载的第二台服务器总是抽风。

先说说应用的场景。

我们的应用项目代码在我们自己的服务器上,两台服务器做承载。按理来说其中一台服务器宕掉会立马故障转移到另一台服务器。但是应用前边还有两台服务器。

不太好解释,一个请求差不多是这样的:

https://www.a.com/
       | 
       | (SLB 轮询到 Server 3、Server 4 上的一台服务器,然后 301 重定向)
       ↓
https://www.b.com/abc
       |
       |(SLB 轮询)
       ↓
Server 1、Server 2(所属其他项目组)
       |
       |(Nginx 转发)
       ↓
Server 3、Server 4 (所属我们项目组)
       |
       | (Nginx 转发到 Localhost 8800端口)
       ↓
      响应

这种场景有些特殊,困于公司的各种恼人的流程,实在想不出其他法子了,以至于开发的应用适配这个架构改了好多次。

现在问题是:当 Server 3Server 4 宕机了,SLB 无法故障转移。碰巧的是 php-fpmServer 4三天挂掉了三次

我们唯一知道服务器宕掉的途径是——业务群炸了!这显然已经晚了,业务势必受到影响。

在翻看 php-fpm 日志和 nginx 日志查找了半天没有结果的情况下,心生一秒计——Supervisor 守护进程。

Supervisor 简单来说就是在你需要常驻运行的程序挂掉的时候及时拉起。这对于现在的场景是非常合适啊。

编辑 /etc/supervisord.d/php-fpm.ini,配置如下:

[program:php-fpm]
command=bash -c "sleep 1 && /usr/local/php7/sbin/php-fpm --fpm-config /usr/local/php7/etc/php-fpm.conf --pid /usr/local/php7/var/run/php-fpm.pid"
process_name=%(program_name)s
autostart=true
autorestart=true
startretries=5
exitcodes=0,2,70
stopsignal=QUIT
stopwaitsecs=2
stdout_logfile=/data/logs/supervisord/php-fpm.log

进入 Supervisor 控制台:

$ sudo supervisorctl
nginx                            RUNNING   pid 26046, uptime 0:00:01
php-fpm                          STARTING
supervisor> reread
php-fpm: changed
supervisor> start php-fpm
php-fpm: ERROR (abnormal termination)

请记住这里最后的结果是 ERROR,然而查看进程 php-fpm 确实在跑了,kill 掉进程也能拉起来,我不太清楚为什么会这样。但是跑了一天后,php-fpm 又挂了。对,是又挂了而且没拉起来。

继续锁定 ERROR,先查看 php-fpm 日志。

[01-Sep-2018 11:20:21] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:20:21] ERROR: FPM initialization failed
[01-Sep-2018 11:20:23] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:20:23] ERROR: FPM initialization failed
[01-Sep-2018 11:20:24] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:20:24] ERROR: FPM initialization failed
[01-Sep-2018 11:20:25] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:20:25] ERROR: FPM initialization failed

一直在报这个错误,看来必须要解决才行呢,看样子是端口被占用了?但是是基于 supervisor 启动的,怎么会有这种错误呢?

当然,配置是有问题的。

php-fpm 进程默认是以 daemon 方式启动的,而 Supervisor 文档 的说明是,使用 supervisor 监护进程时,被监护的进程不能是守护进程。

我们需要关闭 php-fpm 的进程守护,编辑 /usr/local/php/etc/php-fpm.conf,查找 daemonize 修改为 no

然后 killall php-fpm 的所有进程,现在查看 php-fpm 日志。

$ tail -f /usr/local/php/var/log/php-fpm.log
[01-Sep-2018 11:28:25] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:28:25] ERROR: FPM initialization failed
[01-Sep-2018 11:28:26] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:28:26] ERROR: FPM initialization failed
[01-Sep-2018 11:28:27] ERROR: unable to bind listening socket for address '127.0.0.1:9000': Address already in use (98)
[01-Sep-2018 11:28:27] ERROR: FPM initialization failed
[01-Sep-2018 11:28:28] NOTICE: Terminating ...
[01-Sep-2018 11:28:28] NOTICE: exiting, bye-bye!
[01-Sep-2018 11:28:29] NOTICE: fpm is running, pid 26011
[01-Sep-2018 11:28:29] NOTICE: ready to handle connections

查看 supervisor 状态:

$ sudo supervisorctl
nginx                            RUNNING   pid 26046, uptime 0:00:01
php-fpm                          RUNNING   pid 26009, uptime 0:00:45

关于 php-fpm 为什么会隔三差五挂掉还没查出来,为了不影响业务,只能先守护进程保证业务正常运作。