结论：生产环境推荐使用yarn方式部署

 

使用standalone遇到的问题

1) 同一个standalone cluster中的job相互抢占资源，而standalone cluster的模式仅仅只能通过task slot在task manager的堆内内存上做到资源隔离。同时由于前文提到过的Flink在standalone cluster中deploy job的方式本来就会造成资源分配不均衡，从而会导致App Analytics线流量大时而引起Game Analytics线淤积的问题；

2) 我们的source operator的并行度等同于所消费Kafka topic的partition数量，而中间做etl的operator的并行度往往会远大于Kafka的partition数量。因此最后的job graph不可能完全被链成一条operator chain，operator之间的数据传输必须通过Flink的network buffer的申请和释放，而1.1.x 版本的network buffer在数据量大的时候很容易在其申请和释放时造成死锁，而导致Flink明明有许多消息要处理，但是大部分线程处于waiting的状态导致业务的大量延迟。

Standalone模式下job的deploy与资源隔离共享

结合我们之前的使用经验，Flink的standalone cluster在发布具体的job时，会有一定的随机性。举个例子，如果当前集群总共有2台8核的机器用以部署TaskManager，每台机器上一个TaskManager实例，每个TaskManager的TaskSlot为8，而我们的job的并行度为12，那么就有可能会出现下图的现象：

第一个TaskManager的slot全被占满，而第二个TaskManager只使用了一半的资源！资源严重不平衡，随着job处理的流量加大，一定会造成TM1上的task消费速度慢，而TM2上的task消费速度远高于TM1的task的情况。假设业务量的增长迫使我们不得不扩大job的并行度为24，并且扩容2台性能更高的机器（12核），在新的机器上，我们分别部署slot数为12的TaskManager。经过扩容后，集群的TaskSlot的占用可能会形成下图:

新扩容的配置高的机器并没有去承担更多的Task，老机器的负担仍然比较严重，资源本质上还是不均匀！

除了standalone cluster模式下job的发布策略造成不均衡的情况外，还有资源隔离差的问题。因为我们在一个cluster中往往会部署不止一个job，而这些job在每台机器上都共用JVM，自然会造成资源的竞争。起初，我们为了解决这些问题，采用了如下的解决方法:

  1. 将TaskManager的粒度变小，即一台机器部署多个实例，每个实例持有的slot数较少；
  2. 将大的业务job隔离到不同的集群上。

这些解决方法增加了实例数和集群数，进而增加了维护成本。因此我们决定要迁移到on yarn上，目前看Flink on yarn的资源分配和资源隔离确实比standalone模式要优秀一些。