Docker实践之Docker-Compose安装
Docker实践之Docker-Compose安装什么是docker-compose 是一个用于运行和管理多个容器化应用的工具 官方介绍 安装 官方教程 我这里的环境是centos7，要安装自己的实际情况进行安装哦，ps：根据网络情况可能会下载的很慢，大家可以扶墙之后去https://github.com/docker/compose/releases上面寻找适合自己环境的包直接下载 123# sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose# sudo chmod +x /usr/local/bin/docker-compose# sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose 命令讲解：其实就是去github上面下载一个dock...
压测工具 - ab
压测工具 - ab实验环境 Centos7.5 基本概念 QPS：每秒钟请求或查询数量，在互联网领域指每秒响应的请求数（指HTTP请求） 吞吐量：单位时间内处理的请求数量（通常由QPS和并发数决定） 响应时间：从请求发出到收到响应花费时间 PV：综合浏览量（Page View），即页面浏览量或者点击量，一个访客在24小时内访问的页面数量。同一个人浏览你的网站同一个页面，只记作一次PV UV：独立访客（UniQue Visitor）,即一定时间范围内相同访客多次访问网站，只能计算为1个独立访客 带宽：计算带宽大小需关注两个指标，峰值流量和页面的平均大小 日网站带宽=PV/统计时间（秒）平均页面大小（KB）8 峰值一般是平均值的倍数 QPS不等于并发并发连接数。QPS是每秒HTTP请求数量，并发连接数是系统同时处理的请求数量 二八定律（80%的访问量集中在20%的时间）：（总PV数80%）/（6小时秒速20%）=峰值每秒请求数（QPS） 压力测试：能承受最大的并发数和最大承受的QPS值 注意事项： 测试机器与被测机器分开 不要对线上服务做压力测试 观察测试工具所在机器，以及被测试...
【转载】关于PHP程序员技术职业生涯规划
原文地址：【转载】关于PHP程序员技术职业生涯规划 看到很多PHP程序员职业规划的文章，都是直接上来就提Linux、PHP、MySQL、Nginx、Redis、Memcache、jQuery这些，然后就直接上手搭环境、做项目，中级就是学习各种PHP框架和类库，高级阶段就是MySQL优化、PHP内核与扩展、架构设计这些了。 这些文章都存在一个严重的缺陷，不重视基础。就好比练武功，只求速成，不修炼内功和心法，只练各种招式，这样能高到哪里去？我所见过的PHP大牛每一个都是具备非常扎实的基础，他们之所以能成为大牛，是因为基础足够好。基础不稳，面对技术复杂的系统，如同盲人摸象、管中窥豹，只得其门不得其法。而且如果基础不扎实，也没办法进入大公司。国外的Google、Facebook，国内的腾讯、阿里、百度、滴滴、京东、新浪等知名互联网企业，无论哪一家公司面试必然会考验应聘者的技术功底。无法进入一个拥有大规模并发请求的项目中得到历练，不坚持提升自己，那也只能在小公司混日子了。 我最开始工作也是在2家小公司，后来加入腾讯阿里，主要原因还是我坚持学习基础知识，从而得倒了这个机会。有几个方面的基...
Docker实践之应用篇 - MailHog
Docker实践之应用篇 - MailHogMailHog 介绍 引用mailhog/MailHog的介绍：Web and API based SMTP testing 即 本地开发测试的邮件服务，它提供了一个 Web 界面，可以检查应用发送的邮件，运行 MailHog 最简单的方法是用 Docker 运行应用1docker run --name mailhog -p 1025:1025 -p 8025:8025 -d mailhog/mailhog 其中1025 是发邮件用的端口，8025 是 Web 界面用的端口 运行之后看到下面的结果就代表成功了，是不是很简单 -.-! 查看web页面因为我是虚拟机环境，配置了虚拟网络，所以访问地址是http://192.168.56.10:8025 访问ip地址要根据自己的环境来切换哦，别照搬 测试一下我这里使用了mailhog/mhsendmail模拟了邮件发送 安装也是很简单的 1234yum install gogo get github.com/mailhog/mhsendmailln ~/go/bin/mhsendmai...
Docker 常用命令
Docker 常用命令查看12345docker images # 列出所有镜像(images)docker ps # 列出正在运行的容器(containers)docker ps -a # 列出所有的容器docker pull centos # 下载centos镜像docker top <container> # 查看容器内部运行程序 容器1234567891011docker stop <container> # 停止一个正在运行的容器，<container>可以是容器ID或名称docker start <container> # 启动一个已经停止的容器docker restart <container> # 重启容器docker rm <container> # 删除容器docker run...
【自己动手】助手函数包 helper
【自己动手】助手函数包 helper 受人启发，每个项目都写 helper? 为什么不自己搞一个呢？，所以自己动手写一个，以后又不断的更新就好啦，不错不错 源码 https://github.com/lihq1403/helper 安装1$ composer require lihq1403/helper TODO 用法文档 单元测试 同时也学习了一波单元测试，不亏血赚 断言：https://www.cnblogs.com/cxscode/p/8277023.html 源码地址
php 处理高精度计算函数
PHP 为任意精度数学计算提供了二进制计算器（Binary Calculator），它支持任意大小和精度的数字，以字符串形式描述 bcadd — 加法 bcsub — 减法 bcmul — 乘法 bcdiv — 相除 bccomp — 比较 bcmod — 求余数 bcpow — 次方 bcpowmod — 先次方然后求余数 bcscale — 给所有函数设置小数位精度 bcsqrt — 求平方根
【BUG修复日记】之支付回调websocket busy
【BUG修复日记】之支付回调websocket busy问题描述项目中，用到了第四方聚合扫码支付，支付成功会有回调。回调支付成功是服务端的数据整理（这段实现没问题），但是前台页面需要弹出支付成功，并关闭二维码，一开始想了好几个方案： 展示二维码的同时，前端轮询查询状态接口，直到成功就提示支付成功 展示二维码的同时，使用websocket进行长连接，支付成功，服务端主动推送成功结果 作为技术爱好者，当然是选择第二种啦（感觉第一种没啥技术含量，而且会造成服务端接受太多无用请求了） 说干就干：用的框架是tp5.1，可以用workeman来实现websocket 1composer require topthink/think-worker=2.0.* // 5.1仅支持2.0，别搞错了哦 有关workeman的介绍可以看官方文档：Workerman，高性能socket服务框架 安装完成之后，会生成几个文件，我们需要关系的就只是config/worker_server.php 我这里只是做了简单的长连接，主要修改了onMessage回调（记得修改protocol，host，por...
PHP 常用过滤器
PHP 常用过滤器 平时用到的框架，基本都实现了表单验证，探究一下他们的代码，就会发现，使用了大量的过滤器和正则。果然PHP是世界上最好的语言！！！哈哈哈 filter_has_var笨拙的方法1if(isset($_GET["name"]) 最好的语言提供的方法1filter_has_var(INPUT_GET, "name") 返回值：成功时返回 TRUE， 或者在失败时返回 FALSE。 第一个参数可以填入的值有，看英文应该懂是啥意思吧ヽ(ー_ー)ノ type INPUT_GET INPUT_POST INPUT_COOKIE INPUT_SERVER INPUT_ENV filter_var笨拙的方法1疯狂正则，疯狂字符串拆解 优秀的语言提供的方法1filter_var("hhh@qq.com", FILTER_VALIDATE_EMAIL); 返回值：如果OK 会返回原值，如果不OK 则返回false 验证过滤 FILTER DESC FILTER_VA...
【转载】Github 的 Restful HTTP API 设计分解
原文地址：Github 的 Restful HTTP API 设计分解 什么是 RESTfulRESTful 是一种软件设计风格，由 Roy Fielding 在他的 论文 中提出，全称为 Representational State Transfer，直译为表现层状态转移，或许可以解释为用 URL 定位资源，用 HTTP 动词描述操作，不用太纠结于定义，接下来我们会详细讨论。 RESTful 风格的接口，目前来看，实现的最好的就是 Github API，经常被效仿。接下来我们通过分析 Github API 来引出我们的 API 设计原则。 为什么选择 RESTful我认为一套接口应该尽量满足以下几个原则： 安全可靠，高效，易扩展。 简单明了，可读性强，没有歧义。 API 风格统一，调用规则，传入参数和返回数据有统一的标准。 我们当然可以根据自己的经验，或者参考知名公司的接口总结设计出一套满足要求的接口，但是每个人对接口的理解不同，设计出来的接口也会有所不同，接口的命名，请求参数的格式，响应的结果，错误响应的错误码，等等很多地方都会有不一样的实现。当你去寻求一种设计理念来...
