在2017年在线技术峰会——阿里开源项目最佳实践上，来自阿里巴巴中间件的技术专家卫乐分享了Jstorm开源最佳实践。他主要介绍了Jstorm的架构，从性能、稳定性、监控系统、大规模部署、反压、灰度发布&热升级、Exactly-Once、新的窗口机制等方面详细扥想了Jstorm做的优化。以下内容根据直播视频整理而成。

关于阿里中间件，欢迎访问官网了解更多：https://www.aliyun.com/aliware

视频回顾：点击进入

Pdf下载：点击进入

发展历史

JStorm从2013年开始开发，历经了25个版本。从2014年“双十一”开始，做了管控平台，包括调度、用户自定义日志等特征。2015年的“双十一”，对调度进行了优化，并且增加了反压功能，重新设计了Topology Master。2016年，除了性能优化之外，还提供了Exactly Once，包括把社区的Sliding Window和Shade Dependency等特性都移植到JStorm，此外还提供了很多新的feature，如重构的窗口机制，灰度发布等。

使用场景

Jstorm在阿里集团、蚂蚁、优酷、土豆、高德都使用非常广泛。有三种部署方式：Standalone、JStorm-on-YARN、JStorm-on-docker（主推，可以一键部署，扩容缩容方便）。

Jstorm已经不是简单的实时计算了，其应用在很多场景：

• 反欺诈：Nut/Velocity；
  
• 审计：阿里妈妈广告/P4P，AMG；
  
• 数据统计分析：Eagleeye，AE，BI；
  
• 监控：Tlog（阿里内部监控），Rds-monitor（SQL监控），Oceanbase-monitor（SQL监控）, Cainiao Radar, YunOSMonitor；
  
• 数据同步：RDS-Log-Sync, Unify-Log；
  
• 实时推荐：Alipay 1315, Alipay Hyperloop, TPP；
  
• 应用调度：AE邮件实时分析，网销宝。
  

架构

JStorm的整体架构如上图所示。最下方是部署模式，JStorm Core是JStorm计算框架本身，其上是Raw Storm API（此接口相对底层）、Exactly Once、Extension API。其上是集团内部广泛使用的Plugin，SQL engine上是应用。最右边是管控平台Koala。

JStorm增强

性能

上图是去年JStorm 2.2.0和Storm 1.0.2的性能对比图。硬件是32CPU Core/128G物理机，每个Worker是6G内存。从图中可以看到在不同的Worker已经不同的并发下，JStorm至少是Storm两倍以上的性能。那么，如何进行的性能优化？

性能优化在现代的流处理领域广泛认可的一种方式是做Batch，Batch对性能优化的影响是非常大的。Batch是将消息打包，从上游接收一些消息，处理完后进行Batch再往下发，能够节省很多资源，提高性能。在此基础上进行了路径优化，即对JStorm做了JVM层面的Profile，检测框架的hot function部分（调用比较多的部分），进行针对性优化。虽然对JStorm进行了重构Metrics体系，但是底层的Metrics Core库并没有优化，所以对Meter，Histogram等进行了优化。此外，在序列化方面，对常用的序列化都进行了调优。

稳定性

在稳定性方面，做了以下优化：

多集群部署方面，由于涉及到异地多机房、同城多机房等问题，所以同城方面使用了ZK做多机房的容灾，JStorm自动把这些作业调到别的机房，只要保证别的机房的Worker量可以支撑作业量就不会出现问题。跨城情况相对复杂，成本也比较高，在阿里使用多链路来解决，即在多城市部署一模一样的集群消费同一份数据，在输出上做一些灾备，输出到不同的异构数据输出中，这样任意一条链路挂掉就能实时切换。

隔离方面，standalone提供了天然的隔离性，因为Docker本身用cgroup做资源隔离，所以jstorm-on-docker的隔离也相对简单。jstorm-on-yarn是在yarn上的Container中开启cgroup来做隔离。

HA方面，JStorm的HA是很早的特性，非常稳定。节点自检是checkhealth，用于检查supervsior。脚本会在supervsior压力过大或者内存快满的情况下自动调整可用Worker数（降低）。

监控方面，JStorm的自定义metrics重新实现，管控平台Koala集成了监控报警。Tuple life style能够根据节点间花费的时间得知拓扑结构中比较慢的环节。

升级/降级方面，降级即JStorm的反压，升级即热部署和灰度发布。

监控系统

