分布式计算框架--MicroTask性能测试实战

一、什么是MicroTask框架

酷家乐是以分布式并行计算和多媒体数据挖掘为技术核心的VR智能室内设计平台，吸引了超过300万室内设计师（覆盖全国40%的室内设计师）和超1000万业主用户。由于业务的特殊性：用户需要对材质效果进行实施的预览，而生成预览的3D数据需要大量的计算资源，对任务的实时性，可靠性有着较大要求。MicroTask框架是为了解决以上问题由酷家乐内部人员研发的一种通用的分布式实时任务队列编程框架，已经广泛的应用于酷家乐各个业务线。

二、为什么需要Micro Task

首先让我们回顾一下jetty的工作原理：jetty架构比较简单，分为acceptors，selectors和workers三个线程池。 acceptors负责接受新连接（非阻塞型） selectors处理HTTP消息协议的解包（非阻塞模型） workers处理请求（阻塞模型）。

一般是一个ServerSocket对应一个ServerConnector。如果服务器要监听多个端口，就会有多个ServerSocket，相应也会有多个ServerConnector。这上半部分Jetty已经给我们做好了，无需操心其内部实现。需要关心的是业务逻辑，在下半部分的Worker线程里运行。当一个请求过来时会创建一个Worker线程来处理这个请求

而酷家乐业务特点跟其他互联网公司由很大不同：

1.生成3D数据计算量比较大、资源消耗比较多

2.请求体往往比较大

3.nosql类型数据结构

服务端生成3D数据特别消耗资源，jetty处理请求是同步的，如果多个请求同步来生成3D数据整个服务会崩溃！！！Micro Task 主要“消峰”： 把耗费大量资源的计算任务丢到队列中，避免同步计算瞬间占满服务器资源导致整个服务崩溃 （在Micro Task中计算只会导致Worker挂掉）

业务请求体接近100MB 用户设计的建筑

三、Micro Task业务使用

业务表现应用：用户在左侧栏选中材质，拖拽到3d中生成的用户想要的效果。由素材数据转化成为3D坐标信息需要消耗大量的计算资源，而通过MicroTask分布式计算快速的生成3D坐标信息

请求流程：前端请求过来，service服务创建相应的计算任务，丢到任务丢列中。task服务器进行分布式计算，然后把处理的结果返回到任务队列中。此时前端不断的去轮询task的任务之到拿到返回结果。

四、Micro Task性能测试实战

1、指定合适的压测策略：

首先回归一下常用压测的名词：并发用户、并发、VU：一般用来表示虚拟用户（Virutal User，简称VU），对应到 Jmeter 的线程组线程每秒发送请求数；RPS：指客户端每秒发出的请求数，有些地方也叫做QPS 响应时间；RT：从发起请求到完全接收到应答的时间消耗。 有公式可知：并发数 = RPS * 响应时间，采用采用Micro Task的服务往往请求量（TPS）不高（相对于电商的抢购并发场景）所以应该采用 固定RPS压测的压测策略；这里我们一般使用Jmeter的Constant Throughput Timer来控制请求的发送速率。

2、压测数据准备：

在业界往往是用过抓取线上流量或者构建数据仓库编写MapReduce任务去制造压测数据，但是由于业务的特殊性（Nosql类型数据，字段多 很难宽表化处理）无法使用业务通用的造数手段。我们采用大数据手段，定期对线上数据布进行一些统计，准备一些合适的压测数据。（下图方案1，方案2都是MongoDB collection的一条数据,但是数据量缺相差很多，对于方案2给服务器带来的计算量是方案1的几百倍之多）

方案1 方案2

3、工欲善其事必先利其器：

酷家乐质量效能团队开发的jstressin完美兼容jmetter的jmx文件，支持压测脚本在线执行，分布式压测、在线管理压测用例、在线查看压测报告。通过jstressin平台轻松执行性能测试。

4、指标监控：

除了关注服务器的jvm，cpu，内存，网络和接口相应时间、接口错误率等等性能指标，MicroTask的队列变化，任务运行耗时，排队耗时也是要重点监控的。

五、最后

到这里酷家乐分布式计算框架–MicroTask压测方案已经介绍完了，因为篇幅的原因还有很多实施细节部分并没有完整表述，同时MicroTask压测也才初具雏形，欢迎有兴趣的同学联系我们一起探讨，

有表述错误的地方也欢迎大家联系我们纠正。