看看这样的程序排错经历是否似曾相识
本文以开发应用程序过程中遇到的问题为背景，介绍了 3 种常见的排错思路。
涉及到关键词如下
- 日志
- 重启
- 数据库
- 开发流程
读完本文，你将对应用程序如何排错有新的认识和启发。
LNMP 架构应用程序 日志排错
介绍下开发语言和服务器环境，PHP7.2+Linux CentOs
LNMP 指 Linux+Nginx+Mysql+PHP
程序部署后，出现如下图示
php-fpm-500
图中可以看到 500 错误，从服务角度来看，可以看出已经到达 PHP-FPM 层
错误日志位置
- nginx 层 nginx.conf 主配置文件 站点 vhost conf 配置文件 error_log /var/log/error.log debug;
- php-fpm 层
打开 php-fpm.conf 查看日志输出路径
error_log = /var/log/error.log- php 层面
通过php --ini 命令查询到 php.ini的位置打开查看
; error_reporting
; Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
; Development Value: E_ALL
; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT打开 Default Value 可以和 代码中设置 ini_set('display_errors','On');起到同样的效果
- 应用程序 层 程序输出日志
日志打印
- 日志是否打印ini_set('log_errors', 'On');
- 日志是否显示ini_set('display_errors','On'); 页面直接输出错误日志
[16-Jul-2020 01:57:50 UTC] PHP Stack trace:
[16-Jul-2020 01:57:50 UTC] PHP 1. {main}() /data/TunanIotFrontend/healthapi/web/index.php:0
[16-Jul-2020 01:57:50 UTC] PHP 2. require() /data/TunanIotFrontend/healthapi/web/index.php:5
[16-Jul-2020 01:57:50 UTC] PHP 3. ComposerAutoloaderInitce1eaab83df8a51267d1a7a8a9f6250a::getLoader() /data/vendor/autoload.php:8
[16-Jul-2020 01:57:50 UTC] PHP 4. composerRequirece1eaab83df8a51267d1a7a8a9f6250a() /data/vendor/composer/autoload_real.php:56重启大法
重启大法是一个行业调侃术语，泛指通过重启应用服务解决故障的方式。
应用程序运行中，对于运行缓慢 CPU 占比高等情况，都可以采用重启 Web 容器服务解决，比如 Tomcat PHP-FPM 服务。
以下场景慎用 重新启动的方法
以 Java 服务为例，同样 介绍下开发语言和服务器环境，Java Spring+Linux CentOs
❝应用程序连接数据库，数据库停止导致的应用程序停止，这时候如果重启，会发生什么情况？ ❞
这种异常的发展路径如下
- 1 数据库异常连接缓慢/磁盘故障 数据库未停止
- 2 应用程序运行缓慢 偶尔报错
- 3 数据库磁盘坏死，彻底挂起 无法访问
- 4 应用访问数据库超时，整个应用缓慢，整个应用未死
- 5 应用被超时拖死
- 6 重启服务 不能生效
第四步和第五步之间往往会有时间差，可能是几个小时，也可能是几天，有时候诡异之处就是这样。
❝正常情况下，重启服务可以让线上服务正常恢复运行。 ❞
❝风险是往往会毁坏现场，有可能使事故异常无据可查。 ❞
重启是临时应急的解决线上故障的常用方法，追踪定义修复，以及有效复盘是必备可少的事后处理流程。
数据库连接原则
业务系统中，应用程序往往需要连接多个数据库.
对于应用程序连接数据库，遵循谁提供接口谁维护相应数据库的原则
多系统之间数据交互时，优先通过接口获取数据，而不是直接连接数据库.
特别不建议连接跨部门维护的数据库。
❝有据可查，有理可依 ❞
这里涉及到程序层面的相互影响，和部门方面的责任划分问题。
如果是严重的线上事故，必然会有相应的追责定位.
有据可查，有理可依可以有效的避免背锅。
有据可查：日志记录，沟通上报记录，恢复场景。
有理可依：制度，原则，和流程。
本地服务正常，服务器不能运行
我们开发过程中经常会遇到本地服务正常，服务器部署后，不能正常运行的情况。
提示：You've added another git repository inside your current repository.
提示：Clones of the outer repository will not contain the contents of
提示：the embedded repository and will not know how to obtain it.
提示：If you meant to add a submodule, use:
提示：
提示：git submodule add <url> vendor/swiftmailer/swiftmailer
提示：
提示：If you added this path by mistake, you can remove it from the
提示：index with:
提示：
提示：git rm --cached vendor/swiftmailer/swiftmailer
提示：
提示：See "git help submodule" for more information.这种情况可以以下两个角度排查
- 1 代码一致性
- 2 服务器环境权限
对于非编译型语言开发的应用，如 PHP 程序，本地服务是完整的代码，所以程序能够正常运行。
本地代码提交不完整，Git 代码工具如果不能察觉到异常，就会造成服务器和本地代码不一致。
如上文所示 swiftmailer 包不能正常纳入代码库，造成了提交仓库失败。
解决方法如下
- 1 删除 隐藏的 git 目录
- 2 使用 git rm --cached path
- 3 重新 git add
权限造成的异常呢，就是一点，查看服务是哪个用户运行的。
小结
现在的应用部署都是分布式部署，对于分布式系统，有一个特性
❝异常总会发生 ❞
正是这样，我们要对应用系统运行过程种暴露出来的安全隐患足够敏感，及时恢复，以免造成不可恢复的损失。
每次事故和故障的复盘，究其原因都会发现难逃以下几点
- 开发原则执行不彻底
- 开发流程执行不到位
- 参与方沟通不到位，没有达成一致
以上几个问题 可以从程序设计原则，流程标准化，代码审查和沟通体制等多个方面精进优化。
你有哪些应用开发排错经历，欢迎评论一起讨论
我是王明明，互联网技术开发者，阅读写作实践者。
输出我的技术思想，探索个人品牌实践之路，期待认识优秀的你。