Azure Functions是否有等效于LambdaEntryPoint的托管方案？

Azure Functions 有和 AWS LambdaEntryPoint 完全对等的官方实现，完全不用自己写switch手动分发请求，也犯不上给每个接口单独建Function。

直接用进程外（Isolated Worker）模型的Azure Functions，装官方的ASP.NET Core集成包就行：只需要留一个配了通配路由的HTTP触发函数当统一入口，就能把整个ASP.NET Core应用完整跑在Function里，你原来写的控制器、路由规则、中间件、过滤器、依赖注入配置全不用改，和之前在AWS上的开发、部署体验基本没差。

实现逻辑很简单 #

• 给入口HTTP触发器配通配路由{*path}，就能接住所有发到这个Function App的HTTP请求
• 官方集成中间件会自动把所有请求转发给ASP.NET Core原生请求管线处理，根本不需要自己写路由映射逻辑
• 这个方案天然跑在Azure Functions消费计划上，能自动弹性伸缩，空闲的时候不产生计算费用，完全匹配你流量突发、75%时间空闲的成本控制需求，用不着买固定配置的App Service。

你列的两种思路确实都不好用 #

• 给每个API单独建HTTP触发函数：会堆一大堆重复的样板代码，和原来ASP.NET Core的路由体系完全脱节，后续改接口要同步改Function配置，维护起来非常麻烦
• 单函数手动写switch分发：得自己维护一整套路由和方法的映射关系，ASP.NET Core自带的模型绑定、鉴权过滤器、异常处理中间件这些能力全用不上，碰到复杂参数、多版本接口的场景根本维护不动。

几个实操提醒 #

• 别用旧的进程内（In-Process）模型搞这个，进程内模型对ASP.NET Core管线的兼容性很差，官方现在也不往这个模型上加新功能了
• 迁移的时候你原来的Program.cs里的服务注册、中间件配置基本可以直接复制过来，和写普通ASP.NET Core项目没区别
• 如果前面要挂API网关、需要调整路由前缀，直接改Function的路由配置就行，业务代码一行都不用动

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