京东大促备战思路2.0大揭秘

正文

请到「今天看啥」查看全文

吞吐能力，指的是单位时间内处理请求的数量限制，一般用tps来衡量，指的是每秒处理请求的数量。

前面提到过要把总的业务量评估分解到自己的系统的吞吐量指标，可以把系统看成一个黑桶，看这个桶上边界输入的量和下面输出的量。

假设一个系统是客户订单处理系统，每一个订单向它输入2条处理请求，并向外界输出4条信息，如果一天的订单量是1000万，则这个系统要每天接收2000万个请求，输出4000万条信息。

对于直接面对客户的系统，输入的评估需要更多的维度（如促销、推广），但也有简单的评估办法，那把上一次大促作为参照，按业务量同比扩大。

当然，实际评估时，不能只看一天的业务量，还要看峰值，而且要高度重视峰值。前端系统的峰值评估需要考虑比较多的维度（如促销方式和力度等），后端相对简单，用于平均值乘以一个系数即可，这个系统可以根据系统以住大促时统计而来，如果是一个新系统，可以让上游系统协助评估。

并不是所有系统都要承担高峰值。如果一个业务处理流程比较长，则上游的系统可以平滑峰值，让下游系统享受一个平滑得多的请求流，这样可以大大减少系统的建设成本。

例如，在订单处理流程中，OFC 扮演了这一个稳压器的作用，OFC 把上游订单和峰值进行了平滑。所以吞吐能力的评估也需要团队合作。

• 容量规划：

吞吐量的提升，往往伴随着容量提升，需要做好容量规划，主要考虑的因素有：

1. 主业务对象的量（如订单）以及到大促前的增长量

2. 每个主业务对象会占用多少容量

3. 数据要在线上主系统中存留的时间

4. 出现高峰时，允许积压的数据量和积压时间

有了上面这几个数据，就比较好评估了。特别是针对4进行说明，有一些过程数据，处理完就不必要在主系统中存留了，所以在评估时不必考虑，但当出现高峰值，且系统处理无法及时处理时，可以积压一部分数据慢慢处理。

• 流量规划：

吞吐量的提升， 也往往伴随着流量的提升，需要做好容量规划，这时主要考虑峰值时流量即可，评估时可以按峰值吞吐量同比扩大。如果这个值比较大，应该和运维同事一起评估并寻求解决办法。

• 响应速度评估：

响应速度，是衡量服务对请求响应时间的指标，一般用毫秒计量，通常用 tp999，tp99，tp90 这几个指标，其中 tp999 指 99.9% 的服务请求的响应时间不会高于这个值。

提高响应速度，可以提高系统吞吐量。假设一个服务的响应时间为100ms，允许的并发数是500，则理论上这个服务的吞吐量上限为 5000（500*1000/100）tps；如果响应时间降低到50ms，则理论上的吞吐量上限会降为 10000tps。

但是提高响应速度会增加成本，一般说来可以采用类似下面的标准：

前端系统：

后端系统：

1.2.2. 系统性能评估与验证

一般有如下方法：

1. 线上服务的性能一般可以通过 UMP 来查看响应时间、吞吐量；

2. 对于 worker，则可以根据其实际输入输出的数据量来统计；

3. 线下压力测试。梳理出所有开放的接口，进行接口压力测试，线下进行。测试用的数据可以根据业务逻辑进行编制，也可以利用 TCP Copy等技术获取；

4. 线上读接口压力测试；

5. 线上写接口压力测试。这种测试应该非常小心，注意不要产生垃圾数据，对业务造成影响。常用的避免影响业务的方法有：a) 给数据打上测试标签，所有参与测试的系统都要根据此标签识别出正式数据和测试数据；b) 设计好数据处理流程，在这个流程的最后一步才是真正地把数据提交到正式的主业务库，而测试流程不执行这一步，或者结合标签的方法，在这一步过虑掉测试数据；

6. 减少线上服务器数量，让更少的服务器承担不变的压力，从而增大单台服务器的负载；

7. 如果面临大促，则可以考虑跨系统主流程压测：在上游积压一定量的数据，以设计好的速度下发请求，验证后面的流程在设计的并发请求量下是否畅通。这种方法不但需要跨研发团队沟通，也需要和业务团队进行沟通，因为可能会影响到生产时效，同时可能会影响团队绩效。

请到「今天看啥」查看全文