可行啊，我这样做一年多了，打包成单文件丢 alpine/slim 容器，体积小了很多。
比如拿个简单的 NestJS 的程序打包出来也就四十多 MB 吧，丢到 alpine 也就加 5MB 。
好处是在 serverless 环境里避免了 node_modules 大量碎片文件拖慢解压速度，以达到提升冷启动速度的目的。
唯一的缺点是接入 sentry 这种异常监控告警，定位到的代码不那么准。Deno 接下来重点也在兼容 Node.js ，到时又会多一个打包成可执行文件的方案。

每次看到线程池的八股文，我就有种别样的感觉。

.NET 3.5 (2007 年)就支持 async/await
Golang 1.0 (2012 年)发布。
Node.js 6.x(2016 年)开始实验性支持 async/await ，2017 年的 8.x 正式支持
Python 3.5(2015 年)开始支持 async/await ，不过由于 Python 不是像 Node.js 这样的天生异步，还有大量标准库和第三方库仍然使用的是 IO 阻塞模型，所以刚出来那几年还比较鸡肋。
Ruby 3.0(2020 年)开始支持 Ractor 和 Fiber Scheduler ，我觉得它正在经历 Python 3.5 async/await 刚出来那几年的过程。

2022 的 java 面试经验：我跟面试官聊了一个小时线程池
你说像不像 IE 浏览器？
https://pic2.zhimg.com/80/v2-fdd5ebc5f8a0ca5b6c5cf3618b79650d_720w.jpg

选大而全的。

大而全框架带来的是一整套的成熟的解决方案，不需要自己东拼西凑搞半成品，比如当年屌炸天的 Ruby on Rails ，指导了多少框架，前端工程化惊为天人，缓存利用到极致，ORM 设计更是被现在的框架各种抄。简陋的框架只会让别人去拼凑，最佳实践都很少，也不利于开阔视野。看看 python web 那些从 Flask 转到 Django 的就懂了，还有现在的 FastAPI ，流行度比 Sanic 高多了。

排除单独吹 Serverless 的，因为各大云厂商 Serverless 都支持跑 docker 镜像，自己拿 pkg 打成单个可执行丢 slim/alpine 镜像就搞定了，也就几十 MB ，冷启动快得一批，而且 Deno 接下来重点也在兼容 Node.js ，到时又会多一个打包成可执行文件的方案。再看看云厂商那蹩脚的 layer 层设计，让你把 node_modules 放那里，一堆碎片文件妨碍启动速度，不靠谱，狗看了都摇摇头，搞不好还是网络加载的。

单独面向微服务的也可以排除了，比如 Moleculer ，这年头微服务直接上 k8s 然后纯 http 互相调用，无状态简单得一批，可观察性也好，工具链也成熟，还能精细控制流量。

排除 Midway.js ，阿里的开源大家都懂的，三年前我第一个 Node.js 项目用它就碰到一些弱智 bug ，懒得再看了。

排除没用 TypeScript 的，Sails/Hapi 拜拜。

AdonisJS 的纯 TypeScript 版出来太晚了，挺像 Laravel ，PHP 转型到 Node.js 的会喜欢，不过很多 PHP 都觉得转 go 会更好。

所以没什么好选的了，早知道，还是原道，哦，还是 NestJS 。

@Proxy233 触发器要通过绑定他们的 api 网关才支持 WebSocket ，TCP 不支持

@changdy 在数据库中间件配 hook 就搞定了，不用解析日志

@yangyaofei 没有用工具，自己写了几十行 nodejs 的代码就搞定了。

@changdy 完全没考虑，按我的估算数据量到 10 亿，磁盘占用也不到 500G ，在云厂商那里磁盘拉一下进度条扩容就完事了。而且云厂商对 pg 的分布式不太友好，想引导你去它魔改的云原生的版本，贼贵，还不如后面自己用 citus 扩展自建

从付费消息刚出来就绑卡了。
作为正则表达式苦手，我一般在上面用注释放一段样例数据，下面注释放我要提取的数据部分，然后起个包含 regex 单词的变量，它就会帮我补好正则表达式了，非常节省生命。

一开始我也想踢掉 es （ 2c4g 3 节点，580 元 /月），因为我们业务就一个 2c4g 的 PostgreSQ （一主一从，480 元 /月），一张单表同步到 es 做检索，我想 PostgreSQL 搞全文检索问题应该不大。

场景就一个单表（目前千万级，一年内会亿级）的多字段（ 27 个字段）的由用户发起的不确定条件的联合查询 + 几个字段单方向排序。

