vendor 目录究竟应不应该进 VCS

很多项目现在都有组件式的包管理,比如 composer 管理的第三方组件都存放在 vendor 目录下,那么究竟这个目录应不应该放到 git 之类的版本管理里去,之前我的做法是不放,但是后来发现了一个问题,当多台机器面临更新第三方组件的时候,会出现版本不一致的问题,而且本身 Laravel 的 config/app.php 中启用了第三方组件,但是 vendor 目录中还需要 composer update 更新的时候就会报错;

所以,vendor 作为整个项目的一部分,应该放进版本控制系统(VCS);在部署打包的时候也是一份子,编译打包进入 Docker 之类的容器,进行整体的部署,也才能够保障每个服务器上运行的代码是一致的;

用dnsmasq设置本地开发dev环境

作弊条一个,主要是为了映射多个项目的.dev泛域名解析到localhost

brew install dnsmasq
cat << EOF > /usr/local/etc/dnsmasq.conf
address=/.dev/127.0.0.1
listen-address=127.0.0.1
port=35353
EOF
sudo mkdir /etc/resolver
sudo chown `whoami`:admin /etc/resolver
cat << EOF > /etc/dev
nameserver 127.0.0.1
port 35353
EOF

使用了brew services的话还可以直接brew services start dnsmasq就启动了

设置Sublime Text 3下的PHP开发环境

需要做一些PHP的开发工作,工欲善其事,必先利其器.

brew tap homebrew/homebrew-php
brew install curl
brew install php56 --with-homebrew-curl
brew install phpmd php-code-sniffer  php-cs-fixer

在Sublime Text 3里cmd+shift+pinstall package,安装如下插件

Update: 2015-10-22 19:13
更新一下,配置一下可以让代码清晰一些了呢

{
"phpcs_path": "/usr/local/bin/phpcs",
"phpcs_show_errors_on_save": false,
"phpcs_show_gutter_marks": true,
"phpcs_outline_for_errors": false,
"php_cs_fixer_on_save": true,
"php_cs_fixer_executable_path":"/usr/local/bin/php-cs-fixer",
"php_cs_fixer_additional_args": {
"--level=psr2":"",
"--fixers=operators_spaces,align_equals,align_double_arrow,remove_lines_between_uses":""
},
"phpcbf_path": "/usr/local/bin/phpcbf",
"phpcbf_on_save": true,
"phpcbf_show_quick_panel": true,
"phpcbf_executable_path": "/usr/local/bin/phpcbf"
}

在debian使用npm安装出错

在一台Debian机器上部署Laravel,nmp install的时候总出错,错误如下

sh: 1: node: not found
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian

nodejs一定是通过apt-get安装过了,查过之后就是还有一些老旧的package在使用node,所以需要安装一下apt-get install nodejs-legacy,之后就OK了

ref

关闭ElasticSearch自动匹配

这几天在弄ElasticSearch来分析日志,突然有一天早上8:00之后的日志就进不来了,看了分析程序运行正常,服务也正常,只是ElaticSearch的日志增长很快,其中比较值得注意的就是这条了。

Caused by: org.elasticsearch.index.mapper.MapperParsingException: failed to parse date field [22-Nov-2013 12:24:30], tried both date format [yyyy/MM/dd HH:mm:ss||yyyy/MM/dd], and timestamp number with locale []

看起来应该是mapping的问题,对比了一下当前的mapping和之前的,确实有一些不一样,timestamp之前是string,现在成了date,本着调整一下mapping就可以的思路,调整了,开始有数据可以进来了,但是错误还是很多。

仔细看了一下,ES有一个date_detection的机制,得把这个给关了,停止他对时间字段的自动mapping。

CONFIG_DIR下放一个default-mapping.json就可以从cluster级别关闭了。

{
  default : {
    "date_detection" : false,
    "properties" : {
      "@timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      }
    }
  }
}

Think about capacity plan 容量规划

做服务运帷的人员除了解决各种杂七杂八的问题之外,还要时刻的关注业务的增长和服务的容量问题。

要对容量有一个准确的评估并不容易,要考虑的因素比较多,突发的情况也比较多,另外有些时候容量的增长并不是一个线性的过程。

以下是我对容量规划的一些体会

首先是要对系统的构架有足够的熟悉,明确的知道系统的扩展瓶颈在那里,以互联网产品来说大部分的扩展瓶颈都是在DB上,这种情况下,DB的扩展能力就是容量规划的一个极限。从构架上来说,分库分表,增加Cache层都是提升DB扩展能力的手段,使其扩展更趋向于线性。

其次,对整体系统和单一系统进行压力测试和容量测试,找到最大承载和最佳承载。

最后,要建立一个业务数据和系统能力间的关系公式。假定业务数据是日活跃用户(DAU),以Web服务来说,每秒请求数(RPS)就是一个很好的指标做参照。使用RPS比上DAU得到一个RPS/DAU的比率,再结合之前测试的最佳承载,就可以得出值得参考的容量规划。现实情况要更加复杂,特别是有些业务系统涉及的因素比较多,就要拿到多个因素的比率,以其低点为参照。比如DB,在关注存储容量的同时还要关注请求数以及响应速度等多个指标,所以关系公式也就要考虑多个因素进去,按每个因素算出容量,再取其中的最大值。

容量规划本身是一个参考值,估算的精确非常有助业务的发展和成本的节约。同时他作为一个参考值又需要不断的根据业务特点和构架变化作出调整。

bash的退出和后台执行的进程

前天的一个事儿,在这儿计一笔。

后台执行的脚本在shell退出的时候也会退出,所以退出shell后还要继续后台进程就要加nohup,但是在bash下不是完全按照这个来的,如果bash正常退出,他不会向后台进程发SIGHUP,如果异常退出,比如ssh连接因超时中断,bash进程本身收到SIGHUP等等,就会发SIGHUP给后台进程了。
Ref: