C# 扼流圈模式Strangler Fig方法 C#如何逐步迁移遗留系统

strangler fig模式是一种架构迁移策略，指在c#项目中用asp.net core新模块逐步替代asp.net framework旧系统，通过反向代理路由共存于同一域名，解耦身份认证、数据访问与配置管理，避免一步重写风险。

什么是Strangler Fig模式在C#中的实际含义

Strangler Fig不是C#语言特性，也不是.NET库里的某个类或接口，它是一种架构迁移策略——用新模块逐步“绞杀”旧系统。在C#项目中，它表现为：新功能用ASP.NET Core写，老功能仍跑在ASP.NET Framework（甚至Web Forms）上，两者共存于同一域名，靠反向代理或网关分流。

关键判断点：如果你的遗留系统是单体、紧耦合、测试覆盖率低、不敢动核心流程，又必须上线新需求，Strangler Fig就是当前最可行的路径；想一步重写，基本等于重蹈覆辙。

如何让ASP.NET Core和旧.NET Framework共存于同一入口

核心在于请求路由不交给任一后端全权处理，而是前置一层决策逻辑。常见做法是用nginx或iis URL重写规则做路径分流：

• /api/v2/、/admin/ → 转发到新的ASP.NET Core站点（比如https://new-api.example.com）
• /legacy/*、/webforms/ → 保持指向旧IIS应用池
• 静态资源（.js、.css）统一由CDN或Nginx缓存，避免跨域和版本混乱

注意：不要用Response.Redirect硬跳转，那会暴露内部路径、破坏单页体验；必须用反向代理（proxy_pass 或 IIS ARR）维持Host头和cookie域一致。

C#代码层如何解耦新旧系统间的数据与身份依赖

旧系统常把用户信息塞进session、HttpContext.Current.Items，而ASP.NET Core默认不共享这些。直接复用会出错：

常见错误现象：NullReferenceException 在尝试读取HttpContext.Session，或User.Identity.Name为空

• 身份认证统一走JWT或Cookie共享方案：旧系统生成FormsAuthentication.SetAuthCookie后，新系统用CookieAuthenticationDefaults.AuthenticationScheme验证同一.ASPXAUTH Cookie（需配置Cookie.SameSite = SameSiteMode.None且HTTPS）
• 数据库层面不急于拆分：初期共用同一sql Server库，但新模块只读写自己新建的表，旧模块继续用原表；用视图或存储过程封装过渡逻辑
• 避免在新代码里调用System.Web命名空间下的任何类型（如HttpServerUtility），它们在.NET Core中不存在

迁移过程中最容易被忽略的三个技术断点

很多团队卡在这几步，不是技术不行，而是没提前压测或约定边界：

• HttpContext.Current 在.NET Core中彻底移除，所有依赖它的日志、权限、上下文追踪代码必须重写为IHttpContextaccessor + AsyncLocal<t></t> 模式
• 旧系统用Web.config的<appsettings></appsettings>，新系统默认读appsettings.json —— 不要硬编码路径，用IConfiguration抽象统一加载，必要时加自定义Provider从Web.config读取
• 前端ajax请求若带withCredentials: true，而新旧API部署在不同子域（如old.example.com / new.example.com），必须显式设置Access-Control-Allow-Origin为具体域名，不能用*

真正的难点不在写新代码，而在定义清楚「哪天之后，这个URL路径不再转发给旧系统」——这需要业务方签字确认，而不是开发拍板。