.NET 6.0 Kestrel对接单线程原生旧库的REST API方案咨询

方案1：IIS应用程序池进程隔离（适配32位） #

如果旧库仅支持32位，直接利用IIS的应用程序池实现进程级隔离与复用：

• 新建应用程序池，开启启用32位应用程序选项，配置进程回收规则（如请求数、内存阈值）控制进程生命周期
• 将ASP.NET Core应用以InProcess模式部署到该池，IIS会自动管理进程的创建、复用和回收，无需自行编写进程池逻辑
• 该方案依托IIS成熟的进程管理能力，稳定性优于自行实现的进程池，适合作为起步或生产环境方案

方案2：基于命名管道的轻量自定义进程池 #

放弃内存映射文件，改用命名管道传递任务与结果，实现更易维护的进程复用：

• 提前启动固定数量的32位工作进程，每个进程监听专属命名管道
• API主进程收到请求后，将任务序列化（如JSON）发送给空闲工作进程
• 工作进程调用旧库处理后，将结果序列化回传主进程
• 核心代码示例：

  // 工作进程入口
  static void Main() {
      var pipeName = $"WorkerPipe_{Process.GetCurrentProcess().Id}";
      using var pipe = new NamedPipeServerStream(pipeName, PipeDirection.InOut);
      pipe.WaitForConnection();
      using var reader = new StreamReader(pipe);
      using var writer = new StreamWriter(pipe) { AutoFlush = true };
  
      while (true) {
          var taskJson = reader.ReadLine();
          var task = JsonSerializer.Deserialize<ApiTask>(taskJson);
          // 调用单线程旧库处理逻辑
          var result = LegacyLibrary.ProcessTask(task.Data);
          writer.WriteLine(JsonSerializer.Serialize(result));
      }
  }
  
  // 主进程任务分配逻辑
  public async Task<IActionResult> HandleRequest([FromBody] RequestPayload payload) {
      var idleWorker = _workerPool.GetIdleWorker();
      await idleWriter.WriteLineAsync(JsonSerializer.Serialize(new ApiTask { Data = payload }));
      var resultJson = await idleReader.ReadLineAsync();
      var result = JsonSerializer.Deserialize<ResponseResult>(resultJson);
      return Ok(result);
  }
  

• 可额外实现进程崩溃自动重启、负载均衡逻辑，比内存映射文件更易调试和维护

方案3：借助第三方进程池库简化开发 #

直接使用成熟的.NET进程池NuGet包（如ProcessPool），省去自行实现进程管理的成本：

• 配置进程池大小、32位工作进程的启动路径
• 库自动处理进程的创建、复用、异常回收与负载均衡
• 只需定义任务和结果的序列化规则，即可快速对接旧库

为什么不推荐Kestrel单请求单进程？ #

Kestrel原生为单进程多线程模型，无“每个请求分配独立进程”的配置项。强行启动新进程处理每个请求会导致：

• 进程启动开销极大，并发场景下性能急剧下降
• 完全无法实现进程复用，违背核心需求

内容的提问来源于stack exchange，提问作者Robi Ogi