Introduction

elastic-apm-node 提供了非常友好的定制化支持，本篇将示范如何为 express 框架添加路由 patch，以满足信息上报的优化。

前言

苦于 hexo g 的效率问题，与其重新折腾框架，决定在彻底忍受不了之前再实行一点儿补救措施——依赖升级。

Hexo 主题 NexT 5.1.x 已经很久不维护，传说新版本 7.1.x 的速度有显著提升，它是本次的重点升级对象。这里只记录 Next 主题的变更，因为 Hexo 主体和其他依赖的升级都十分平滑，没有明显的 breaking changes。

前言

根据上一篇《Node.js APM 产品调研》的市场调研结果，笔者更青睐 Elastic APM 这个开源产品，故决定带来它的一篇专题介绍。

尽管团队已经开始试用，但踩坑时间较短，与其编写测评，不如先带大家走进这个项目，剖析个别令人感兴趣的技术点。

前言

服务进程登场时往往“蓄势而发”，犹抱琵琶半遮面，真正的服务端口跑起来之前做了太多准备工作，然而落幕工作常被人草草了之。

如何让进程自然结束，这本是 hello world 级的基础内容，却有很多项目忽视了这一步的必要性以及重要性。

目前使用 PM2 作为进程管理的项目仍占多数，有相关意识的朋友使用 pm2 reload 让进程“平滑”重启，但这就不需要额外的代码处理了吗？

举个例子，未捕获的异常导致服务强行退出时，是不是有可能进程尚未记录异常日志、请求执行到了一半、甚至中断了更复杂的业务工作？PM2 只能截住新的请求，旧的请求是否彻底执行完毕，仍需要业务自己判断。

下面我们先抛开 PM2 ，聊聊基本的进程退出需要哪些工作。首先我们从未捕获的异常说起。

前言

突破查询瓶颈的方法有很多，但这里先不谈分库分表之流，当头问题就一个：单数据表分页查询过慢怎么办？

其实讲分页优化的博客真不少，但很多博主只顾分享点子忽略了细节，还有很多值得补充的地方。笔者回顾了曾经在千万级 BBS 项目的优化经历，尽可能结合实际地聊聊个人对分页查询的见解。也希望读者在亲身操作中验证，任何优化脱离了实际场景都是纸上谈兵。

前言

部署 RabbitMQ、MongoDB 或其他服务的单节点，有时会将 bind_ip 之类的设置写作 127.0.0.1。然而在 Debian 系统这么操作可能就给自己挖了“坑”，不管你有没有遇到过 host 相关奇怪的部署问题，来看作者的一波填坑历程吧~

Debian 的 默认 hostname 配置

在 Debian 系的 Linux 发行版中，/etc/hosts 中前两行默认配置如下，其中 myhostname 即 /etc/hostname 指定的本机名称，可通过 hostname 指令查看。

1
2

127.0.0.1 localhost
127.0.1.1 myhostname

第二行配置将本机 host 指向了 127.0.1.1，这又能对软件的安装造成什么影响呢？请看下面的例子。

svn 给笔者的一大印象就是非常容易产生冲突，特别是项目加入新人后，由于初期没有强硬地制定规范，导致后期合并代码时灾难连天。决定在此分享这些“亡羊补牢”的规则，也算是避免 svn 产生合并冲突的一点经验。

问题

原始需求是通过 nginx 在请求链接中增加一个固定参数 custom_param，方法很简单，在 location 中重设 $args。

1
2
3

# in location xxx
set $args $args&custom_param=test;
proxy_pass http://remote_host;

顺便说一下，即使链接中没有参数也不影响一般服务端解析，符号?会自动加上，如上例子 proxy_pass 后会路径将变成 http://remote_host/xxx?&custom_param=test。

但问题是在服务器如此配置 nginx 后，custom_param 参数并没有如约发给 remote_host……

有关被 nginx 官方自我批判的 if 语句，《If Is Evil》—— 着实应成为每位开发者初次使用 nginx if 之前必读的文章。

即使笔者一年前就开始接触使用 nginx 和 if 的组合做 url 跳转，但涉及的功能太简单，一直没能见识到它的真面目。直到近期在多个 if 内处理 proxy_pass 时，噩梦果真就降临了……希望大家仔细阅读上面的文章，引以为戒。

如果想快速知道为什么 “if is evil”，以及如何避免被坑，可以向下阅读一探究竟。