AWS弹性架构下Amazon SQS与ELB搭配部署及最佳实践咨询

ELB是否会对调用请求进行排队？ #

ELB的核心定位是七层/四层请求负载转发，本身不支持持久化的请求排队能力。当后端目标组无可用健康实例、或所有实例的连接数/负载达到上限时，超出ELB处理阈值的请求会直接返回503或504错误，不会暂存等待后端服务空闲。

是否需要在后端服务前部署SQS？ #

是否部署需结合业务特性判断：

• 若你的查询请求为同步实时场景（要求页面实时返回查询结果，无等待机制），不适合部署SQS。SQS的异步消费模式会拉长响应链路，无法满足实时性要求。
• 若你的请求为异步可延迟场景（如批量查询、任务提交，支持前端先返回任务ID用户后续查结果），非常推荐部署SQS。它可以缓冲流量洪峰，避免后端服务过载时请求直接丢失，也能减少ELB返回错误的概率。

SQS是否不适用于Auto Scaling解决方案？ #

SQS和Auto Scaling是高度适配的组合，不存在适配问题。AWS Auto Scaling原生支持以SQS队列深度作为扩缩容触发指标，你可以配置规则：当队列内待处理消息数超过阈值时自动扩容后端服务实例，队列深度回落后自动缩容，这种基于业务负载的扩缩容策略，比传统基于CPU、内存的指标更精准，资源利用率更高。

此类业务场景对应的最佳实践 #

同步实时查询场景 #

• 保留现有两层ELB+Auto Scaling的架构即可
• 为两个Auto Scaling组配置多维度扩缩容策略，除CPU、内存外，可加入ELB请求延迟、目标组请求数等业务相关指标，同时预留足够的冷却时间和扩容缓冲，避免流量突增时扩容不及时
• 可在第一层ELB前端增加CloudFront缓存静态资源，WAF拦截恶意请求，降低后端服务的无效负载
• 配置合理的ELB超时、重试规则，前端同步做降级提示，提升洪峰时期的用户体验

异步处理场景 #

• 在两层组件之间新增SQS队列：第一层组件接收到请求后直接写入SQS，给前端返回任务标识，后端服务自主从SQS拉取消息处理
• 队列类型按需选择：无顺序要求选标准队列（吞吐量无上限），有严格顺序要求选FIFO队列
• 后端Auto Scaling组绑定SQS队列深度指标做扩缩容，同时配套部署死信队列，收纳多次消费失败的异常消息，避免异常消息堆积占用资源

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