Jiasm

在当前公司接近 4 年，同时也是社会工龄接近 10 年的节点，思来想去还是记录一下过去这十年发生的事情和思考，毕竟可能没有下一个工作的十年了 :(

公司内部的 NPM 因为一些固有的 bug 经常被吐槽，最近刚好有时间可以来做优化，然后就尝试解一下之前遇到的一个 publish 的 bug，下边是分析记录。

一个 zsh 特性引发的惨案，期间被迫翻看源码绝望之中偶然发现问题所在，挥泪写下记录避免其他人遭遇同样的问题。

最近我们团队接手了一个需要定时重启才能用的遗留项目，记录了完整的排障流程。主要涉及一些 TCP 相关的东西。

上次针对 redis 的源码阅读涉及普通的 client，这次针对 cluster 模式下的 client 源码进行分析。 具体的源码路径就是在 lib/cluster 目录下了。

从项目中看，源码都在 lib 文件夹下，是一个纯粹的 TS 项目。 lib 目录下的文件主要是一些通用能力的提供，比如 command、pipeline以及数据的传输等。 而下分的两个文件夹，redis 与 cluster 都是具体的 redis client 实现，clust…

其主要逻辑会集中在 数据的序列化/反序列化 以及 数据的传输上，而这两项 gRPC 分别选用了 Protocol Buffers 和 HTTP2 来作为默认选项。 gRPC 在 Node.js 的实现上一共有两个官方版本，一个是基于 c++ addon 的版本，另一个是纯 JS…

其他的一些功能就都是基于 PM2 之上的辅助功能了。 PM2 的项目结构算是比较简洁的了，主要的源码都在 lib 目录下， God 目录为核心功能多进程管理的实现，以及 API 目录则是提供了各种能力，包括 日志管理、面板查看系统信息以及各种辅助功能，最后就是 Sysinfo …

可以看到，最后会匹配一个 .node，而后边的描述也表示该后缀的文件为一个二进制的资源。 而这个 .node 文件一般就会是我们所编译好的 c++ 扩展了。 日常的开发其实只用第一项就够了，我们用自己熟悉的语言，写一段熟悉的代码，然后发布在 NPM 之类的平台上，其他有相同需求…