高负荷应对方案

前提

假设我们为每个实例分配的CPU/MEMORY/NET是固定的。

三种类型业务的高负荷

  • 第一种
    独立的服务最容易伸缩,它可以进行线性地伸缩。如果用户增长了两倍,我们就运行两倍的服务实例, 就万事大吉了。

  • 第二种
    服务依赖了外部的资源,比如那些使用了数据库的服务。数据库有它自己的容量上限,这个一定要注意。你还要知道,如果系统性能出现衰退,就不应该再增加更多的实例,而且你要知道这种情况会在什么时候发生。

  • 第三种
    服务受到外部系统的牵制。例如,外部的账单系统。 就算运行了 100 个服务实例,它也没办法处理超过 500 个请求。我们要考 虑到这些限制。在确定了服务类型并设置了相应的标记之后,是时候看看 它们是如何通过我们的构建管道的。

应对方案

  • 如果是第一种类型的服务
    我们使用一个实例,并在这个环境里运行它,给它最大的负载。在运行了几轮之后,我们取其中的最小值,将它存入InfluxDB,将它作为该服务的负载上限。

  • 如果是第二种类型的服务
    我们逐渐加大负载,直到出现了性能衰退。我们对这个过程进行评估,如果我们知道该系统的负载,那么就比较当前负载是否已经足够,否则,我们就会设置告警,不会把这个服务发布到生产环境。我们会告诉开发人员: “你们需要分离出一些东西,或者加进去另一个工具,让这个服务可以更好地伸缩。”

  • 因为我们知道第三种类型服务的上限
    所以我们只运行一个实例。我们也会给它一些负载,看看它可以服务多少个用户。如果我们知道账单系统的上限是1000个请求,并且每个服务实例可以处理200个请求,那么就需要5个实例。

0%