一开始我验证的是 PostgreSQL 全文检索，腾讯云升级到 4c8g 的一个月才 980 元，开 zhparser 扩展的确很快，几毫秒就搜出来了，但是任意几个字段组合检索就慢得要死（几百毫秒到 1 秒多），更别说 count 一下条数或者 odery by 了。

而在 es 里，2c4g ，检索速度非常稳定，任意字段组合检索都是十几毫秒，于是我打消了踢掉 es 的念头。

你可能需要的是云函数（ serverless ），https://help.aliyun.com/document_detail/179379.html 阿里云云函数环境最高支持 16 核 32G 内存，做个 docker 镜像丢上去跑就可以了。

“你电脑内存多大”
“1T”
“哈哈哈真是小白，哪来 1T 的内存，那是硬盘”
“没错啊（打开机箱亮出主板上 8 条 128G ECC 内存）”

“你项目多大并发”
“10 万”
“哈哈哈你知道 10 万并发是什么概念吗”
“没错啊（打开日志 /监控上的某一时间范围的数据统计，那里显示着峰值时每秒有 10 万次左右的请求）”

异曲同工之妙（ dog

观念问题，一堆黄色的告警中往往隐藏着潜在 bug ，机器都能看出来的问题为什么要视而不见，所以我从业以来就是全部清理的，前期比较蛋疼因为 IDE 一升级加了规则又会多好多告警，不过我也会专门清理完。带人也是这么宣导的（前提是工具链统一），基本上呆的每个团队我都会在第一个月持续灌输这个理念，基本上后面就不会出现了。

其实带来的好处很多的，比如新增的代码里 IDE 告警了，你会很敏感，会多思考一下，特别是以前写 PHP 的时，IDE 能发现的告警基本上都是一些潜在 bug 。

换位思考一下，2 个功能差不多的代码库，一个 IDE 能提示出 2000 个告警，另一个库几乎没有告警，你会觉得哪个质量好？

@dzdh 我觉得主要看你们是否把调整配置当成一次发版（更新容器）进行操作，如果不会线上 reload 那的确可以直接单个文件一把梭。

reload 用于一般用于蓝绿部署，nginx unit 的条件路由可以很好的控制流量，比如通过特定 header 字段和值进行流量切换，比如把测试账号引流到特定节点。

另外不建议把 nginx 和 php-fpm 分开部署，因为 php 的 curl 功能过于强大，如果代码逻辑不严谨或者缺乏安全团队测试，不恰当使用 curl 的话，会被和 gopher 组合构造出任意代码给 php-fpm 执行（相当于后门）。

@dzdh nginx unit 说白了就是更容易编程化的 nginx ，你也可以把 json 写到文件，然后给 post json 文件的 curl 命令做个 alias ，就能达到修改配置文件 + nginx -s reload 的效果

上 nginx unit 就可以把 php 和 nginx 二合一了

电子书啊，绿色环保。
纸质书的示例代码段，你都不能复制到电脑运行…

喜欢轻薄和续航,那就捡二手 code01 呗,一代 90wh 电池随便浪

二手 code01 行情:
32g + 512 约 3000
16 + 512 约 2500

单条笔记本 32g 内存条行情:600 不到
code01 全新个电池行情:约 220

中端 1t 固态约 600,
中端 2t 约 1200

二手 code01 随便折腾,现在买到的还有保修,坏了不心疼,而且内存和固态还能随便迁移,7k 预算甚至可以买 2 台 code01 做冗余

看 code01 产品经理微博，12700h 的 code01 没被批准立项

是因为 intel 挤牙膏...
我之前在选 vps 的时候，看到 https://contabo.com/en/server-outlet/ 居然还有 i7 920 和 i7 3770 配置的服务器在卖，去 intel 官网看了下规格...
i7 920 是 2008 年的产品，4 核 8 线程，频率 2.66 GHz ~ 2.93 GHz
i7 3770 是 2012 年的产品，4 核 8 线程，频率 3.40 GHz ~ 3.90 GHz

好家伙十三年前的 cpu 都还能继续放在服务器上卖呢

而去年轻薄笔记本比如 ThinkBook 15 吹的 "11 代 i7" i7-1195G7 ，是 2021 年的产品，4 核 8 线程，频率 2.90 GHz ~ 5.00 GHz

直到 2021 年，部分轻薄本的 cpu 频率还和十年前的 i7 这种家用处理器差不多，给十年前的 cpu 配个 SATA 接口的固态，再搭个 16G~32G 的内存，普通上网和办公场景和现在的主流机器你几乎察觉不出差别。