生产环境下ASP.NET Core URL重写方案选择及中间件性能影响问询

1. 最优重写方案选择 #

通用场景下，URL Rewrite中间件是更优选择，各方案的差异如下：

• 搭配IIS使用的URL Rewrite模块：仅支持Windows + IIS的部署架构，规则需要在IIS侧单独配置，和应用代码分离，跨平台部署或迁移环境时很容易遗漏规则
• Apache mod_rewrite模块：仅适用于Apache作为反向代理的部署场景，规则语法和.NET生态不兼容，配置依赖服务器端操作，应用移植成本高
• NGINX Rewrite：仅适用于NGINX作为反向代理的部署场景，规则独立于应用存放在NGINX配置中，多环境部署时需要同步维护代理配置和应用代码
• URL Rewrite中间件：是ASP.NET Core官方原生提供的组件，和应用深度集成，天然支持跨平台部署（无论上层用IIS/NGINX/Apache做反向代理，还是直接用Kestrel对外提供服务，规则都能生效），规则可以写在应用代码或配置文件中，随应用一起发布，不存在配置遗漏的问题，同时还支持直接导入IIS、Apache的现有重写规则，迁移适配成本极低。

如果你的团队有统一在反向代理层管理所有重写规则的规范，可以根据部署架构选择对应代理的重写模块，否则优先选择URL Rewrite中间件。

2. URL Rewrite中间件的性能影响 #

答案是存在可忽略的极微小性能损耗，绝大多数场景下甚至比反向代理层重写的综合性能更好：

1. 中间件的重写逻辑在应用进程内执行，没有反向代理到应用的额外链路开销，反而比代理层重写的整体链路耗时更短
2. 中间件的规则匹配经过.NET运行时深度优化，常规业务场景下几十条重写规则的匹配耗时仅为微秒级，不会对请求处理的总耗时产生可感知的影响
3. 只有当重写规则量级超过数百条时，才需要通过调整规则排序（把高频触发的规则放在更靠前的位置）优化性能，普通业务场景完全不需要担心性能问题。

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