Azure上从.NET 4.8单体应用迁移微服务能否保留原API URL？

完全可以实现保留原API调用地址，将请求透明转发到微服务处理，以下是几种实用落地方案：

方案1：利用IIS URL重写规则（适配.NET 4.8 App Service） #

Azure App Service基于IIS运行，可直接修改web.config添加URL重写规则，无需改动原应用代码即可完成转发。

在web.config的<system.webServer>节点下添加如下配置：

<rewrite>
  <rules>
    <!-- 单个API端点转发 -->
    <rule name="Forward Some Endpoint to Microservice" stopProcessing="true">
      <match url="^api/some-endpoint(.*)$" />
      <action type="Rewrite" url="https://my-microservice.net/api/some-endpoint{R:1}" />
      <!-- 传递原请求Host头（可选，部分微服务需依赖此信息） -->
      <serverVariables>
        <set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />
      </serverVariables>
    </rule>

    <!-- 批量转发多个API端点（按需配置） -->
    <rule name="Forward Multiple Endpoints" stopProcessing="true">
      <match url="^api/(some-endpoint|another-endpoint)(.*)$" />
      <action type="Rewrite" url="https://my-microservice.net/api/{R:1}{R:2}" />
    </rule>
  </rules>
</rewrite>

• 效果：客户端请求原地址some-url.azurewebsites.com/api/some-endpoint时，请求会被透明转发到微服务地址，客户端无感知。
• 注意：若微服务部署在Azure内部VNet中，需确保原App Service已启用VNet集成，具备访问微服务的网络权限。

方案2：使用Azure API Management（APIM）/Front Door（适合大规模拆分） #

如果是长期的微服务演进计划，推荐用APIM或Front Door作为统一流量入口：

1. 将原App Service和目标微服务都配置为APIM/Front Door的后端服务。
2. 把原地址some-url.azurewebsites.com绑定为APIM/Front Door的自定义域名。
3. 配置路由规则：将/api/some-endpoint路径的请求路由到微服务后端，其余路径仍指向原单体App Service。

这种方案的优势：

• 无需修改原App Service的任何代码或配置。
• 可统一管理认证、限流、监控、缓存等能力，适配多微服务的长期演进需求。

方案3：在原App Service中添加反向代理逻辑（适合逐步迁移） #

如果需要对转发逻辑做精细化控制（比如修改请求/响应内容、添加降级逻辑），可以在原API的Action中直接调用微服务并返回响应：

using System.Net.Http;
using System.Text;
using System.Threading.Tasks;
using System.Web.Http;

public class SomeController : ApiController
{
    private static readonly HttpClient _httpClient = new HttpClient();

    [HttpPost]
    public async Task<HttpResponseMessage> SomeEndpoint()
    {
        // 读取原请求内容与类型
        var requestContent = await Request.Content.ReadAsStringAsync();
        var contentType = Request.Content.Headers.ContentType?.MediaType;

        // 传递认证头（若原请求带认证信息）
        if (Request.Headers.Authorization != null)
        {
            _httpClient.DefaultRequestHeaders.Authorization = Request.Headers.Authorization;
        }

        try
        {
            // 调用微服务并返回响应
            var microserviceResponse = await _httpClient.PostAsync(
                "https://my-microservice.net/api/some-endpoint",
                new StringContent(requestContent, Encoding.UTF8, contentType)
            );
            return microserviceResponse;
        }
        catch (HttpRequestException)
        {
            // 微服务不可用时的降级逻辑（可选，比如返回原单体应用的响应）
            return Request.CreateErrorResponse(System.Net.HttpStatusCode.ServiceUnavailable, "服务暂不可用");
        }
    }
}

通用注意事项 #

• 认证传递：确保原请求的Authorization等关键头能正确转发到微服务，避免权限校验失败。
• 日志与监控：在原App Service和微服务中分别添加请求日志，或用Azure Monitor追踪链路，方便排查问题。
• 跨域兼容：原地址不变的情况下，浏览器端的跨域策略与之前一致，无需额外调整。

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