无服务器架构的广泛应用推动了云计算的发展，而在实现高可用性、自动扩展和灵活分发的过程中，负载均衡器成为关键组件。AWS Elastic Load Balancer（ELB）为无服务器架构提供了一种可靠的解决方案，它能够在分布式环境中智能地管理流量分发，从而确保应用的性能和稳定性。通过与 AWS Lambda、API Gateway 等无服务器服务无缝集成，ELB 为开发者提供了高效且可扩展的负载管理方式。
什么是弹性负载均衡器 (ELB)？
ELB 是 AWS 提供的一组负载均衡（LB）服务。它们包括Classic Load Balancer、Gateway Load Balancer、Network Load Balancer和Application Load Balancer。
每个 LB 都涵盖不同的用例
- Classic Load Balancer是基于 EC2 的架构的不错选择
- 网关负载均衡器可帮助 VPC 中的第三方虚拟机
- 网络负载均衡器专注于高性能低级网络，例如基于 UPD 的游戏或物联网连接
- 应用程序负载均衡器是使用 HTTP 协议的软件的高级解决方案
在无服务器架构的情况下，所有服务都使用HTTP API，这意味着ALB是最佳选择。因此，本文将重点介绍ALB。
什么是应用程序负载均衡器 (ALB)？
ALB 专注于 HTTP，因此它可以使用协议的某些部分来做出有关缓存的决策，从而为您节省一些 Lambda 执行时间。这意味着您的 Lambda 函数必须正确设置其缓存标头。
价格
虽然 ALB 可以与 Lambda 集成，但 ALB 不是无服务器服务；它没有即用即付模式，这意味着您需要为未使用的时间付费。但是，如果您的服务具有持续稳定的流量需求，那么从长远来看，它可能比 API Gateway 更便宜。
限制
此外，API Gateway 限制连接数为 10k，而 ALB 没有限制。它是一个 API Gateway，具有更多次要功能；功能简单，但性能卓越。如果您要做大，ALB 可能是您的唯一解决方案。
权限
ALB 更像是传统的“绑在公共 HTTP 端点前面”的东西。因此，虽然它与 Lambda 集成，但它不提供基于 IAM 的权限。您必须在无服务器函数中处理这个问题。
变换
这种传统的负载平衡方法还意味着 ALB 无法进行请求和响应转换；它只是将您的数据传输到管道。同样，这使得 ALB 的灵活性不如 API 网关，并将更多工作转移到 Lambda。
多区域
您一次将 ALB 部署到一个区域。同样，这不是无服务器服务，因此您需要做更多工作。要使流量在多个区域之间保持平衡，您需要 Route53 的基于 DNS 的平衡。
可靠性或成本配置
使用带有 Lambda 目标的 ALB 通常可以提供良好的可靠性，因为 Lambda 会自动扩展。如果您需要的不仅仅是开箱即用的可靠性，则必须将 ALB 部署到多个区域并将其置于 Route53 之后。
在成本方面，Lambda 可能成为您的主要罪魁祸首。如果您将每个请求路由到具有大内存配置的 Lambda 函数，那么成本很快就会变得昂贵。因此，请遵循无服务器最佳实践，使 Lambda 函数保持小巧和目的驱动。为您的 ALB 侦听器设置条件，以便尽可能使用内存占用较小的函数。
健康检查最佳实践
尽管 EC2 目标很容易不堪重负，但 Lambda 目标由于其固有的自动扩展功能而具有更多的缓冲；无服务器系统中仍然存在可能出错的情况。
AWS 默认禁用 Lambda 目标的 ALB 运行状况检查，因此您必须在此处选择加入。
虽然有些问题可能是由推送到 Lambda 的错误代码引起的，但大多数问题都来自函数使用的上游服务。因此，请设置 Lambda 以管道方式传输健康检查，然后使用上游服务的结果进行响应。
如果出现问题，唯一快速的解决方案是告诉 Route53 将以下请求路由到不同的部署。
AWS 中的日志分析
AWS 允许您使用 Amazon Athena 分析 ALB 日志。Athena 是一种无服务器查询服务。您需要激活查询日志并将其保存到 S3，然后使用 Athenas SQL 查询进行探索。
AWS Elastic Load Balancer 在无服务器架构中扮演了至关重要的角色，通过其自动化的流量管理、灵活的扩展能力以及与其他 AWS 服务的深度集成，帮助开发者轻松应对各种业务需求。无论是处理高并发请求还是优化资源利用率，ELB 都能为无服务器架构提供可靠的支撑，让开发者专注于核心逻辑的实现和创新。
