Our application structure looks like

我们的应用程序结构如下所示

[Nestjs App1]                     
Listens on Http Port 8080
Accepts Http Connection from User 

[Nestjs App2]
Listens on Http Port 8081 as Microservice over Transport.TCP

  const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.TCP,
      options: { host: '127.0.0.1', port: 8081 }
    },
  );
  await app.listen();

App1 receives http requests from user and after authentication check it connects to App2 via nestjs microservice pattern and returns the data computed by App2 to the user.

App1接收来自用户的Http请求，认证检查后，通过nestjs微服务模式连接到App2，并将App2计算的数据返回给用户。

We are able to run both apps into pm2 cluster mode.

我们能够在PM2集群模式下运行这两款应用程序。

However, for App2, Graceful restart is not handled properly by App2 cluster as during App2 restart, requests are continuously sent to every instance of App2 and fails while some instance of App2 are being bootstrapped.

然而，对于App2，App2集群没有正确地处理平稳重启，因为在App2重启期间，请求被连续发送到App2的每个实例，并且在引导App2的某些实例时失败。

We suspect, it is due to the working of App2 as microservice which communicates to App1 through node's net socket transport events and pm2 cluster (node cluster) is not able to determine the nature of communication and keeps sending all requests to every instance of App2 even after sending SIGINT while restarting?

我们怀疑，这是由于App2作为微服务通过节点的Net Socket传输事件与App1通信，而PM2集群(节点集群)无法确定通信的性质，即使在重启时发送SIGINT后仍向App2的每个实例发送所有请求？

Anyone having better understanding of node cluster's requests management and nestjs microservice please help us how to handle graceful restart for nest default(TCP) microservices.

任何对节点集群的请求管理和Nestjs微服务有更好了解的人，请帮助我们处理Nest Default(Tcp)微服务的平稳重启。

We want that during pm2 reload App2, new requests should be sent only to other App2 cluster instances which are currently running.

我们希望在PM2重新加载App2期间，新请求应该只发送到当前正在运行的其他App2集群实例。

After through debugging, it is found that default nestjs microservice TCP client does not work properly in cluster mode of pm2 as it communicates with each other using socket events. Graceful restart can't be achieved using default TCP client strategy of nestjs microservice as during graceful restart of microservice, i.e. after SIGINT process event, its socket server keeps accepting new requests and thus graceful restart/stop fails altogether.

通过调试发现，默认的nestjs微服务TCP客户端在PM2的集群模式下无法正常工作，因为它使用套接字事件进行通信。在微服务平滑重启过程中，Nestjs微服务默认的TCP客户端策略无法实现平滑重启，即在SIGINT处理事件后，其Socket服务器继续接受新的请求，从而平滑重启/停止完全失败。

We resolved it after implementing our own CustomTransportStrategy server and custom ClientProxy on the top of HTTP protocol with node's http package.
In addition, we keep counter record of all requests in process using global interceptor.

我们在使用节点的http包在HTTP协议之上实现了我们自己的CustomTransportStrategy服务器和定制的ClientProxy后，解决了这个问题。此外，我们使用全局拦截器保存正在处理的所有请求的计数器记录。

Using, OnApplicationShutdown lifecycle event of nestjs, we return a promise and resolve it after all pending requests are processed by our microservice.
As a fallback, We also set "kill_timeout" of pm2 cluster to a higher value in such a way that it forcefully kills and restart our microservice when something goes wrong.

使用nestjs的OnApplicationShutdown生命周期事件，我们返回一个Promise，并在我们的微服务处理完所有挂起的请求后解决它。作为后备，我们还将PM2集群的“KILL_TIMEOUT”设置为更高的值，以便在出现问题时强制终止并重新启动我们的微服务。

Now graceful restart is working fine in the pm2 cluster mode using our custom transport strategy over HTTP.

现在，使用我们的基于HTTP的定制传输策略，完美重启在PM2集群模式下工作得很好。