使用工具来检查项目代码对PHP7的兼容情况

使用 PHP_CodeSniffer + PHPCompatibility
PHP_CodeSniffer
PHP_CodeSniffer对PHP,JavaScript和CSS文件进行标记,并检测违反已定义的一组编码标准的行为。
https://github.com/squizlabs/PHP_CodeSniffer

PHPCompatibility
PHP兼容性检查
https://github.com/PHPCompatibility/PHPCompatibility
更多PHPCompatibility相关内容,请参考 https://www.sitepoint.com/quick-intro-phpcompatibility-standard-for-phpcs-are-you-php7-ready/

安装和运行

按照官方文档进行安装
先安装PHP_CodeSniffer
再安装插件PHPCompatibility

composer global require “squizlabs/php_codesniffer=*”
phpcs –config-set installed_paths /data/wwwroot/php/PHPCompatibility
phpcs –config-set installed_paths “D:\projects\php\PHPCompatibility”

查看是否安装上
phpcs -i
#The installed coding standards are MySource, PEAR, PSR1, PSR12, PSR2, Squiz, Zend and PHPCompatibility
执行检查
phpcs –standard=PHPCompatibility –runtime-set testVersion 7.0 /data/wwwroot/project/ >phpcs.log
#执行的过程会有些慢,慢慢等吧

根据phpcs.log中的日志,解决error级别的错误

FILE: \data\wwwroot\project\Common\function.php

FOUND 3 ERRORS AFFECTING 2 LINES

9 | ERROR | Function split() is deprecated since PHP 5.3 and removed since PHP 7.0; Use preg_split() instead
11 | ERROR | Function eregi() is deprecated since PHP 5.3 and removed since PHP 7.0; Use preg_match() instead

11 | ERROR | Extension ‘ereg’ is deprecated since PHP 5.3 and removed since PHP 7.0; Use pcre instead

再加上手动按照PHP版本逐级检查不兼容

PHP5.4.x 》 PHP5.6.x

从 PHP 5.4.x 迁移到 PHP 5.5.x

不向后兼容的变更的检查
检查 pack() 和 unpack() pass

PHP 5.5.x 中废弃的特性的检查
preg_replace() 函数中用到的 /e 修饰符现在被弃用。可以使用 preg_replace_callback() 函数来替代。
mcrypt 的相关函数

PHP 5.5.x 》 PHP5.6.x

从PHP 5.5.x 移植到 PHP 5.6.x
不向后兼容的变更的检查
严格的 json_decode()

PHP 5.6.x 》 PHP7.0.x

从PHP 5.6.x 移植到 PHP 7.0.x
不向后兼容的变更的检查
ereg相关函数
split()

测试

把主要业务功能都过一遍测试

升级部署问题

方式1:容器部署:php-fpm改用docker的方式部署,这样比较方便多版本切换和回滚
方式2:传统部署:部署新服,业务流量切过去,原有服暂时不要销毁,等业务没问题后再慢慢销毁原有服, 如果是云平台应该为所有将要销毁的系统做一个快照以备不时之需

需求

在vue单页应用开发中,如果为了省事PHP代码和vue代码都放在同一个GIT仓库中
那么如何进行vue前端代码和php Api 后端代码组织呢?
下面提供一个组织方式

项目目录结构

其中
frontend 为vue前端项目目录
public 为php的web目录,index.php入口文件在这里,nginx也配置的是public

vue 配置

文件 frontend/config/index.js

前台访问

api接口为
http://appweb.dev/v1/api

访问/ui/即可
http://appweb.dev/ui/

需要注意的问题

public/ui 目录为前端项目build后的文件,不适宜纳入git管理
线上发布的通过CI&CD工具解决
目前适用于PHP项目的CI&CD工具有
Jenkins
Walle 瓦力上线部署系统
Piplin 持续集成与部署系统

mysql雪崩

故事

小王刚下班回家正准备露一手做2个菜。
手机就收到监控报警,网站打不开报警,mysql IO报警,xx报警
还没等开电脑,公司的人就来电话了
老板:小王啊,网站怎么又打不开了?快点解决啊!损失很大啊!
小王:好的马上处理。
凭借小王丰富的经验,mysql IO都那么高了,肯定是什么sql查询把IO都耗干净了,估计还卡了一堆查询
熟练的用show processlist看了下mysql正在处理的查询,果不其然,这查询队列都长到姥姥家了
苦逼的小心易易的结束了卡的时间很长的SELECT查询,这他妈结束的数据远远跟不上新增加的慢查询的速度呀
应用层程序也来不及改呀
最后小王还是恢复了数据库,可时间已经过去了整整1小时。

