基于AWS Lambda实现Fargate集群HTTP请求动态路由方案咨询

Elastic Load Balancing 适配性 #

完全可以实现需求，你需要用ELB体系下面向HTTP/HTTPS场景的应用负载均衡器（ALB）：

• ALB自带的静态路由规则（按路径、请求头、Query参数匹配）不支持对接外部Redis做动态查询，没法直接满足你的要求
• 正确的配置方式是把所有入站请求先转发给绑定的Lambda函数，函数里完成Redis查询、路由规则计算后，按照ALB要求的固定格式返回转发指令，ALB拿到指令后会直接把请求转发到对应Fargate所属的目标组
• 这个模式里Lambda只做路由判定，不碰实际业务流量，后续请求都是ALB直接和Fargate通信，额外性能损耗非常低，是两个官方方案里性价比最高的选择，唯一要注意的是Lambda返回给ALB的响应格式必须符合规范，否则会直接触发502错误。

API Gateway 适配性 #

也能实现需求，但场景限制比较多：

• 实现逻辑是给API Gateway配置Lambda自定义集成，所有请求先打到Lambda，Lambda查完Redis确定目标Fargate地址后，自己发请求到对应的Fargate服务，再把Fargate的响应透传回客户端
• 这个模式下全量请求、响应都要过Lambda转发，高并发、大请求体的场景很容易碰Lambda的执行时长、内存、带宽配额上限，而且全量流量走Lambda计算的成本比ALB方案高很多，只适合并发规模不大、路由逻辑特别复杂的场景。

• CloudFront + Lambda@Edge：把Lambda部署在CloudFront边缘节点，在回源请求阶段执行Redis查询和路由判定，直接把请求调度到对应Fargate的接入点，适合全球多地域用户访问的场景，用户侧访问延迟更低，但Lambda@Edge的运行配额比普通Lambda更严格，需要提前适配Redis的跨地域访问能力。
• AWS App Mesh服务网格：给所有Fargate任务注入Envoy边车代理，写一个轻量控制面服务把Redis里存的路由规则同步到边车配置上，请求不用每次过Lambda查Redis，直接在边车层就能完成路由转发，性能损耗极小，适合服务数量多、路由规则更新不需要毫秒级生效的微服务场景。
• 自研网关层：在Fargate集群前面部署一组跑开源网关（APISIX、Nginx、Envoy都可以）的服务，这类网关大多原生支持对接Redis存动态路由规则，完全不需要依赖Lambda做路由计算，转发性能最高，适合QPS规模大、对延迟要求极高的场景，缺点是需要自己维护网关集群的扩缩容、版本升级和配置迭代。

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