我们公司目前运营着一个单体应用程序，它由在两台服务器上运行的多个 Tomcat 实例组成。这些实例使用 Apache 进行负载平衡，其中每个实例侦听不同的端口，然后重定向到其各自的端点（例如 /payments、/orders 等）。
我们正在将基础设施迁移到 AWS，并考虑用应用程序负载均衡器 (ALB) 替换 Apache。我们想征求您的意见，看看这是否是一种可行的方法。
此外，我们正在考虑为每个 Tomcat 端点创建单独的 EC2 实例。例如，拥有两台服务器，其中多个实例专用于 /payments，两台服务器专用于 /orders，等等。您对这种方法有什么看法？
此外，我们想知道 ALB 是否支持将多个端口重定向到单个目标。例如，我们希望将端口 8090、8091、8092 和 8093 重定向到 /payments 端点。
谢谢！
答案1
对于此用例，使用 ALB/应用程序负载均衡器似乎很合适。它适用于 AWS 中的大多数 http(s) 负载平衡用例，但有些极端情况它无法做到。
ALB 在传入连接/端口和目标组的监听器方面具有相当灵活的架构。您应该能够做您需要做的事情。但是，一旦您进入 AWS 并了解了设置方式，我不确定您是否需要这样做，但这取决于您的解决方案的架构方式。
我认为每个 Tomcat 实例拥有一台服务器是合理的。每个可用区都放置一台以实现冗余。请注意，如果启用跨区域负载平衡（如果在控制台中创建，则默认为开启），AZ-A 中的负载平衡器可以将流量发送到 AZ-B 中的容器，从而产生 AZ 间流量费用。AWS 表示，它会尽可能将流量保持在可用区内。密切关注您的账单，必要时关闭该功能。您应该考虑自动扩展和健康检查。
您应该考虑使用容器而不是实例，您可以在您管理的 EC2 实例或 Fargate 容器上运行容器。Fargate 容器的成本稍高一些，但 AWS 可以管理它们，因此可以为您节省一些精力。对于大多数用例来说，AWS Elastic Container Service (ECS) 已经足够了，您不需要 EKS/K8S 以及它为大多数用例带来的所有复杂性。
您也可以简单地将服务器迁移到 AWS。这通常可行，但在许多情况下，这是重新构建解决方案以更符合云原生方式的第一步。
如果您不理解我回答中的某些术语，欢迎提问，但我也建议您接受一些培训。AWS 是一个复杂的企业环境，很容易出错、产生巨额账单或错过造成安全问题的事情。培训AWS 助理架构师证书就很合适。周围有很多培训提供商，我喜欢 Adrian Cantrill 培训，尤其是针对初学者的培训，但也有 Cloud Guru 和许多其他培训。