杨绛先生

今天在朋友圈刷屏了,不想跟风,干脆在这里写点东西,权当念想。

第一次听说杨绛先生,是在高中,有篇语文中学到的,关于她跟钱钟书先生的故事,记不清了,那时候很奇怪,为啥女的也可以叫先生,后来才知晓,先生是一种很少的女士能有的尊称。

她的那句 『你的问题就在于读书太少而想的太多』,足够受用终生,很多人,尤其是我自己,在几年短短的职业生涯中,感受到,很多问题,不能干想。

阅读全文

轻量级消息队列 Kue 的一些使用总结

最早接触 kue 是在 0.7 之前的版本,功能很少,很弱,但还是很好用的,那时候找过一些其他的消息队列,如 rabbitmq,kafka 之类的,但是都觉得太重了,跟 nodejs 的融合还是不太合适。

找着找着,就找到了 tj 大神搞的 kue,基于 redis 的 subpub 做的优先级消息队列,适合做一些离线任务,比如统计运算、发邮件消息以及异步业务逻辑。

阅读全文

数据库分页最佳实践

2016-06-22 更新:

MongoID 不能保证连续增长,因此,在这种情况下,不适合此种方案,如果是为了保证速度以及效率的话,可以放缓存,比如 redis 以及 memcached 之类的。

阅读全文

Node.js APP dockerize

今天把做的项目直接做了 docker 化,一个是前端纯静态化的,另一个是后端 Node.js App,对于这两个项目,想用最简单的方式来使用 docker

静态项目最容易,直接用 nginx,将编译好的静态文件直接丢到 volums 里面即可:

1
2
3
4
5
6
7
8
version: '2'
services:
nginx:
image: nginx:latest
volumes:
- ./build:/user/share/nginx/html:ro
ports:
- "8080:80"

阅读全文

Docker ELK 搭建经验总结之二

运维了这么些日子的 ELK,解决了些问题,总结如下:

禁止内存换出 memlock

在 docker 中运行 elasticsearch 有个很大的问题就是

阅读全文

软件开发中的完美心理

很多时候,会发现会有一种求完美的心理:

  • 这个功能实现好差,重构下吧;
  • 新出了个工具或者框架,在项目中试试吧;
  • 试过新工具或者框架之后,恩,好棒,用来改改其他的项目;

阅读全文

爬虫方案之 PhantomJS

发现 zombie.js 还是太弱了,很多地方不能满足需求,包括 request 的 HTTP 头也不合乎标准,于是硬着头去尝试下 PhantomJS。

这一试,我就后悔了,这么好的东西我居然不先尝试!怎么说呢,它比 zombie 好用太多,加载处理速度方面也是远远超过。唯一比较遗憾的是没有原生的 nodejs 接口,它只是一个环境,像 mocha 这样有自定义的变量,需要用它去执行 js 文件。所以如果要用到爬虫上面的话,需要通过第三方的包去包装一层。比如我用的 https://github.com/amir20/phantomjs-node

阅读全文

爬虫方案之 zombie.js

这几天在做爬虫的东西,腾讯的登录真能把人搞死。。。
首先是对 http 头做了校验,一旦顺序或者大小写不对,立马报 403 错误,然后最后密码加密那块 md5 + salt + RSA + 还有自创的 TEA 加密,我完全被搞晕了。

只能说它们的安全措施是做得非常好的,我搞了几天,完全用它的 JS 代码,本来还有希望的,今天再一看,登录相关的逻辑又改了。。。

阅读全文

管理后台最佳伴侣之 NgAdmin

这几天为了给系统新做个后台,到处找开源项目,真给我找到了,https://github.com/marmelab/ng-admin

阅读全文

Webpack 在后端 APP 中的使用

一直都说,webpack 一般只作为前端项目的开发工具使用,非常方便,但是因为它太好用了,而且 react 后端渲染也需要用到,所以纯粹用到后端项目也是可以的。

比如我用在 koa 项目中,为了更好得使用 babel,(babel-node 太慢了。。。项目大了之后挺要命的。。。),用 webpack 的 hot reload,缓存,然后部分编译,不要太爽~

阅读全文

Docker ELK 搭建

记得上次说到的 #1 中提到,需要搭建 ELK 来实现数据需求,其实还有另一个需求:日志系统。

联系到最近一直在看的 docker,我就直接用它来部署了,申请了台 8 核 16G 机器,CentOS7,其实 ELK 还是得深入看看,毕竟 docker 只是用来部署,而不是帮你解决日志系统的问题。

阅读全文

记一次 mongo 性能提升报告

最近的一直进行的工作包括提升 mongo 的性能,在我接手的这段时间里,在 newrelic 上的平均响应时长是 200-300ms,遇到任务堵塞还会暴涨到 600ms 左右一小段时间。

第一次

尝试是升级 mongoose@4.4.9,效果是很明显的,响应时长立马降下来了,平均响应时长 100ms 左右。但,我们观察到 mongo 的连接数直接升了一倍,app 进程在阶段性重启,大约是 20 分钟一次,因为我们用 pm2 的时候,设置了最大内存,一旦超过就自动重启,于是我们放弃了。

阅读全文

关于 pm2 的弱项

部署 deploy

由于我们线上项目全部部署在高配主机上,使用的是 pm2 部署,于是当我刚接手的时候,十几台主机全部用 pm2 部署的意义不知你是否明白,每台部署至少 1 分钟,然后串行部署,于是开始部署之后,可以很悠闲地去喝杯茶了

阅读全文

express 中的 trust proxy 设置

一般来说,我们的项目都是放在反向代理后面的,比如 nginx,haproxy 之类的,这时候就会有个问题,你获取的 IP 地址可能一直是前面代理的 IP,而不是用户端的 IP,于是这时候 express 就需要设置下 trust proxy 了

默认是 false,也就是不信任任何代理,比如你所在的私有网络是 10.0.0.0/8,那么直接设置:

阅读全文

记一次 Mongo 连接配置调优

话说在我接手公司的项目后花时间去优化 API 性能的时候,在 newrelic 上面看到,大部分都是 mongo 的时间,因此很有必要花大时间去优化。

我们用的是 mongoose@3.8.23,然后修正了其中的复制集排序选择问题(3.8.39 已经修正了,目前我正在比较测试,包括目前最新的 4.4.x),先把项目的连接配置贴出来:

阅读全文