迁移至.NET Core后IIS托管Kestrel服务进程隔离与GUID重复问题求助

一、实现同一应用池内的进程隔离 #

1. 启用Web Garden配置 #

同一应用池内可通过Web Garden让应用运行在多个独立工作进程中，每个进程拥有完全隔离的内存空间：

• 打开IIS管理器，找到目标应用池，右键选择高级设置
• 在进程模型下，将最大工作进程数设为大于1的数值（建议根据服务器核心数调整，比如2-4）
• 可选：配置定期回收规则，避免进程长时间运行导致的内存泄漏或状态异常
• 注意：启用Web Garden后，应用不能依赖进程内会话状态，需改用分布式会话（如Redis、SQL Server），否则会出现会话丢失问题

2. 为进程分配唯一标识 #

通过环境变量为每个工作进程分配唯一ID，确保应用能识别当前运行的实例：

• 在应用池高级设置的环境变量中，添加键值对INSTANCE_ID=%INSTANCE_ID%（IIS会自动为每个工作进程生成唯一ID）
• 应用启动时读取该环境变量，用于实例专属的配置或状态隔离

3. 独立进程托管（替代方案） #

如果不需要IIS的反向代理能力，可直接将.NET Core应用作为独立进程运行，实现完全隔离：

• 将应用发布为自包含部署包：dotnet publish -c Release -r win-x64 --self-contained true
• 为每个实例创建独立的配置文件，绑定不同端口（如5000、5001）
• 用Windows服务托管每个实例，确保开机自启
• 在IIS中配置反向代理规则，将请求转发到不同端口实现负载均衡

二、排查GUID主键重复问题 #

虽然你怀疑进程隔离问题，但off-ramp服务无此异常，大概率是GUID生成逻辑或并发处理问题：

• 检查GUID生成代码：确保所有主键GUID使用标准的Guid.NewGuid()生成，该方法基于RFC4122标准，在多进程、高并发场景下不会产生重复值。避免使用自定义的GUID生成逻辑（如基于时间戳+进程ID，易因时间精度或进程ID重复导致冲突）
• 验证数据库约束：确认目标表的主键约束为UNIQUE或PRIMARY KEY，且未被意外修改
• 排查并发插入逻辑：如果on-ramp服务采用批量插入或异步并发写入，需确保每个请求生成的GUID唯一，可在日志中记录插入前生成的GUID，出现重复时回溯请求来源

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