事后
老版:这次网站挂了1小时,以后别这样,的解决啊!
小王解释道:网站被恶意爬虫了,爬到了耗IO的sql查询,这个时候业务又是高峰期,导致数据库卡死了。
(对于业务来说,更多时候只关注结果,业务不能离线)

其他公司怎么做的?

  • 数据库中间件处理
  • 缓存机制保证不会让数据库太难受
  • 应用层熔断机制
    等等

纯PHP + MYSQL的项目如何应对数据库雪崩?

  • 数据库中间件处理
    我想绝大用PHP + MYSQL的中小公司是没有MYSQL中间件的,有中间件的可以在数据库中间件处理
    有用Swoole写MYSQL中间件的案例
  • 缓存要顶用
    设计好Redis机制,最小量的请求落在MYSQL上
  • 用MySQL Query Rewrite Plugin 进行SQL语句重写
    MySQL · 5.7新特性 · Query Rewrite Plugin
  • 用pt-kill自动杀掉过长的慢查询
    pt-kill是Percona-Toolkit系列之一,Percona公司出品的工具都没用过,绝对有相见恨晚的感觉。
    pt-kill杀掉慢查询,这算是一个简单粗暴的“熔断方案”,都已经到了让数据库雪崩的阶段,与其业务都不可用,还不如有损服务。
    需要注意的是只结束从库的SELECT慢查询

直接上手,pt-kill常驻进程自动结束SQL慢查询实例

以下实例作用是
* 127.0.0.1这台msyql实例上
* 字符集指定为 utf8
* 查询中有关键字 “SELECT|select” (支持正则)
* mysql帐号是 “业务mysql帐号”
* 查询时间大于60秒
* kill掉查询,不kill mysql连接
* 表示从匹配的结果中选择,类似SQL中的where部分,all是全部的查询
* 10秒检查一次
* 日志记录位置
* 打印日志
* 守护进程的方式运行

常用参数说明

  • host 连接数据库的地址
  • port 连接数据库的端口
  • user 连接数据库的用户名
  • passowrd 连接数据库的密码
  • charset 指定字符集
  • match-command 指定杀死的查询类型
  • match-user 指定杀死的用户名,即杀死该用户的查询
  • match-info 匹配查询的信息
  • busy-time 指定杀死超过多少秒的查询
  • kill 执行kill命令
  • kill-query 与kill匹配查询的连接不同,此选项只会kill查询,而不会杀死连接
  • victims 表示从匹配的结果中选择,类似SQL中的where部分,all是全部的查询
  • interal 每隔多少秒检查一次
  • print 把kill的查询打印出来
  • log 输出日志到文件仅在 daemonize 守护进程的时候
  • daemonize 守护进程(常驻进程)
    更多参考官方pt-kill手册

监控多个mysql

如果多个mysql都需要用pt-kill监控慢查询并干掉,那么运行多个即可

pt-kill守护进程

虽然pt-kill自带参数daemonize可以后台守护运行,但是很多时候会莫名其妙的进程挂掉,
那么还需要一个外部的进程守护工具来守护他,在pt-kill自动退出后再次把进程拉起来
这里进程守护工具我们使用 Monit
配置文件参考为

参考

官方pt-kill手册

隐藏nginx、openresty版本号

隐藏nginx、openresty的版本号有什么用?
假设一个场景,nginx被爆出0.9-1.5的版本被爆出一个0day漏洞,
攻击者会先大量扫描匹配的nginx版本,然后实施攻击。
如果事先隐藏了会降低第一时间被攻击的风险

在 http {} 中间配置增加

在http头中从原来的
Server: nginx/1.0.15 变为 Server: nginx
Server: openresty/1.11.2.3 变为 Server: openresty

nginx 日志格式化完整增强版

本完整增强版主要解决了后端执行时间的记录、哪台后端处理的、日志集中化后日志来自于哪台服务器ip、cdn传过来的客户端ip等扩展等问题。

在默认的nginx日志上,扩展增加了http头中代理服务器ip($http_x_forwarded_for)、
http头中cdn保存的客户端用户真实IP($http_x_real_ip)、服务端ip($server_addr)、http头中host主机($host)、
请求时间($request_time)、后端返回时间($upstream_response_time)、后端地址($upstream_addr)、
URI($uri)、ISO 8601标准时间($time_iso8601)

nginx日志滚动切割

繁忙的nginx服务器每天都会产生大量的web日志,所以每天需要切割。
每天切割的日志需要保留一段时间,更老的日志需要删除,专业叫法叫做日志滚动类似于视频监控,
所需要保留一定时间的日志还需要删除更老的日志。

