一、故事背景
最近负责的业务由于三方配额不够，需要购买配额。问题来了，买多少配额合适？下图是目前的调用关系。由于是关于IOT的业务，其中老的实现是设备直接调用三方接口（安卓设备调用Http接口）。后来由于长远规划，逐步增加一层「平台服务」。新版本的设备调用「平台服务」，由后者调用「三方接口」。
调用情况
已知：
- 「三方接口」一段时间的配额内的调用次数统计。小时、天、20分钟等等。
- 「平台服务」统计的新版本设备调用次数统计，以及由于配额超限导致的失败次数。
- 「平台服务」调用「三方接口」的平均耗时。
- 当前购买的并发数配额。
求：
- 高峰期实际一小时调用量。
- 实际高峰期需要并发配额，从而知道还需要买多少。
二、计算所需配额
<1> 高峰期实际一小时调用量
要求「高峰期实际一小时调用量」，如果同一时刻调用失败率全局相同，就很容易得出，即：
高峰期实际一小时调用量 = 这一小时的配额内调用量 / (1 - 这一小时的超配额的失败率)
「平台服务」统计的高峰一小时的失败率是否能代表同一小时「旧版本设备」的失败率呢？
响应超过配额的是「三方接口」端，站在这个角度，它并没有对这两个地方来的调用做区分，所以应该失败率是全局的。
<2> 实际高峰期需要并发配额
这里对于2个概念重新再回顾下：
QPS：对一个特定的请求，服务端每秒钟可以处理的次数；
并发：服务端可以同时处理的请求次数。如果一个请求服务端还在处理中，就会占用一个并发。
一个并发的QPS = 1秒 / 接口平均耗时
实际需要总QPS= 实际需要并发数 * 一个并发的QPS
高峰期实际一小时调用量 = 实际需要总QPS * 3600秒
联立上面三个式子，可以求出「实际需要并发数」，其余参数都可直接或者间接得到。
三、还没完
本以为根据上面得到的配额买了加上去就大功告成。发现失败率下降不少，但是仍然还是存在。考虑到上面计算的配额是根据一小时的调用统计进行计算，虽然根据监控，分钟级别调用均匀，但是在秒级别看就存在波峰波谷了。事实上「平台服务」层已经做了削峰操作。使用线程池进行控制并发线程数控制小于购买的并发数，目的是给旧设备一些并发余量。
目前看来需要设备全部切到平台才可以做到准确的控制。削峰要考虑以下两点：
1.对于下游服务的访问是否做到准确控制；
2.必须在满足对于上游调用方响应耗时承诺的前提下，对下游访问进行控制；