Jstorm的监控系统如上图所示，重新设计的监控系统的优点在于自动聚合的功能。从下往上，一个Task有多个Stream，Task往上是Component，再往上是Topology，再往上是Cluster。重新设计后的优点在于可以统计所有级别的Metrics，展现完整的历史曲线，而不是单点的数据。

自定义监控

上图是Metrics整个分级汇总的实现。具体可见github源码中最新的metrics设计文档。

大规模部署

在没有Topology Master的情况下，所有的Task汇报心跳、发送Metrics的时候都需要写ZK，并且Storm是把Metrics直接ZK里面，这样ZK的压力更大。有了Topology Master之后，Topology Master是Task的总节点，Task汇报心跳的时候只需要向Task汇报心跳，Topology Master汇总后再发送给Nimbus或者ZK，这样会使ZK的压力缩到拓扑的量级。

反压

Storm的反压，比如bolt处理消息来不及的情况下会向ZK写一个节点进行反压，监听bolt上游的节点停止发送数据直到下游的bolt能够正常处理。这样的问题是数据可能出现骤降的过程，并且反压结束数据流下来之后容易导致新一次的反压，从而导致tps会一直抖动。

Jstorm做了两级的反压，第一级和Jstorm类似，通过执行队列来监测，但是不会通过ZK来协调，而是通过Topology Master来协调。在队列中会标记high water mark和low water mark，当执行队列超过high water mark时，就认为bolt来不及处理，则向TM发一条控制消息，上游开始减慢发送速率，直到下游低于low water mark时解除反压。此外，在Netty层也做了一级反压，由于每个Worker Task都有自己的发送和接收的缓冲区，可以对缓冲区设定限额、控制大小，如果spout数据量特别大，缓冲区填满会导致下游bolt的接收缓冲区填满，造成了反压。

灰度发布&热升级

一个规模很大的拓扑，以前的升级需要先把拓扑kill掉，修改代码、重新打包、重新提交，导致应用会有短暂的时间不能使用。此外，有时候只想升级部分的Worker，不想重启整个拓扑。灰度发布和热升级是做Worker内部的重启，但是不会kil拓扑。

Exactly-Once

在Jstorm中，Exactly-Once是通过Topology Master来做协调的。Jstorm中的Exactly-Once并不像以前那样每发一条消息一次。Spout发一个Batch，会有一个Batch ID，并且立马发一个Checkpoint barrier（控制消息），TM会得知发了一条新的Batch，TM会把offset记录下来。Bolt分为两种，一种是Stateless Bolt，一种是Stateful Bolt。Stateless Bolt比较简单，就是正常处理，继续往下游Bolt发。Stateful Bolt则需要把状态存起来，把Checkpoint发送给Topology Master，直到Ending bolt向TM发送Checkpoint barrier。当所有的Ending bolt都做完Checkpoint后，就会将状态存在Hdfs/hbase中，再通知Spout发送下一个Batch。

实际上，每一个batch的处理和发送是可以并行的，只是TM本身的Checkpoint是串行的，这样就可以很好的提高性能。比如中间有一个Batch处理失败了，TM会得知，此时就会做Rollback，向Spout发送Rollback barrier，从Hdfs/hbase中找出最近完成的Checkpoint，删除历史无用的Checkpoint，Spout会从状态中重新恢复Offset，Stateless Bolt会继续处理，Stateful Bolt会把Checkpoint所对应的状态从Hdfs/hbase中拉出来恢复，再根据数据计算。

其他特性

其他的特性包括自定义调度、动态调整日志级别、自定义日志（外部应用可以很方便做日志采集、基于日志的监控报警）、用户自定义metrics（根据业务日志做监控报警）、优雅shutdown（把所有的消息处理完之后再shutdown）、动态扩容、更新配置。

新的窗口机制

Storm的Window有很多问题，所有的数据需要统一处理，在工业级的产品中不可行。重构的窗口机制不会在内存憋每个窗口的数据，只需要存每个窗口的处理结果。重构的窗口机制，支持Processing time、Ingestion time、Event time、Watermark (late element)、Window early fire。

JStorm Future

Apache Beam提供了一次编写、多个不同引擎到处运行的特性。JStorm也会适配Beam，做Apache Beam JStorm runner。JStorm SQL需要进行重构和优化。将来计划在Jstorm上封装一些算子、整合框架，使其易于开发、调试，性能更加优化。