很多人喜欢手动用bash shell去写nginx的日志切割滚动配合定时计划任务执行执行。
其实用系统自带的logrotate更好。
新建文件

写入

elastic stack elk日志系统

采集的日志需要格式化格式,要么在采集端做,要么在入库elasticsearch的时候做。
在nginx中直接配置输出的日志就是json格式,可以减少格式化日志的cpu开销
在日志采集端,用filebeat、或者logstash作为日志采集工具可以不做任务的格式化处理,
仅仅采集json格式的文本即可。

nginx反向代理

nginx反向代理的时候要支持后端服务器为DDNS动态域名

nginx 反向代理 WebScoket

nginx代理设置php pm status

php-fpm.conf设置

phpfpm.conf

nginx 域名SEO优化 301

把 iamle.com 默认 301到 www.iamle.com

nginx 全站http跳转https

XSS、Ifram

nginx http2 openssl 支持情况介绍

Supporting HTTP/2 for Website Visitors

ssl https 证书配置生成巩固

Mozilla SSL Configuration Generator

nginx+php 开启OPCACHE 并且使用软连接发布

软连接的方式发布新版本php代码,但是因为OPCACHE未及时更新某些时候会导致502错误
2个方式,方式1直接在nginx这里自动更新最新路径,方式2刷新php-fpm的缓存
下面是方式1

Cache invalidation for scripts in symlinked folders
Symfony Configuring a Web Server

用PECL自动安装Redis扩展、Swoole扩展

编译安装PHP7并安装Redis扩展Swoole扩展

在编译php7的机器上已经有编译安装过php5.3以上的版本,从而依赖库都有了

本php7是编译成fpm-php 使用的,

如果是apache那么编译参数应该为

编译安装php7

编译安装php7的redis扩展支持

/usr/local/php7/etc/php.ini
中加入
extension=redis.so

编译安装php7的swoole

/usr/local/php7/etc/php.ini
中加入
extension=swoole.so

# 在nginx和php-fpm下一访问nginx就瞬间502的问题 php-fpmsignal 7 (SIGBUS)

故障现象

使用TinkPHP3.2.x框架,页面偶尔会出现一访问nginx就报502 bad gateway,并不是等一段时间后nginx才报502,打开页面的一瞬间就502了。

php-fpm日志

 


可以看到有大量的 php-fpm进程收到 signal 7 退出了, 由于fastcgi php-fpm 瞬间退出了,nginx就瞬间502了

对php-fpm进行调试

既然看不出来头绪就需要进行调试了,这里需要把php-fpm退出的时候导出coredump

 php-fpm coredump方法

核心文件,也称核心转储,是操作系统在进程收到某些信号而终止运行时,将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件。这种信息往往用于调试。 核心文件一词来源于磁芯内存。

php需要打开debug参数,如果编译的时候没有打开,需要重新编译,以下是我这里的

修改dump出来的路径

允许程序崩溃的时候dump

关闭dump功能

用gdb进行调试

 

发现 php的lex_scan执行的时候崩溃了,通过搜索明白是某php正在被词法分析的时候又被修改了。

最后确定是TinkPHP开启调试模式后,模板是动态编译的,这样当有并发访问的时候就发生了php文件又在被解析,又在被写入的情况导致lex_scan的时候php-fpm就挂掉了。

当有并发的时候关闭调试模式即可解决

也算是见识了php程序的问题可以让php-fpm进程都挂掉

参考

提供SIGABRT的 backtrace ,如何提供backtrace, 请参看:

http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Generating core-dump for php5-fpm

https://rtcamp.com/tutorials/php/core-dump-php5-fpm/

对nginx报502bad gateway的一次原因定位

http://blog.chunshiban.com/2013/07/05/%E5%AF%B9nginx%E6%8A%A5502bad-gateway%E7%9A%84%E4%B8%80%E6%AC%A1%E5%8E%9F%E5%9B%A0%E5%AE%9A%E4%BD%8D/

一例php进程的SIGBUS故障

http://blog.druggo.org/post/2013/05/02/%E4%B8%80%E4%BE%8Bphp%E8%BF%9B%E7%A8%8B%E7%9A%84SIGBUS%E6%95%85%E9%9A%9C

低并发502错误signal 7 (SIGBUS)

http://kokahkhk.blog.163.com/blog/static/209428040201411595622729/

压力测试下httpd进程由于lex_scan和Runtime缓存文件而崩溃

http://www.thinkphp.cn/topic/27464.html

php进程崩溃跟踪方法

http://blog.chinaunix.net/uid-23504396-id-4819011.html