从Heron看实时计算系统差异对比

      真的有很久没有更新博客了，上一次更新还是2014年。那时候就在写云计算君临天下。感叹变化太快，自己14-15年从storm到全栈工程师，到产品经理，现在又重回大数据，不胜唏嘘。

      这两年里，许多新的开源系统发布，平均1、2年技术栈都要变一下。当然，其中最火爆的莫过于spark了。spark集批量计算，实时计算，SQL计算，图计算，机器学习与一身。以scala语言的易编程特点几乎一统大数据"计算“领域的江湖。

      不过streaming始终还是以min batch来作为最小单位进行计算，实时性上更适合分钟级的分析统计类应用。对于ms或者秒级实时的场景依然不太合适。当然目前实时计算领域还有一个flink设计上很牛逼，天然支持了状态计算，只可惜社区不够活跃，难以被大多数公司所采用。

      以上只是一个大致的概览，回到本文的主角——Heron，storm的继承者。沿用了storm的数据模型——经典spout-bolt模型。而又从架构上弥补了storm存在的缺点。

      1、资源最小单位——topology采用了进程的方式开并发，而不是以往的线程方式。利于资源隔离，debug，profilling以及troubleshooting等更加友好。但其实也有所失就是开进程开销总是要比线程要大。

      2、资源约束——topologies会严格使用自己所allocate的资源，而不会占用其他组件资源造成竞争，运行起来更加安全。当然安全的缺点就是可能会造成资源的浪费。这和虚拟机超卖是一个道理，有利有弊

      3、兼容性——完全兼容storm的代码，甚至做到不改一行代码直接编译后就能在Heron上运行

      4、背压机制——分布式系统中组件的执行速度各不相同&#