amazon-web-services - 以下云 (AWS) 架构的缺点
问题描述
我需要一个可扩展且具有成本效益的网页设计服务架构。（多个客户）。我正在遵循下面的架构。我想知道它的缺点。
背景：基于 Nuxt.js 的服务器渲染应用程序，前面是 nginx 反向代理。
应用程序容器和代理容器部署到 AWS ECS 实例上。代理容器通过从动态容器端口映射到静态 ELB 端口的侦听器注册到 ALB（应用程序负载均衡器）。
所以，假设我们有两个客户： www.client-1.com和www-client-2.com
当向 发出请求时www.client-1.com，请求被 301 重定向（带有屏蔽）到 ALB 的 PORT 80。当请求命中ALB:80时，它通过配置的 映射到instance_ip:3322（其中 3322 是动态容器端口）listener-for-client-1。并将响应发送回客户端。
当向 发出请求时www.client-2.com，请求被 301 重定向（带屏蔽）到 ALB 的 PORT 81。当请求命中ALB:81时，它通过配置的 映射到instance_ip:3855（其中 3855 是动态容器端口）listener-for-client-2。
如您所见，此模型允许我在多个客户端之间共享一个 elb。这个模型已经过测试并为我工作。
- 您认为域转发 301 是一个糟糕的主意吗？您能否推荐一种负担得起的替代方案，而不需要每个客户的 ELB。
- 您还看到哪些其他缺点？
谢谢！
解决方案
域屏蔽总是一个糟糕的主意。问题是不可避免的，特别是当浏览器需要访问非标准端口时。
但这一切都不是必需的。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 条规则。