nest如何实现多进程间通信和egg类似的agent机制
发布于 6 年前 作者 yuu2lee4 9054 次浏览 来自 问答
17 回复

直接用 egg ~

  1. nest 在 cluster 这块没有特殊定制,直接用 pm2 之类的启动 cluster 即可。
  2. 首先要看你的场景是否需要 agent? worker 之间一般不互相通讯的。
  3. 其次你需要在 bootstrap 的地方自己去 fork 个 agent,然后通过 ipc 去做通讯就好了,都是 Node 自己的 API,简单封装下即可。可以看 egg-cluster 源码。

不存在的 nest 根本就没用到 cluster 模块,https://github.com/nestjs/nest/blob/1be2ccdb0b80e8be169471582e6ef7ac183a0625/packages/core/nest-application.ts

而 egg https://github.com/eggjs/egg-cluster/blob/0a9adbed8aee42523764d7ab4ea06800cdcebb18/lib/master.js

要实现的话,首先要实现内部通信机制,之后再通过 cluster 启动。进程模型是通过 sdk-base 和 cluster-client 实现的。

@okoala 不好用。 nest.js 对 ts 支持更完善,也更像spring ,分层更好。

如果你只是为了榨干多核CPU性能的话 用 pm2 start xxx -i 核心数 即可。

node 的辅助线程实际上也利用了多核处理, 多进程的话一般会有进程间通信问题,实际提升不大,由于存在进程间通信,反而降低效率。

如果为了性能,将 nest 的底层框架从 express 换成 fastify ,能提升50% 以上。

我们实际在使用中,用到了微服务,通过启动多个 node 容器来榨干性能。

1.egg有自身的优点 比如要跟另外一个服务建立长连接 只用agent连接就好了 把脏活累活丢给下面的workers去干 也就是说虽然是多个进程 但只需要一个连接即可 尽管agent也许会挂掉 但同样可以依靠pm2复制这样的通信节点(master-agent-worker)

2.使用nest 同样是长连接服务 如果不自己去开发egg那一套 则需要依靠pm2实现同样的可靠性 结果就是每个进程一个连接 大大浪费了连接资源 不过通信稳定性倒是更加可靠

目前来说nestjs还有着缺陷 不易使用 作者也没时间去完善文档 很多重要的细节都没提到 特别是microservice这部分 还耦合了Rxjs 多此一举 mqtt通信的topic还强制加了ack 后 缀 表示很蛋疼

进程间通讯没有那么难,本人使用过koa,但是因为项目需要独立运行,数据库migration,还有各种定时任务和自动触发任务都需要进行配合,所以进程间通讯是要非常重要的,就简单写了master的通讯,后来学了egg,发现egg开发应用正是使用nodejs进行这种类型的应用服务所需求的架构,其他都无所谓,就是看中了agent和worker的设计。其他框架如果没有实现IPC,自己使用cluster就好,我觉得很多应用包含了定时任务、缓存等独立业务的,不是说效率不效率或者是性能不性能,用nodejs,不考虑进程的业务,其实并不是一个完整的应用。比如一个需要精确控制“连接池”的应用,使用nodejs去写,又想启用多核,进程间不同的“池”如何统一这个需要考虑,而不是无脑pm2,又比如一个定时任务,需要大量io且不能重复,这个定时任务需要应用本身去实现,不考虑IPC?每个进程都去走遍?所以,nodejs写程序,多少都先考虑业务在多进程下是否适合,再去选怎么做,而且我觉得任何框架,根据自己的业务需求去制定一些ipc,比起什么性能,难道不是想用nodejs去快速搞好这个项目比较重要吗?再说了,性能能差到哪里?像log4js都内置又ipc,我自己写的业务可能都没它的多,我不见得我的应用性能卡在了这。

@HobaiRiku 目前egg最强 毫无疑问 如果全面使用ts 基本没对手了

@phper-chen 每个进程一个链接这种模式浪费我觉得就浪费吧,毕竟链接这种资源在大多数情况下是比较富裕的资源。其实nest作者也可以考虑egg这种连接方式,但没有社区贡献的话这种事情肯定没啥优先级。 nestjs不光microservice依赖了rxjs,是整个nestjs都依赖了rxjs

@phper-chen 我觉得没有谁最强,老是说谁牛逼,像搞推销搞纠纷,一点意思没有,我觉得是不管对于什么xxx.js,有问题是肯定的,大家提出来,可以互相参考,根据个人爱好或者需求去舍取或者模仿甚至去创新,这才是提升呀,比如对于我们公司,egg只会适用于自己使用,或者客户直接托管与我们的项目,其他网络服务应用的软件(需要交付客户自行部署运行,需要进行保密的),用没有明确入口文件的egg模式是没办法打包加密的,这种情况下,如果继续用nodejs,那就必须用nest或者原生koa等,或者就用其他语言比如go这种去完成,没有哪个xxx.js是万能的,也不可能完全都是用xxx.js就一定能做完所有事情,我只确信一点,用nodejs很开心,很快,很有效。

@HobaiRiku 说的很好,开源更多是为了看到更多的不同,互相促进。就像没有 Vue,Angular,React 三国争霸的世界,是多么的 bornig 。 脱离场景去讨论框架,是耍流氓,每个团队的基建技术栈,每个 Leader 的技术倾向,都会影响到框架的选择,框架也不是银弹。

需要交付客户自行部署运行,需要进行保密的),用没有明确入口文件的egg模式是没办法打包加密的

PS 下,Egg 是可以有明确入口的,只需要自己写个 index.js 调用 startCluster 即可,这个在 FAQ 有提到的。 不过 JS 的话,打包加密其实收益比感觉不是很大,都是裸奔的。

@HobaiRiku 这个最强只是对比其他,它的应用场景更广,功能更全 ,考虑的更周到

@jiangzhuo 长连接这种还是越少越好

最像 Spring === 更好 本身就是个伪命题,应用层框架要贴合业务场景和团队来进行选型,如果说团队很多从 java 转过来的,那么越像 Spring 大家上手越容易这是好事; 反之就要看需求了,比如题主这种对单独 agent worker 需求的,我在之前的公司也有类似的场景——需要一个应用启动单独的长连接服务区获取服务信息,那么用 egg 就很完美地贴合了这样的开发场景。

@phper-chen 可能应用场景不同,我是开发游戏服务器的,客户端和服务器之间链接一直保持着几百条长连接,所以觉得多几条服务器和服务器之间的链接也没什么。

@jiangzhuo 游戏才几百条。。。。

@phper-chen 几百条不少了,独立游戏又不能跟那些有市场有推广的比。

回到顶部