我需要一个可扩展的，具有成本效益的体系结构来进行网页设计服务。 （多个客户）。我正在遵循以下架构。我想知道它的缺点。
背景：基于Nuxt.js的服务器呈现的应用程序，位于nginx反向代理的前面。
应用程序容器和代理容器已部署到AWS ECS实例上。代理容器通过侦听器注册到ALB（应用程序负载平衡器），侦听器从动态容器端口映射到静态ELB端口。
因此，假设我们有两个客户：www.client-1.com和www-client-2.com
向www.client-1.com发出请求时，该请求会被重定向到ALB的端口80 301（带掩码）。当请求到达ALB:80时，它通过配置的instance_ip:3322映射到listener-for-client-1（其中3322是动态容器端口）。并将响应发送回客户端。
向www.client-2.com发出请求时，该请求将301重定向（带有屏蔽）到ALB的端口81。当请求到达ALB:81时，它通过配置的instance_ip:3855映射到listener-for-client-2（其中3855是动态容器端口）。
如您所见，此模型使我可以在多个客户端之间共享elb。该模型已经过测试，可以为我工作。
谢谢！
答案 0 :(得分：0)
域掩码始终是一个可怕的想法。问题是不可避免的，尤其是当浏览器需要访问非标准端口时。
但这都不是必需的。 ALB在单个平衡器上支持多个应用程序（客户）。
您现在可以创建Application Load Balancer规则，这些规则根据Host标头中指定的域名路由传入的流量。可以将对api.example.com的请求发送到一个目标组，将对mobile.example.com的请求发送到另一个目标组，而所有其他请求（通过默认规则）都可以发送到第三个目标组。
https://aws.amazon.com/blogs/aws/new-host-based-routing-support-for-aws-application-load-balancers/
尽管本示例使用http://example.com的子域，但ALB没有要求将域关联的限制。您可以将26个不同的SSL证书附加到单个ALB，并按主机名从标准端口80和443路由到每个请求Host标头的唯一后端目标-每个平衡器最多100条规则。