就是 gossip 的思想吧，但这么搞怎么实现之前可以通过注册中心去做的那些路由调度、熔断、权重、灰度....

我觉得楼主你想法其实是对的，现在这样按层工程分包方式就是不对的。
从业务上讲，同一领域内的对象应当聚合在一起，这也是为了把领域内的知识都限制在包内，而不是散落在项目的角落里。
Node.js 在 Github 上 star 最多的 Best Practices 明确表明应当按业务分包。
为了照顾没有团队规范的多人开发，而抛弃正确的项目结构，我认为是本末倒置了。

我手上的 2720QM 还好，下边缝隙确实大了点，但屏本身还可以

直接 mono-repo 复用代码，但是分开部署

@mzmxcvbn
1. 都放在一层 dao 里，叫什么不重要，重要的这层只负责数据的加载和保存，你只需要调用标准接口，不需要关心存储细节；
2. 从 DDD 的角度来讲，每一个聚合根对应一个 DAO （ DDD 里叫 repository ）。但如果只从分层角度来考虑的话，是的，每一个 model 对应一个 dao ；
3. 对于 list 接口，你自己已经提到了，where/order by/limit 都只是“参数条件”，所以他们只是一个大接口的参数而已，这个接口的基础功能，就只是 list，至于怎么 list 、list 多少个东西出来、顺序是啥样的，只是参数而已

dao 还是要有的，未来如果需要在 data load 这个切面做事情的话，没有单独分层而是“server 层的代码中直接调用 orm 增删改查的方法。”会导致改起来很麻烦。当业务大到一定程度就没法改了。
其实如果还处于对性能要求不高的阶段，dao 层可以很简单，只有 list 、load 、save 三个方法。

至于 controller 和 service，我觉着确实一定程度上可以合并。现阶段大部分写事务脚本的业务，service 复用的机会不多。能复用的话也都会抽成单独的子函数。

建议楼主实践下 ddd，代码写出来会很清晰。

一般两遍，第一遍通读、跳读+高亮+注释，（部分书）第二遍主要读自己标记过的部分，然后整理成笔记

我们就 PM2 启 egg，没啥问题

你这需求明显 4K60，有钱 4K144，2K 没必要

只用时间戳，有可读性需要再单独转

magic number...这词儿不容易歧义吧

我来一个大炮打蚊子的，直接上 k8s liveness probe...

我还以为是专门在开会时候玩的游戏...
我还想呢，都这么牛逼的嘛

第一天六点到第二天六点，节假日加班加起来工时达到每周九天！
算了下好像 all in 都不够，打扰了 :|

我觉得 @yannxia 描述的就挺对的，个人理解云原生落地的体现出的最基础的特性就是面向 docker 、k8s 、SaaS 、DevOps 开发 SoA 架构（老东西但其实是一个玩意儿），简单来说就是业务无状态、基础设施服务化、CI / CD，屏蔽基础设施细节。比较详细的话是云原生的 12 因素吧，都满足应该就挺原生的？ https://12factor.net/zh_cn/
搞不清楚是什么应该也不重要吧，云原生对于开发来说确实是个好事儿，省心。

全上云的话，直接用服务商的备份功能不就好了？

没有自己的快捷键习惯么？没必要考虑为别人调 BUG 这种场景吧，除非你天天的任务就是跑到别人的机器上 DEBUG...

连接都是连接池复用的，连接不够自然就排队了，不会出现你说的并发叠加什么的。而且死锁不是这个意思的。
现实情况是，该调多少就调多少，除了明显犯蠢，不用想太多。

@visitant 跳板机的目的就是隔开网络区域，一个 ProxyCommand 又给干穿了就违背跳板机的初衷了吧。至少我司是明确规定禁止私自打通各个区域的，一般能通的都默认通，不能通的打通就是违规。