读“日请求亿级的QQ会员AMS平台PHP7升级实践”博客心得笔记

Posted 2020-07-20

因原文章出自CSDN未经允许不可转载，故只记录下大神们的心得和最值得收藏借鉴的地方，供日后参考，php7版本尚未普及，对于前辈们为了性能提升有勇气探索新技术敢于尝螃蟹的精神十分敬佩，倍受鼓舞。

PHP7升级面临的风险和挑战 
对于一个已经现网在线的大型公共Web服务来说，基础公共软件升级，通常是一件吃力不讨好的工作，做得好，不一定被大家感知到，但是，升级出了问题，则需要承担比较重的责任。为了尽量减少升级的风险，必须先弄清楚我们的升级存在挑战和风险。 
以下是前辈们整理的升级挑战和风险列表： 
（1）Apache2.0和PHP5.2这两个2008-2009年的基础软件版本比较古老，升级到Apache2.4和PHP7，版本升级跨度比较大，时间跨度相差7-8年，因此，兼容性问题挑战比较高。实际上，我们公司的现网PHP服务，很多都停留在PHP5.2和PHP5.3的版本，版本偏低。 
（2）AMS大量使用自研tphplib扩展，tphplib很早在公司内部就没有人维护了，这个扩展之前只有PHP5.3和PHP5.2的编译so版本，并且，部分扩展没有支持线程安全。支持线程安全，是因为我们以前的Apache使用了prefork模式，而我们希望能够使用Apache2.4的Event模式（2014年中，在prefork和worker之后，推出的多进程线程管理模式，对于支持高并发，有更良好的表现）。 
（3）语法兼容性问题，从PHP5.2到PHP7的跨度过大，即使PHP官方号称在向下兼容方面做到99%，但是，我们的代码规模比较大，它仍然是一个未知的风险。 
（4）新软件面临的风险，将Apache和PHP这种基础软件升级到最新的版本，而这些版本的部分功能可能存在未知的风险和缺陷。 
部分同学可能会建议采用nginx会是更优的选择，的确，单纯比较Nginx和Apache在高并发方面的性能，Nginx的表现更优。但是就PHP的CGI而言，Nginx+php-ftpm和Apache+mod_php两者并没有很大的差距。另一方面，我们因为长期使用Apache，在技术熟悉和经验方面积累更多，因此，它可能不是最佳的选择，但是，具体到我们业务场景，算是比较合适的一个选择。 

从PHP5.2升级到PHP5.6相对比较容易，前辈们做的主要的工作如下： 
（1）清理了部分不再使用的老扩展 
（2）解决掉线程安全问题 
（3）将cmem等api编译到新的版本 
（4）PHP代码语法基于PHP5.6的兼容（实际上变化不大） 
（5）部分扩展的同步调整。apc扩展变为zend_opcache和apcu，以前的apc是包含了编译缓存和用户内存操作的功能，在PHP比较新版本里，被分解为独立的两个扩展。 

从PHP5.6升级到PHP7.0的工作量就比较多，也相对比较复杂，以下是前辈们制定的每一个阶段的升级计划： 
（1）技术预研，PHP7升级准备。 
（2）环境编译和搭建，下载相关的编译包，搭建完整的编译环境和测试环境。（编译环境还是需要比较多的依赖so） 
（3）兼容升级和测试。PHP7扩展的重新编译和代码兼容性工作，AMS功能验证，性能压测。 
（4）线上灰度。打包为pkg的安装包，编写相关的安装shell安装执行代码（包括软链接、解决一些so依赖）。然后，灰度安装到现网，观察。 
（5）正式发布。扩大灰度范围，全量升级。