早就听说 ES5 的版本了，一直没有在意，但是直到最近正式版出来之后，才有了要升级现在的 ES 集群的想法，首先便是日志集群（2.3 版本），之前一直有问题：丢日志现象很严重，尤其是 GC 导致的静止现象，然后所用占用的空间非常大。 看 ES5 的介绍，以及网上其他人的经验，ES5 集成了 Lucene 6，性能提高不少，简单来说：** 磁盘空间少一半 &#...

为什么我们需要近来 HTTPS 越来越被大家重视，尤其是在 http2 出来之后。 流量劫持国内的网络环境很恶劣，运营商各种流量劫持，DNS 劫持，只是为了在你页面上加上几个小广告，或者更严重的，是否还记得 12306 抢票软件拖垮了 github？对于流量劫持，很简单的方案就是用 HTTPS，流量加密之后就可以解决。（说句题外话，DNS 劫持的话，http...

在业务安全性方面，我们常常会用到接口限流，主要是为了防止系统压力过大、保证每个用户请求的资源保持均匀以及屏蔽恶意请求。 几个常见的场景如下： 恶意注册 爬虫的过度抓取 秒杀场景 目前实现 API 接口限流的方式有几种常见的，简单来说原理很简单，无非是在一个固定的时间段内，限制 API 的请求速率，一般来说是根据 IP，如果是登录用户的话，还可以用用户的 ...

最近看 APM 上面的 API 响应，发现有个 API 在挑事，平均响应时长 4s，已经到了不可忍受的地步。 仔细一看，发现是动态有关的 API，类似于微博，进一步分析发现，这个 API 设计不合理：用了 mongo 的 aggregate，占了响应时长的 90% 以上，这个不适合在 API 使用，因为非常耗数据库的计算性能。 Mongo 数据库结构1234...

众所周知，配置在项目开发中非常重要，一般来说，我们都会根据环境会有不同的配置，比如本地开发会配置本地机器的数据库，测试时还会给数据库设置不同的本地数据库，然后线上线下也会有不同的配置，其中非常值得注意的便是：生产环境的配置，因为这些配置非常敏感，需要加密。 把配置直接放进代码管理 repo 是最低级的做法：历史记录会有永远记录着配置中的敏感信息，看过不少初学...

不知道，你有没有遇到类似的情况： 不重视测试，开发新功能都是手工测试 每次开发新功能，都会懒得去做回归测试，线上经常出问题 新同事来，不熟悉系统，提交的代码会把系统搞坏 测试覆盖率一直非常低 这时候，你需要个 CI，也就是持续集成。 我理想中的团队开发流程中，CI 是最重要的一环，团队成员按照 git flow 开发，然后提交，等待 CI 测试通过，最后...

很多同行都会想，当自己做到一定程度了，应该会去做技术专家，或者管理岗位。 只是，现在的很多同行是这样的，我很喜欢钻研技术，并且，我还想往管理岗位上发展，但是遇到一些团队管理的时候，往往不想去处理。 原因？很简单，因为搞定团队内部的琐事，把团队带的井井有条，远远比不上自己去钻研新技术，提高团队的生产力带来的快乐要多。所以，这样的人，不太适合往管理岗位发展。而管...

日志收集的重要性不言而喻，总结下在日志方面做的一些尝试： 日志收集的选型目前 nodejs 比较流行的工具有 winston，log4js，还有 bunyan，也是我用过比较多的，总体看来的话，winston 功能丰富，log4js 老牌有保障，bunyan 比较轻量级，我最后选择了 bunyan 是因为看中它的轻量级，怎么说呢，winston 太复杂了以至...

没有什么运维问题是一起重启解决不了的，如果有，那就两次。 — 🙈 今天又栽在 mongodb 索引上了，哥们又在我不知情的情况下，加入了新建索引的代码，也怪我，没有 review。两亿多数据啊。。。。天。。。。 于是我们的平均响应时长就跟过山车似的，一波未平，一波又起，甚至一度达到了我入职以来的最高值，6kms。 没办法，先重启，回滚了刚上线的代...

最近总能发现，很多东西，我在实践中总结出的的经验，都是别人在书中提到过的，就比如《重构》这本书，我一直认为重构不应该拿出专门的时间，而是应该在开发新功能或者修改 bug 的时候去做，作者也非常强调这种观点： 不用专门时间，随时随地，比如以下三种情况：添加功能时修补错误时复审代码时 比如在一个人员缺少的阶段，如果你跟产品汪或者 CEO 说，我需要几个星期甚...

今天尝试了用 redis 的 set 作为缓存用途，恩，好疼。。。 是这样的，看到项目中用到应用缓存的地方很少，为了减轻 MySQL 数据库的压力，特地引入 redis 作为已购买物品的缓存，但是物品不能重复购买，因此这个缓存还得支持重复性检查。 于是很自然想到 redis 里面的 hash 或者 set，然后，有个问题就是，当 hash 或者 set 没有...

这些日子为了解决业务上的挑战，想要解决 MySQL 的性能提升方案。 目前找了主要有： 分库分表 读写分离 读写分离最简单，牺牲一点一致性能减少读的压力，分表也比较简单，但是目前没有特别合适的中间件，结合我们的业务场景，分库是目前最适合下点功夫的。（另外还需要做高可用，可以做双主，但是不需要我过多参与，因此这里不谈。） 背景介绍 MongoDB 用来存储...

nodejs 这些年来的发展迅猛，一个重要的条件就是 npm，npm 这个包管理工具很强大，如果没有这个工具，很难想象没有 npm 的 nodejs 会发展到什么程度，golang 或许可以是个参照：发展到现在，一直没有一个统一并且非常规范的包管理工具。 我一直想很相信，任何东西的发展，离不开好的基础，无论是个人或是国家： 个人，需要多学习，多锻炼，提升自己...

先从一次面试经历说起，记得有次面试，我问被面试者一个 API 文档的问题： 『用 gitbook。』 我呆了一下『那如果你们修改了 API 接口，怎么修改文档呢?』『我们文档也用 git 管理，直接修改提交。』『那你们有没有某次代码修改之后，忘记修改文档了?』『……』 我想在实际开发中，这样的做法很容易顾此失彼，忘记更新代码，造成了文档与代码不一致的情况...

今天正在家里加班的时候（哎。。。不多说。。。），突然接到电话，mongo 出问题了，同事把某个 collection 的索引给删了，新代码上线之后，mongo 不断在重建索引，经过立马回滚代码之后，还是继续在重建索引，用 db.currentOp 来看，索引一到 99% 就重建，也就是重新开始建立索引。 在 APM 上面看到响应时间慢了 5 倍左右，一直不断...