[eggjs/egg]您好，当我在使用egg的多进程模型的时候，目前有这样一个需求：

1.HTTP 需要请求(request)和响应(response)，你所说的耗时操作在单线程会导致超时，没有问题。问题是:即使在多线程情况下，HTTP请求的特性没变，还是需要response，那么就是说耗时操作还是会导致超时，这个跟线程无关。如果说在进行request的时候开启异步操作，response立即返回，任务还在进行执行，这种场景跟一次HTTP请求的关系不大

2.获取PID

agent.messenger.opids

上面的可以获取PID

worker 之间是对等的，耗时操作最好丢给 fc 去做

你好，你使用 cluster 之后，具体请求的处理已经由 worker 完成了... 为何还要从一个 worker 转发到等价的另一个 worker

您好，我先再描述下我的应用场景。我的需求是，在一次请求中，有一步是耗时很大密集计算任务，做完这一步才可响应（可能需要2S）。为了使不所有worker可能会被同时阻塞，我向通过设置，来将所有任务交给其中一个进程来做，这样其他进程不至于被堵塞。 但查过源码后，我发现，指定worker似乎并不是一个好的方法（很难做，也不稳定）。 于是我是用了egg提供的ClusterClient，自己再开几个进程（非使用Cluster），实现了我自己的多进程管理。由这些进程来完成密集计算任务，解决了这个问题。

关于提到的离线计算，由于该计算是在一个请求中的，且是实时的，所以没有办法使用离线计算

应该不是每一个请求都需要2S秒吧。如果不是的话，用Nginx或者别的，负载均衡一下就可以了。你说的这个方案提高了复杂性，而且还不稳定。

这样的设计的目的主要是为了，如果存在密集型计算任务的话，可以有一个独立的服务器可以去执行，而不用影响实际的请求处理服务器。不过个人觉得用nginx不是很方便。 其实就是相当于一个fc了，我只是简单的自己实现下类似于cluster的管理（使用cluster开启的子进程没办法使用cluster开子进程），当然也可以使用其他的已经成熟的fc服务，只需要在ClusterClient中实现相应的通信服务就好。这样就相对解决了复杂性，提高了稳定性

可能我没有表达清楚。 普通任务和计算型任务存在以下三个方面：

代码上，可以把普通任务和计算型任务分为两个工程，这样在部署的时候，就是分开部署的，所以也就不存在你说的这个场景，但是这样要维护两套代码，不大方便，当然这样取决于这两个任务之间重要程度有多高，决定是否要分开两个工程

同一套代码的情况下，部署上用Nginx只是个类比的方案，毕竟现在Docker和Kubernetes也能做到把这两种类型的任务分开，以及还有其他的方案

消息方案：采用事件触发的方式，就跟fc一样了。

❤️ 总得来说，我觉得代码和部署两个方面来说，部署更偏重一点。

我比较倾向分开部署，相当于是两个独立的服务，尽量将计算服务这一部分抽象出来。 至于您说的部署，我目前接触的还比较少（目前大二），所以现在可能还不能很好理解。 我更倾向于消息方案，这样更独立一点 部署使用同一套代码，在维护这点，我觉得各有看法。一方面，同一套代码维护可能轻松一点。 当时我觉得分开部署，更有利于模块解耦，可以独立出fc，维护也会相对容易一点 感谢您的回答~~

这块我们推荐用 FC。

至于你提到的维护上的问题，是可以通过工程来解决的，譬如在 CI CD 部署时自动把一部分代码发布到 FC。