【问题标题】:Best Approach for Auto-Scaling (Avoiding Down Time)自动缩放的最佳方法(避免停机时间)
【发布时间】:2019-05-24 18:17:51
【问题描述】:

我们将 AWS 用于我们的 Web 应用程序,我们的目标是为数百万用户扩展它。现在,我们正在使用 AWS Beanstalk “Auto Scaling”,我在其中定义了要扩展的最小、最大实例。

问题: 1-我们需要为超过 100 万用户扩展它 2- 我们的 AutoScaling 正在工作,但是当我们启动新实例时(安装应用程序需要更多时间)并且意味着同时用户请求也开始到达那里(获取空响应,因为应用程序正在安装)。

我想用最少的时间使用最好的架构(构建一个我们可以随着时间改进的坚实基础)架构。

P.S:我们使用的是微服务架构 + API GATEWAY。

提前致谢。

【问题讨论】:

    标签: amazon-web-services load-balancing amazon-elb autoscaling amazon-elastic-beanstalk


    【解决方案1】:

    100 万以上用户的定义很模糊。这是否意味着一百万同时用户需要复杂的数据库访问或仅仅一百万用户访问 S3 存储上的文件?定义性能要求是设计可靠、安全和容错系统的第一步。

    良好自动缩放的关键有几个因素:

    1. 健康检查。您的健康检查将确定负载均衡器何时开始向您的后端实例发送请求。您的运行状况检查需要准确地确定实例何时可供服务以及在检查新实例的运行状况之前等待多长时间(实例启动时间)。
    2. 实例启动和配置。您需要您的实例尽快上线。这通常意味着创建一个无需下载和安装更新、软件包或应用程序的预配置 AMI。
    3. 管理。流量的突然大幅增加通常是可以预见的。通常可以安排产品公告、营销视频等,并且可以提前对您的平台进行预热,然后在活动结束后关闭。

    对自动扩缩的一个常见误解是可以立即进行扩缩。不是这种情况。要处理大量增加的流量,您要么需要预热环境,要么拥有额外的冗余容量来处理即时峰值。

    自动扩缩功能适用于随时间增加和减少的流量,而不是一次全部。除无服务器平台外,没有 instant on 用于计算服务。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-08-23
      • 1970-01-01
      • 2016-03-28
      • 2018-02-11
      • 1970-01-01
      • 1970-01-01
      • 2011-01-12
      相关资源
      最近更新 更多