1

目前，我还没有设置 AWS 负载均衡器。

请求来自单个 ec2 实例：首先命中 nginx，然后将其转发到 node/express。

现在，我想创建一个自动缩放组，并附加 AWS 负载均衡器以分发进来的请求。我想知道这是否是一个好的设置：

Request -> AWS Load Balancer -> Nginx A + EC2 A
                             -> Nginx B + EC2 B
                             -> ... C   + ... C

Nginx 安装在运行 node.js 的同一 EC2 上。Nginx 配置具有使用 geoip 模块检测用户位置的逻辑，以及 gzip 压缩配置和 ssl 处理。

我还将 ssl 处理移至负载平衡器。

4

1 回答 1

1

理想情况下（如果 Nginx 可以与特定的 Node 任务分离），您需要一个专用于每个服务的自动扩展组，我建议为此使用容器化，因为这正是它的含义，尽管所有这些显然都需要一些非- 对您的程序进行细微的更改...

在此处输入图像描述

这将使...


高效的资源分配

  • 选择具有每个服务（节点或 Nginx）的 CPU/RAM/网络/存储的理想组合的实例类型
  • 保持对相对于实际需求运行的任务数量的精细控制。


智能缩放

设置为初始化扩展操作的阈值需要反映它们正在运行的资源。当您的程序的简单读取操作出现峰值时，您可能不想说将计算密集型节点容量加倍。通过按资源对服务进行细分，阈值可以与您的服务最需要的资源相关联。您可能想要扩展...

  • Nginx 基于 1 分钟内的最大入站请求
  • 节点基于 5 分钟内的平均 CPU 利用率

你的实例相对于你的任务的大小被分成的“块”也对它们的扩展效率有很大的影响。这是一个夸张的示例，仅针对一项服务...

  1. 1 个 EC2 t3.large 运行 5 个节点任务 @ 50% RAM 利用率。
  2. AS 组达到 70% 或您分配的任何阈值，横向扩展 1 个实例
  3. 2 个实例现在运行 6 个节点任务 @ 30% RAM 利用率

这会导致2个问题...

  • 你现在浪费了很多钱
  • 可能更重要的是......你的缩小门槛是多少？20% 利用率？

上下缩放界限的差距越小，您的效率就越高。当您正在运行的任务都是同质的时，您可以添加和删除更小、更精确的资源“块”。

在上面的场景中，您理想情况下想要类似...

  1. 3 个 t3.small 实例运行 5 个节点任务
  2. AS 组的利用率达到 70%，横向扩展 1 个实例
  3. 现在您有 4 个实例上的 6 个任务，利用率为 50%
  4. 利用率下降到 40% 缩减 1 个实例。

显然你仍然可以在相同的底层资源上运行所有这些运行 Node 和 Nginx，但是这一切的数学变得非常疯狂并且让你的系统变得脆弱。

（我已将上述内容简化为针对 AS 组的内存利用率，但在应用程序中，您将让 ECS 添加基于 Utillzation 的任务，然后将其添加到集群的内存预留中，然后启动 AS 操作。）


简化且高效的部署

  • 您不希望每次更新 Nginx 配置时都​​重新部署整个 Node 代码库。
  • 简化蓝/绿部署测试和回滚。
  • 最大限度地减少您必须为部署的“蓝色”部分启动的资源。
  • 如果仅依赖于它们的服务需要，请使用带有预安装二进制文件的自定义 AMI

无论您是否想立即执行此操作（并且您会这样做），此配置都将允许您迁移到Spot 实例以处理更多可变工作负载。像所有这些一样，您仍然可以使用您已经布置的配置的 Spot 实例，但是有效且不中断地处理终止程序是另一回事，当您完成时，您希望其余部分非常有条理且工作顺利.

ECS

NLB

我不知道您使用什么进行部署，但AWS CodeDeploy将与ECS完美配合以管理您的容器集群。

于 2019-01-26T07:10:27.580 回答