以下云 (AWS) 架构的缺点

Downsides of the following cloud (AWS) architecture

我需要一个可扩展且具有成本效益的网页设计服务架构。 (多个客户端)。我正在遵循下面的架构。我想知道它的缺点。

背景:Nuxt.js 基于服务器呈现的应用程序,前面是 nginx 反向代理。

app 容器proxy 容器 部署到 AWS ECS 实例上。代理容器通过从动态容器端口映射到静态 ELB 端口的侦听器注册到 ALB(应用程序负载均衡器)。

所以,假设我们有两个客户:www.client-1.comwww-client-2.com

当向 www.client-1.com 发出请求时,该请求被 301 重定向(带掩码)到 ALB 的端口 80。当请求命中 ALB:80 时,它通过配置的 listener-for-client-1 映射到 instance_ip:3322(其中 3322 是动态容器端口)。并将响应发送回客户端。

当向 www.client-2.com 发出请求时,该请求被 301 重定向(带掩码)到 ALB 的端口 81。当请求命中 ALB:81 时,它通过配置的 listener-for-client-2 映射到 instance_ip:3855(其中 3855 是动态容器端口)。

如您所见,此模型允许我在多个客户端之间共享一个 elb。这个模型已经过测试并且对我有用。

谢谢!

域屏蔽总是一个糟糕的主意。问题是不可避免的,尤其是当浏览器需要访问 non-standard 端口时。

但是none这是必要的。 ALB 在单个平衡器上支持多个应用程序(客户)。

You can now create Application Load Balancer rules that route incoming traffic based on the domain name specified in the Host header. Requests to api.example.com can be sent to one target group, requests to mobile.example.com to another, and all others (by way of a default rule) can be sent to a third.

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 header -- 每个平衡器最多 100 条规则。