開一個新坑，系統性的學習下 Flink，計劃從整體架構到核心概念再到調優方法，最后是相關源碼的閱讀。
今天就來學習 Flink 整體架構，我們先看官網的架構圖
圖中包含三部分，分別是 Client、JobManager 和 TaskManager。其中 Client 并不屬于 Flink 集群，它主要用來把用戶編寫的程序翻譯成 StreamGraph 然后優化成 JobGraph，再將 JobGraph 提交到 Flink 集群執行。
JobManager
Flink 集群的 JobManager 是用來接收 Client 提交的任務，并且分發給 TaskManager 去執行。此外，JobManager 還有一些其他的職責，例如任務調度，協調 checkpoint 和協調從失敗中恢復。
每個 Flink 集群至少要有一個 JobManager，但在生產環境中通常是高可用模式部署，即部署多臺 JobManager，其中一臺作為 Leader，其他的作為 Standby 節點。當 Leader 掛掉時，其他的 Standby 節點會有一臺被選舉為新的 Leader 提供服務。這樣就能避免 JobManager 單機故障影響到整個 Flink 集群的可用性。
JobManager 主要由以下幾部分組成，下面我們分別來看每部分的作用。
DataFlow Graph
JobManager 收到 JobGraph 之后，根據并行度的設置，將各個算子任務拆分成并行的子任務，最終生成 ExecutionGraph。
Checkpoint coordinator
Checkpoint 是 Flink 最核心的概念之一，Flink 的容錯機制主要靠 checkpoint 來保障。而 checkpoint 的生成會恢復則由 checkpoint coordinator 來負責。
Job Dispatch
Job Dispatch 提供了 REST 接口用于提交 Flink 任務，并為每個任務啟動一個 JobMaster。JobMaster 負責管理單個 JobGraph 的執行。
Task Scheduling
Task Scheduling 負責 Task 部署和調度，值得一提的是，JobManager 和 TaskManager 以及 Client 之間的通信都是通過一個叫 Actor System 的 RPC 系統實現的。
Resource Manager
Resource Manager 負責集群中的資源的分配回收，它管理的資源單元叫做 task slot，對于不同的部署環境，Resource Manager 有不同的實現，
Actor System
Actor System 是 Flink 集群中的一種 RPC 通信的組件，JobManager 和 TaskManager 以及 Client 之間的通信都是基于 Actor System 的。而 TaskManager 之間的數據傳遞是基于 Netty 的。
TaskManager
聊完了 JobManager，我們再來看下 TaskManager 的結構。TaskManager 主要負責執行作業的 task，并緩存和交換數據流。TaskManager 中最小的資源調度單位是 task slot，這點在前面介紹 Resource Manager 時也提到過。它表示并發處理 task 的數量。
Task Execution
TaskManager 在接到 JobManager 部署的任務后，就會申請相應的 task slot 去執行任務。
Data Exchange
Data Execution 主要負責 TaskManager 之間的數據交互的一些操作，這里主要關注邏輯層面，例如一些 shuffle 操作。而網絡傳輸則主要是由 Network Manager 來實現。
Memory Management
Memory Management 負責 TaskManager 的內存管理，在執行任務過程中，接收到的一些數據是需要放在內存中進行處理的。相應的內存管理操作依賴于 Memory Management 模塊。
Actor System
Actor System 我們在前面提到過，TaskManager 和 JobManager 之間的通信全靠它。
Network Manager
Network Manager 主要負責 TaskManager 之間的數據交互，它是基于 Netty 實現的。
最后多提一個 Graph 的概念，前面我們已經了解到了 JobManager 會將 JobGraph 根據并行度的配置轉換成 ExecutionGraph。在這之后，JobManager 會對作業進行調度，將 task 部署到各個 TaskManager 上，最終就形成了物理執行圖，也就是 PhysicalGraph。
這里小結一下，Flink 中四種圖的生成順序是：用戶編寫的代碼生成 StreamGraph，Client 將其進行優化，主要是將多個符合條件的節點 chain 在一起，生成了 JobGraph，然后將 JobGraph 提交到 JobManager，再由 JobManager 生成并行版本的 ExecutionGraph，待JobManager 將 task 調度后，生成的圖被稱為 PhysicalGraph。
Flink 的幾種部署模式
根據集群的生命周期、資源隔離以及 main() 方法的執行，通常將 Flink 的部署模式分為三種：Session Mode、Per-Job Mode 和 Application Mode。下面我們分別介紹這三種部署模式。
Session Mode
Session Mode 下，所有的任務共享 JobManager 和 TaskManager，JobManager 的生命周期不受提交的 Job 影響，會長期運行。
Per-Job Mode
Per-Job Mode 下，每個任務獨享 JobManager 和 TaskManager，資源充分隔離。JobManager 的生命周期和 Job 的生命周期綁定。
Application Mode
Application Mode 下，每個 Application 對應一個 JobManager，且可以運行多個作業。客戶端無需將依賴包上傳到 JobManager，只負責提交作業，減輕了客戶端的壓力。提交作業后，JobManager 主動從 HDFS 拉取依賴包。
三種模式的對比
| Session | Per-Job | Application | |
|---|---|---|---|
| 優點 | 1、資源充分共享，提升資源利用率 2、作業集中管理，運維簡單 | 1、資源充分隔離 2、每個作業的 TM Slots 可以不同 | 1、有效降低帶寬和客戶端負載 2、Application 之間實現資源隔離，Application 中的資源共享 |
| 缺點 | 1、資源隔離差 2、TM 不易擴展，伸縮性差 | 1、資源浪費 | 1、僅支持 Yarn 和 Kubunetes （個人感覺夠用了） |
總結
最后來總結一下，今天主要學習了 Flink 的整體架構和三種部署模式。
1、Flink 的集群架構上主要包含 JobManager 和 TaskManager，其中 JobManager 主要負責一些作業調度和資源協調的工作，TaskManager 則主要負責執行任務。
2、Flink 的部署模式分為 Session、Per-Job 和 Application 三種，Session 模式是所有 Job 共享 JobManager 和 TaskManager，Per-Job 則是作業獨享的，而 Application 模式則是在 Application 中共享 JobManager。
詳解)
