写在《从0学架构》课程毕业之际 作者: nbboy 时间: 2020-08-23 分类: PHP,Python,Java,软件架构,软件工程,设计模式 评论 李运华老师的架构课程确实让我受益匪浅，对我未来的架构师之路帮助非常大。我其实不算一个架构师，顶多算高级程序员吧，这次通过学习该教程，给我的体会有下面几点。 架构师之路是一个漫长的过程，有一定的方法论，主要从复杂度，高可用，扩展性，高性能上面去考虑，更多时候是几个方案的权衡。对于要不要做架构这个问题，我觉得看项目的情况，比如项目规模，项目持续时间等。对于长时间需要维护的项目，肯定是需要做架构设计的，架构设计不是一撮而就，而是不断演化的过程，老师在课程中详细说了3个架构原则，然后说了架构的具体设计流程，另外从高可用，高扩展，高性能3高的角度说了三种系统需要学习的理论知识，最后还准备了很多具体实例来说明前面的理论。 我的理解是，不但业界成熟的开源组件有架构，而且我们平时遇到最多的业务系统也有架构，可以说架构在软件行业无处不在。当然架构也解决不了所有的问题，也不是所有的问题都是架构的问题，但是架构顺了，问题解决起来就容易得多了。 好了，不进行“剧透”了，我这个架构小学徒，还需要更多学习，大家想更多了解就去学习李老师的课程吧。 课程链接:http://gk.link/a/10kMd
php7性能分析(转) 作者: nbboy 时间: 2020-06-18 分类: PHP 评论 xhprof Xhprof是facebook开源出来的一个php轻量级的性能分析工具，跟Xdebug类似，但性能开销更低，还可以用在生产环境中，也可以由程序开关来控制是否进行profile。 xhprof for PHP7 xhprof已经不维护很久了，同事他也不再支持php7.这对我学习性能测试造成了困扰，好在有这个xhprof for PHP7的开源项目，供大家一起使用。 适配PHP版本 7.0 7.1 7.2 安装 git clone https://github.com/longxinH/xhprof.git ./xhprof cd xhprof/extension/ phpize ./configure --with-php-config=/path/to/php7/bin/php-config make && sudo make install 出现 Installing shared extensions: /opt/php-7.0.14/lib/php/extensions/no-debug-non-zts-20151012/ 代表编译成功 编译过程问题 configure: error: Cannot find php-config. Please use --with-php-config=PATH configure: error: Cannot find php-config. Please use –with-php-config=PATH 一般出现这个错误说明你执行 ./configure 时 –with-php-config 这个参数配置路径错误导致的。 查找: find / -name php-config 修改为： ./configure --with-php-config=/usr/local/php/bin/php-config 就可以解决问题，上面的 /usr/local/php/ 是你的 php 安装路径。 配置 添加配置项到php.ini [xhprof] extension=xhprof.so xhprof.output_dir=/Users/machuang/Desktop/project/xhprof/save_output_dir//此处你就留一个存放xhprof记录文件的目录ok了 创建目录 mkdir -p /Users/machuang/Desktop/project/xhprof/save_output_dir 重启php-fpm, php.ini就生效了 machuangdeMacBook-Pro:7.1 machuang$ fpm -n Gracefully shutting down php-fpm -n . done -n Starting php-fpm done 项目地址 https://github.com/longxinH/xhprof 使用 植入xhprof 此处写个脚本就OK，文件命名为b.php。 <?php //1.开启xhprof xhprof_enable(); //2.你需要分析的代码 for($i=1;$i<1000;$i++){ if($i%100 == 0){ echo $i; echo "<br>"; } } //3.关闭xhprof,收集数据 $xhprof_data = xhprof_disable(); include_once './xhprof/xhprof_lib/utils/xhprof_lib.php'; include_once './xhprof/xhprof_lib/utils/xhprof_runs.php'; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo "<br>"; echo $run_id;die; //将run_id保存起来或者随代码一起输出 使用php内置部署工具 php -S 127.0.0.1:9001 在浏览器运行脚本 打开：http://127.0.0.1:9001/b.php 输出： 100 200 300 400 500 600 700 800 900 5ad88171addf9 查看结果 在浏览器输入url，HOST为你的项目当前域名，get参数run的值为$run_id HOST/xhpfrof_html/index.php?run=58d3b28b521f6&source=xhprof_test 打开：http://127.0.0.1:9001/xhprof/xhprof_html/ 可见生成的文件，点击一个打开，url地址变为 http://127.0.0.1:9001/xhprof/xhprof_html/index.php?run=5ad88171addf9&source=xhprof_test Function Name Calls Calls% Incl. Wall Time (microsec) IWall% Excl. Wall Time (microsec) EWall% main() 1 50.0% 3 100.0% 3 100.0% xhprof_disable 1 50.0% 0 0.0% 0 0.0% xhprof_enable的参数控制 HPROF_FLAGS_NO_BUILTINS 跳过所有内置（内部）函数。 XHPROF_FLAGS_CPU 输出的性能数据中添加 CPU 数据。 XHPROF_FLAGS_MEMORY 输出的性能数据中添加内存数据。 结果分析 xhprof_html/index.php将记录的结果整理并可视化，默认的UI里列出了： funciton name ： 函数名 calls: 调用次数 Incl. Wall Time (microsec)： 函数运行时间（包括子函数） IWall%：函数运行时间（包括子函数）占比 Excl. Wall Time(microsec)：函数运行时间（不包括子函数） EWall%：函数运行时间（不包括子函数） 在xhprof_html/index.php中还可以看到[View Full Callgraph]链接，点击后可以绘制出一张可视化的性能分析图，如果点击后报错的话，可能是缺少依赖graphviz， graphviz是一个绘制图形的工具，可以更为直观的让你查看性能的瓶颈。 优化读取测试数据 graphviz https://graphviz.gitlab.io/download/ macbook上的安装很简单，brew就可以。 brew install graphviz 安装成功，brew会帮你配置graphviz，所以后面可以直接使用。点击 [View Full Callgraph] ，可以更直观查看所有的性能测试信息。 XHProf报告含义 XHProf报告中有许多列，它们代表的含义见下表： 列名 描述 Function Name 方法名称。 Calls 方法被调用的次数。 Calls% 方法调用次数在同级方法总数调用次数中所占的百分比。 Incl.Wall Time(microsec) 方法执行花费的时间，包括子方法的执行时间。（单位：微秒） IWall% 方法执行花费的时间百分比。 Excl. Wall Time(microsec) 方法本身执行花费的时间，不包括子方法的执行时间。（单位：微秒） EWall% 方法本身执行花费的时间百分比。 Incl. CPU(microsecs) 方法执行花费的CPU时间，包括子方法的执行时间。（单位：微秒） ICpu% 方法执行花费的CPU时间百分比。 Excl. CPU(microsec) 方法本身执行花费的CPU时间，不包括子方法的执行时间。（单位：微秒） ECPU% 方法本身执行花费的CPU时间百分比。 Incl.MemUse(bytes) 方法执行占用的内存，包括子方法执行占用的内存。（单位：字节） IMemUse% 方法执行占用的内存百分比。 Excl.MemUse(bytes) 方法本身执行占用的内存，不包括子方法执行占用的内存。（单位：字节） EMemUse% 方法本身执行占用的内存百分比。 Incl.PeakMemUse(bytes) Incl.MemUse峰值。（单位：字节） IPeakMemUse% ncl.MemUse峰值百分比。 Excl.PeakMemUse(bytes) Excl.MemUse峰值。单位：（字节） EPeakMemUse% Excl.MemUse峰值百分比。 php框架中使用 此处我们有比较优雅的注入方式，首先，把xhprof项目放到laravel项目的public目录下， 然后在index.php的最上面加入如下代码： ini_set('xhprof.output_dir',dirname(__DIR__).'/xhprof_save_dir'); //echo ini_get('xhprof.output_dir'); die; $xhprof_lib_dir = dirname(__DIR__).'/public/xhprof/xhprof_lib/utils/xhprof_lib.php'; $xhprof_runs_dir = dirname(__DIR__).'/public/xhprof/xhprof_lib/utils/xhprof_runs.php'; include_once $xhprof_lib_dir; include_once $xhprof_runs_dir; //开启xhprof xhprof_enable(XHPROF_FLAGS_MEMORY ); //在程序结束后收集数据 register_shutdown_function(function() { $xhprof_data = xhprof_disable(); //让数据收集程序在后台运行 if (function_exists('fastcgi_finish_request')) { fastcgi_finish_request(); } //保存 $xhprof_runs = new XHProfRuns_Default(); $xhprof_runs->save_run($xhprof_data, "xhprof_crm"); }); 然后，在xhprof/xhprof_html/index.php增加一行代码，如下： ini_set('xhprof.output_dir',dirname(dirname(dirname(__DIR__))).'/xhprof_save_dir'); 这是为了保证数据的存储和读取目录一致。 打开类似链接，即可看到测试数据分析了 http://xhprof.your-laravel.app/xhprof/xhprof_html/index.php?run=5adeaebf97d31&source=xhprof_crm 数据如下 Overall Summary Total Incl. Wall Time (microsec): 818,313 microsecs Total Incl. MemUse (bytes): 10,521,952 bytes Total Incl. PeakMemUse (bytes): 10,435,224 bytes Number of Function Calls: 56,935
从线上宕机引起的问题谈开去 作者: nbboy 时间: 2020-06-18 分类: 默认分类,PHP 评论 ### 背景 公司的外网线上项目连续宕机将近2周时间，后来通过查找日志，发现是某度蜘蛛大量爬取造成。因为公司花钱进行了SEO推广，所以也不能直接禁掉蜘蛛，所以一度造成网站打不开的情况。期间增加带宽，扩容cpu,增强搜索引擎集群等方案，都得不到好的效果。 ### 分析 开始优化代码，记录慢日志，在云平台看慢查询，渐渐优化慢查询，但是问题依旧。慢慢通过分析慢日志注意到如下细节：  这里我摘取了两个日志片段，其实类似日志片段还有非常多。可以看到将近相同的时间不同的许多进程都进行了GC,而这里的所谓GC是什么？ 在StartSession.php上看到了如下代码: ```php /** * Remove the garbage from the session if necessary. * * @param \Illuminate\Session\SessionInterface $session * @return void */ protected function collectGarbage(SessionInterface $session) { $config = $this->manager->getSessionConfig(); // Here we will see if this request hits the garbage collection lottery by hitting // the odds needed to perform garbage collection on any given request. If we do // hit it, we'll call this handler to let it delete all the expired sessions. if ($this->configHitsLottery($config)) { $session->getHandler()->gc($this->getSessionLifetimeInSeconds()); } } ``` 这里注释的意思是有一定概率进行GC,并不是每次都进行GC,先来看下GC做了什么事情。 因为配置的是文件session,所以我们找到文件Session的实现文件FileSessionHandler.php,摘取GC函数代码如下: ```php /** * {@inheritdoc} */ public function gc($lifetime) { $files = Finder::create() ->in($this->path) ->files() ->ignoreDotFiles(true) ->date('<= now - '.$lifetime.' seconds'); foreach ($files as $file) { $this->files->delete($file->getRealPath()); } } ``` 代码的意思很简单，就是通过搜索文件，获取到过期的session文件然后进行删除，这里的过期时间在session.php的配置里定义： ```php /* |-------------------------------------------------------------------------- | Session Lifetime |-------------------------------------------------------------------------- | | Here you may specify the number of minutes that you wish the session | to be allowed to remain idle before it expires. If you want them | to immediately expire on the browser closing, set that option. | */ 'lifetime' => 120, 'expire_on_close' => true, ``` 可以看到默认是2个小时，下面一个参数的意义是是否要在浏览器关闭的时候立即过期！刚才说到了，有一定概率执行这个GC,那这个概率多大呢？ ```php /** * Determine if the configuration odds hit the lottery. * * @param array $config * @return bool */ protected function configHitsLottery(array $config) { return random_int(1, 100) <= 2; } ``` 上面代码是我把默认配置替换后的结果，也就是会有2%的可能会触发一次GC!而一次GC我们要回收两个小时之前的过期session文件。如果在并发量稍微有点大的情况下，要删除的文件其实是非常可观的，删除这个IO操作就是直接导致了cpu负荷直接超载的罪魁祸首。 ### 解决方案 方法很简单，就是换driver,比如集中式的redis session方案。 ### 总结 虽然这次项目的主要负责人不是我，不过通过这次抓取日志，跟踪代码，分析代码学到了很多优化的一手资料。Laravel其实是一个相当灵活的框架，文件session方式只能在测试环境进行应用，而在线上环境必须上集中式session方式，不然流量起来的时候，就会吃苦头。Laravel如不经过优化的情况下，他的性能是不高的，好在他也提供了很多可以优化的扩展接口，算的上是目前PHP里相当成熟的框架了。
Laravel程序 最佳实践1 作者: nbboy 时间: 2020-03-14 分类: PHP 评论 # 层的定义 Laravel程序在初始化后，其实相比PHP的其他框架，分层还算比较明确的，正如它的作者所说，是为艺术家写的框架。刚开始的时候，会把所有的代码写在Model里，当代码比较多的时候，往往一个Model代码文件就会膨胀开来。不但Model文件代码非常多，Controller文件代码也非常多，这又会导致复用率非常低。 所以后来在思考一种更好的分层,相信很多从静态语言走过来的读者，比如Java或者C#在开发WEB程序的时候，也是会经典的三层架构MVC。他们更习惯把逻辑代码写在Service层，这样既解决了复用的问题，也解决了把业务逻辑写在Controller层的尴尬。 这时很多人感觉有点疑问，为什么把代码写在Controller层不好？因为根据标准的MVC模型的定义，C这层存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。也就是说，如果把大段的业务逻辑，放在了控制层，不但影响到了复用度，而且导致各层的职责混乱！ 说道MVC,简单复习下MVC的一些概念。其实MVC最早不是产生于WEB程序，而开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。也就是按照标准的定义，我们很多人用的都不是MVC,而是变态版本的MVSC,中间加入一个Service层。这里也顺便说下，其实按照标准，M和V的数据变动是双向的，但是目前我们的WEB做不到这点。 再说回Laravel的情况，Laravel的模型层真的是非常舒服，借助于Eloquent ORM,写起查询来真的是一种享受。借用Laravel官方文档说:"Eloquent ORM 提供了一个漂亮、简洁的 ActiveRecord 实现来和数据库交互"。写过的肯定对他的链式写法映象深刻，这种做法是他的优点之一。有了一个足够强大的模型层，事情真的解决了一大半。**按照DDD的想法，模型应该反映领域驱动的模型，引入Repository层来解决模型的加载和存储问题，引入Service层来解决跨模型的事物处理问题。**对于一般的中小型项目，这种分层已经够用了。分层其实本身很简单，难得是大家都要去遵守这种约定和随着项目不停得去对代码和模块层级，类层级进行审视和重构。 # 框架的破坏 这个是一种糟糕的写法，其实第一次我看到这样写的时候，内心真的10万头草泥马在奔腾。在团队里的很多小伙伴，在Controller层写类似这种代码： AuthController.php中 ```php $token=User::createToken($oldUser); ``` User.php中 ```php protected function createToken($user){ ... } ``` Model类中的保护成员竟然在Controller层进行直接调用，说好的保护呢？？？不过回过头一想，业务程序员是缺乏基础的认识，但是框架怎么能放行这种愚蠢的写法呢！！！ 看看框架做了什么？  哇，原来是这么一回事，果然是框架在作怪。不过仔细想想，作者的想法是不是就是这样？我猜作者的想法只是为了给使用者方便，不用再去"NEW"一个对象，但是的确在这里给使用者放行了这种行为。我想作者可能已经想到了这个问题，只是让使用者自己去做规范吧。 # 总结 其实这篇文字真的没写多少，一方面博客刚恢复访问，总得写点什么。另外一方面后期有很多文章正在构思，小弟文笔不怎么样，只求在这里做一个备忘吧，如果能帮到读者，那我很开心了。其实，Laravel总体来说真的是PHP中的好框架了，但是使用中有很多细节需要考虑和决策，甚至当项目大了之后，也有必要做一定的改造。