1. Предпосылки
Проект находился в рабочей среде PHP5.6, и было принято решение обновить PHP до PHP7.Основные причины для рассмотрения включают:
1. Официальная версия PHP7 тоже давно выпущена, чего достаточно с точки зрения стабильности и насыщенности данными
2. См. уведомление о том, что PHP5.* не будет выполнять обслуживание безопасности.
3. Улучшена производительность PHP7 по сравнению с PHP5.
4. Жизнь бесконечна, бросая больше, чем
Настоящим записываются процесс и шаги обновления в надежде помочь небольшим партнерам с аналогичными потребностями!
2. Установите PHP7
Я не буду много говорить об этом шаге, найдите процесс установки в Интернете и следуйте инструкциям. (ps: другие коллеги уже установили его на сервер компании, поэтому я могу просто использовать его напрямую)
php7和php5.6具体信息：
# php7 -v
PHP 7.1.12 (cli) (built: Jun 8 2018 19:36:50) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
# php -v
PHP 5.6.10 (cli) (built: Jun 8 2018 14:46:07)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
3. В проекте используется среда PHP7
В тестовой среде выполняется много проектов, поэтому вы не можете напрямую заменить php по умолчанию на PHP 7. Используемый метод заключается в использовании конфигурации nginx для обработки и настройке этого проекта на использование phpfpm7.
Вызовите тестовый интерфейс в проекте и протестируйте содержимое интерфейса: echo phpinfo(); Вы можете заметить, что он был заменен на PHP7!
В-четвертых, обнаружение статического кода
Как мы все знаем, PHP7 упразднил многие функции, поэтому нам нужно проверить совместимость кода.
Принятый метод заключается в использовании PHPCS и PHPCompatibility для определения стандарта кодирования PHP7 в проекте.
//PHPCS和PHPCompatibility安装和使用流程
mkdir /tmp/php_codesniffer
curl -s http://getcomposer.org/installer | php
./composer.phar config -g repo.packagist composer https://packagist.phpcomposer.com
./composer.phar selfupdate
./composer.phar require "squizlabs/php_codesniffer=*"
cd /tmp/PHPCompatibility
git clone https://github.com/wimg/PHPCompatibility.git
/tmp/PHPCompatibility/vendor/bin/phpcs --config-set installed_paths /tmp/PHPCompatibility/PHPCompatibility/
/tmp/PHPCompatibility/vendor/bin/phpcs -i
/tmp/PHPCompatibility/vendor/bin/phpcs --standard=PHPCompatibility --report-file=/tmp/check_php7_report [项目路径]
После этого код проекта можно обрабатывать поочередно согласно сгенерированному отчету '/tmp/check_php7_report'.
5. Где журнал ошибок?
В проекте используется фреймворк ThinkPHP3.2.2, но пока я не нашел, куда выводится лог ошибок, и продолжу, когда будет время, примерный процесс такой:
1. Сначала добавьте в nginx следующую конфигурацию:error_log logs/error.log error;Затем, после нескольких дней использования, я никогда не видел никаких журналов и думал, что проблем нет.
2. По прихоти я хотел убедиться, что ошибочная ситуация может быть записана, поэтому я написал интерфейс, конкретное содержание:
$str = 'asdasdaiAAS';
echo preg_replace("/([A-Z])/e", "'_' . strtolower('\\1')", $str);
在Linux下执行PHP脚本输出以下内容，同理接口也应该返回同意内容：
php5.6 : asdasdai_a_a_s
php7 ：PHP Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in ..
3. Но реальная ситуация, возврат в интерфейсе PHP5.6 соответствует ожидаемому, а в PHP7 возврат пустой и httpcode равен 200 (происходит проблема)
4. Первоначальное предположение состоит в том, что ошибка не записывается из-за фреймворка ThinkPHP, поэтому при проверке его конфигурации и логов фреймворка никаких отклонений не обнаружено.
5. Чтобы продолжить, подождите, пока у вас будет время проверить, где находится журнал ошибок.
6. Обнаружение интерфейса
Изначально я хотел использовать журнал ошибок, чтобы подтвердить, есть ли проблема с интерфейсом, но, поскольку журнал ошибок найти не удалось, у меня не было другого выбора, кроме как перейти на другое решение:
1. Получите вызываемые интерфейсы через журнал nginx, а затем выполните дедупликацию всех интерфейсов проекта, чтобы найти интерфейсы, которые не вызывались.
2. Вызываемый интерфейс использует скрипт для повторного вызова, чтобы получить возвращаемое значение в среде PHP5.6 и PHP7 соответственно, и зашифровать два возвращаемых значения md5 для сравнения.
С этим нетрудно справиться, имея план, и он должен быть последовательным, как и ожидалось, но проблемы действительно есть! (Это также показывает со стороны, что это обнаружение интерфейса очень необходимо и не может быть проверено только тестировщиками)
7. Найденные ямы и способы заполнения ям
1. Проблема: json_encode php7 будет переполняться при обработке типа float
php5.6:[6.28]
php7:[6.2800000000000002]
Решение: измените значение serialize_precision в php.ini ниже 17, и самопроверка php7 вернется в нормальное состояние.
2. Проблема: Проблема с переполнением json_encode решается в командной строке, а потом все равно будут проблемы с интерфейсом
Решение: перезапустите phpfpm для PHP7.
3. Проблема: При расчете php7, если делитель равен 0, результатом будет NAN
php5.6:0
php7：NAN
Решение: оцените случай, когда младший делитель равен 0
8. Заключение
Работа по обновлению PHP7 на этот раз еще не закончена! В настоящее время завершена только часть самопроверки.После прохождения теста работа может быть завершена, когда она полностью подключена к сети!
Если в будущем будут найдены ямы, они будут обновлены здесь вовремя.
Я надеюсь, что дорога впереди может быть великодушной, и на пути не будет ям~