一、故事背景

最近负责的业务由于三方配额不够，需要购买配额。问题来了，买多少配额合适？下图是目前的调用关系。由于是关于IOT的业务，其中老的实现是设备直接调用三方接口（安卓设备调用Http接口）。后来由于长远规划，逐步增加一层「平台服务」。新版本的设备调用「平台服务」，由后者调用「三方接口」。

调用情况

已知：

• 「三方接口」一段时间的配额内的调用次数统计。小时、天、20分钟等等。
• 「平台服务」统计的新版本设备调用次数统计，以及由于配额超限导致的失败次数。
• 「平台服务」调用「三方接口」的平均耗时。
• 当前购买的并发数配额。

求：

• 高峰期实际一小时调用量。
• 实际高峰期需要并发配额，从而知道还需要买多少。

二、计算所需配额

<1> 高峰期实际一小时调用量

要求「高峰期实际一小时调用量」，如果同一时刻调用失败率全局相同，就很容易得出，即：

高峰期实际一小时调用量 = 这一小时的配额内调用量 / (1 - 这一小时的超配额的失败率)

「平台服务」统计的高峰一小时的失败率是否能代表同一小时「旧版本设备」的失败率呢？
响应超过配额的是「三方接口」端，站在这个角度，它并没有对这两个地方来的调用做区分，所以应该失败率是全局的。

<2> 实际高峰期需要并发配额

这里对于2个概念重新再回顾下：

QPS：对一个特定的请求，服务端每秒钟可以处理的次数；
并发：服务端可以同时处理的请求次数。如果一个请求服务端还在处理中，就会占用一个并发。

一个并发的QPS = 1秒 / 接口平均耗时

实际需要总QPS= 实际需要并发数 * 一个并发的QPS

高峰期实际一小时调用量 = 实际需要总QPS * 3600秒

联立上面三个式子，可以求出「实际需要并发数」，其余参数都可直接或者间接得到。

三、还没完

本以为根据上面得到的配额买了加上去就大功告成。发现失败率下降不少，但是仍然还是存在。考虑到上面计算的配额是根据一小时的调用统计进行计算，虽然根据监控，分钟级别调用均匀，但是在秒级别看就存在波峰波谷了。事实上「平台服务」层已经做了削峰操作。使用线程池进行控制并发线程数控制小于购买的并发数，目的是给旧设备一些并发余量。

目前看来需要设备全部切到平台才可以做到准确的控制。削峰要考虑以下两点：
1.对于下游服务的访问是否做到准确控制；
2.必须在满足对于上游调用方响应耗时承诺的前提下，对下游访问进行控制；