前提
假设我们为每个实例分配的CPU/MEMORY/NET是固定的。
三种类型业务的高负荷
第一种
独立的服务最容易伸缩，它可以进行线性地伸缩。如果用户增长了两倍，我们就运行两倍的服务实例, 就万事大吉了。第二种
服务依赖了外部的资源，比如那些使用了数据库的服务。数据库有它自己的容量上限，这个一定要注意。你还要知道，如果系统性能出现衰退，就不应该再增加更多的实例，而且你要知道这种情况会在什么时候发生。第三种
服务受到外部系统的牵制。例如，外部的账单系统。 就算运行了 100 个服务实例，它也没办法处理超过 500 个请求。我们要考 虑到这些限制。在确定了服务类型并设置了相应的标记之后，是时候看看 它们是如何通过我们的构建管道的。
应对方案
如果是第一种类型的服务
我们使用一个实例，并在这个环境里运行它，给它最大的负载。在运行了几轮之后，我们取其中的最小值，将它存入InfluxDB，将它作为该服务的负载上限。如果是第二种类型的服务
我们逐渐加大负载，直到出现了性能衰退。我们对这个过程进行评估，如果我们知道该系统的负载，那么就比较当前负载是否已经足够，否则，我们就会设置告警，不会把这个服务发布到生产环境。我们会告诉开发人员: “你们需要分离出一些东西，或者加进去另一个工具，让这个服务可以更好地伸缩。”因为我们知道第三种类型服务的上限
所以我们只运行一个实例。我们也会给它一些负载，看看它可以服务多少个用户。如果我们知道账单系统的上限是1000个请求，并且每个服务实例可以处理200个请求，那么就需要5个实例。