結論：生產環境推薦使用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，自然會造成資源的競爭。起初，我們為了解決這些問題，采用了如下的解決方法:
- 將TaskManager的粒度變小，即一台機器部署多個實例，每個實例持有的slot數較少；
- 將大的業務job隔離到不同的集群上。
這些解決方法增加了實例數和集群數，進而增加了維護成本。因此我們決定要遷移到on yarn上，目前看Flink on yarn的資源分配和資源隔離確實比standalone模式要優秀一些。
原文鏈接：https://segmentfault.com/a/1190000020209179