概述
本文簡單介紹：
1）工程部署的必要性/部署原理
2）單機和叢集的簡介/差別/適用場景/組成部件
3）各種部署方式的差別，什麼是容器化部署？
工程部署原理
為什麼不能直接用本地FineBI，而需要在伺服器部署工程？
問題：既然使用者可以直接在自己電腦端安裝 FineBI ，為什麼還需要在伺服器端部署FineBI工程呢？
答案：對於正式的企業工程，需要讓多個操作員連結到同一個工程，並讓多個查看者能夠在不同的電腦上存取同一個系統。
因此，需要在伺服器上部署工程，來確定不同的操作員和查看者可以在各自的電腦終端上存取工程。
為什麼推薦將工程部署在中間軟體中？
中間軟體是位於工件系統和應用程式之間的軟體層，用於支援應用程式之間的通訊和交互。
為了實現工程的更好可用性和穩定性，通常會將FineBI部署在中間軟體中。
部署在中間軟體中可以提供以下優勢：
應用伺服器可以提供更好的安全性：應用伺服器可以對傳輸協定和Web安全性進行控制和管理，可以使用HTTPS協定等加密協定來保證資料傳輸的安全性。
應用伺服器可以提供更好的效能：應用伺服器可以對請求進行負載均衡，以確定系統在高負載時仍然能夠高效地運作。
應用伺服器可以提供更好的擴展性：使用應用伺服器可以方便地擴展系統，併為不同的應用程式提供專用資源，進而確定應用程式的穩定性。
應用伺服器可以提供更高的可用性：應用伺服器可以提供高可用性和故障容許度機制，以最大化系統的可用性。
因此，將FineBI部署在中間軟體中可以提供更好的安全性、效能、擴展性和可用性，進而確定工程的穩定性和高可用性。
伺服器工程的運作原理
伺服器中工程部署的原理就是將 FineReport 報表工程部署到 Web 應用伺服器端。
使用者在用戶端產生一個查看請求，傳送給 Web 應用伺服器端。
Web 應用伺服器將FineBI的計算結果反饋給用戶端。
FineBI在計算結果時會涉及到資料庫的讀寫操作。
叢集與單機
什麼是叢集和單機？
單機
就是一個部署好的工程。
叢集
叢集（cluster）就是將多個相同的工程集中起來提供同一種服務，這些單個的工程就是叢集的節點（node）。
基於叢集的橫向擴展性，使用者可透過增加節點數量使併發趨於線性增長，進而獲得較高的併發支撐效能。
同時也可以用多個工程做備份，避免單機不可用導致系統停止造成的損失（業務中斷、資料/範本丟失），確定系統 7*24h 穩定運作。
叢集的優勢
帆軟叢集具有高可用性、高效能、易於管理、可伸縮性和安全保障等優點，適用於企業級的報表生成和管理需求，可以幫助企業更好地管理和控制報表資料的儲存、生成、共享等方面的效能和效果。
| 優勢 | 說明 |
|---|---|
| 高可用性 | 帆軟叢集透過叢集節點、負載均衡器、狀態伺服器等多個組件協同工作，有多個節點來分擔處理請求的負荷。 當叢集節點發生故障時，負載均衡器會自動將請求轉發到其他可用節點，保證系統的高可用性。 |
| 高併發 | 帆軟叢集允許平行處理多個儀表板生成和資料計算任務，透過多個節點進而實現任務的分散式處理。 透過叢集的橫向擴展，實現資料計算與儀表板生成的加速，進而提高整體的效能。 節點數量越多，支援的併發越高。 |
| 易於管理 | 帆軟叢集提供了完整的管理平台，包括叢集節點的監視、配置、部署和故障自動修復等功能，可以大大降低叢集維護和維運的難度和風險，幫助企業更好地管理和維護系統。
|
| 強擴展性 | 基於良好的架構設計，Web叢集具有良好的橫向擴展性，帆軟叢集可以快速增加叢集節點的數量，使併發趨於線性增長，以應對高峯期和流量波動，做到系統的可伸縮性和高效性。 |
叢集和單機的差別/叢集解決什麼問題？
當我們把叢集和單機比作一組出租車承接客人的話，它們的差別可以這樣解譯：
1）解決高負載問題
單機就像是一輛出租車，它可以接受乘客的訂單，但是如果訂單請求變得非常多，該出租車的服務能力可能無法滿足，並可能會出現效能瓶頸。
此時，你需要多輛出租車來分擔訂單處理工作。而這些出租車可以被組成為一個出租車隊的形式稱之為叢集。
這樣，您可以將乘客分配到不同的車輛中，並將他們同時送到目的地，進而提高服務效率。
2）解決高可用問題
但是，僅僅增加車輛的數量只能解決工程高負載問題，並不足以保證高可用性。
您還需要一個良好的車隊管理系統來確定每輛車都可以順利地運作，並提供相同的服務品質和客戶體驗。
在叢集設計中，這意味着您需要將多個伺服器組合在一起，以實現負載均衡、配置資訊資料庫、狀態伺服器和檔案伺服器等功能。
這些組件可以確定整個叢集的高可用性，並提供穩定的服務。
3）總結
叢集和單機的主要差別在於共享資源和協作工作。
叢集中，多個工程相互通訊共享資料和任務，可以提供更好的可延伸性和更高的效能。
單機中，所有的資源都被獨佔使用，沒有擴展性和動態性可言。
總之，叢集設計是一種有效的解決方案，可以提高系統的負載能力和可用性，並確定系統的穩定性和一致。
叢集為什麼需要多類組件？
在搭建叢集時，需要注意到這不是一件輕鬆簡單的事情。
為了提供無縫絲滑的服務，必須提高服務品質並組建一個優秀的車隊。
我們需要考慮如何構建一個良好的車隊，這是叢集架構需要解決的問題。
| 組件 | 說明 |
|---|---|
| 工程節點 | 叢集節點就是一輛輛出租車。 當某個出租車出現了故障，會自動安排其他出租車來代替它的工作，以確定整個車隊仍然正常工作。 帆軟叢集設計避免了主節點的概念，只將第一個加入叢集的節點作為基準節點。每個節點都平等地提供服務和進行管理操作。 每個節點都是一個可以獨立運作的工程，負責處理使用者的請求，處理生成報表的任務和管理其他組件的工作。叢集節點間透過一系列的網路協定和服務進行通訊和協作。 |
| 負載均衡 | 負載均衡就像出租車隊的調度中心，用於協調和分配所有的工作和請求。 在接待客戶時，負載均衡作為統一入口，負責對接客戶，不需要讓客戶一個個訊問司機。 在叢集中，負載均衡用於分配任務到各個節點上，使它們能夠更高效地工作。 負載均衡器會在所有節點之間平衡負載，確定每個節點都分配到足夠的任務並保持忙碌狀態。 |
| 外接資料庫 | 配置庫，即外接資料庫FineDB，類似於出租車隊的車管所。 它儲存並維護所有車輛和司機的資訊，為每個司機提供相同的車輛裝飾、報價、出行路線等資訊。讓每一輛車都給顧客提供一致的出行體驗。 在叢集中，配置庫用於儲存和維護所有節點的配置資訊和參數，這些參數是為了使叢集節點協調工作而必須合理設定的。 |
| 狀態伺服器 | 狀態伺服器就像出租車隊的管理中心。 它負責監視和維護車隊的整體狀態，包括車輛和司機的位置，以及服務進度。 在叢集中，狀態伺服器也執行相似的任務。它監視每個節點及整個叢集的運作狀態、記錄日誌和錯誤資訊、協調節點間的通訊和任務分配等。 |
| 檔案伺服器 | 檔案伺服器類似於出租車隊的儲存倉庫。 它儲存所有與車隊相關的檔案，包括車輛維護記錄、保險單、車輛位置資料等。 在叢集中，檔案伺服器用於儲存和共享叢集中所需的檔案和資料資源，以確定每個節點都可以存取並使用它們。 |
帆軟叢集的架構非常靈活，可以根據不同的業務需求和特點進行配置。想要開啟叢集必須至少滿足以下條件：
1）有1個以上工程節點
2）節點配置了外接資料庫
3）節點配置了狀態伺服器
4）如果有2個以上工程節點，則必須配置檔案伺服器
抽取叢集與直連叢集
什麼是抽取叢集和直連叢集？
直連叢集：
FineBI工程中只使用直連資料，不使用抽取資料
抽取叢集：
FineBI6.0工程，全新部署叢集，工程中使用了抽取資料。
FineBI5.x熱備工程升級FineBI6.0，升級後取消熱備，建議調整為抽取叢集
抽取叢集的優勢
1）業務高可用
方案特性：
叢集由多個同步節點和非同步節點組成，只要還有一臺同步節點存活，就能夠提供完整的資料，保證資料查詢高可用性。
當資料更新在執行程式中出現異常（當機或節點假死），則透過恢復機制，將正在進行的任務重新恢復為執行前的狀態，並重新執行，以保證更新業務的高可用。
特性表現：
與熱備相比，抽取叢集中節點當機時不再會有節點切換的耗時，降低了不可用的時間。
此外，6.0叢集還支援更新業務的高可用，提供更新任務的異常恢復機制。
2）查詢高併發
方案特性：
多臺節點同時提供查詢服務，實現負載均衡，查詢併發量隨節點數量近似線性提升，提供可橫向擴展的查詢能力。
特性表現：
抽取叢集的查詢，達到了真正的負載均衡，且併發效能可以隨節點增加而線性增加。
抽取叢集方案並不優化單個節點的併發數，而是優化整體。
抽取叢集方案的效能提升，隨節點數增加非整倍的提升，會有一定的衰減。
注：下表用六種情況，展示在不同節點和併發數下，查詢效能的表現。這些情況僅作為測試用例，實際部署中節點數不推薦超過5，併發數不止支援140。
實際配置中，需要根據使用者使用高頻場景（查看儀表板/自助分析），來選擇最優節點數，詳情請參見：工程部署方案選擇
| 節點數-併發數 | 相比單機，效能提升的倍數 |
|---|---|
| 單節點-10併發 | - |
| 4節點-40併發 | 3.6 |
| 7節點-70併發 | 6.7 |
| 單節點-20併發 | - |
| 4節點-80併發 | 3.6 |
| 7節點-140併發 | 6.1 |
3）提升更新吞吐量
方案特性：
可以透過增加節點的方式來提高更新效能，更新耗時隨節點數變多呈現非線性降低的趨勢。
特性表現：
多表更新任務的更新效能，隨節點數變多，呈現非線性地先提升後降低趨勢（由於資料同步機制）。
抽取叢集方案並不優化單個節點的更新效能和吞吐量，而是優化整體。
由於資料同步機制，單表更新在多節點的更新效能會比單節點有所下降。
由於資料同步機制，全局更新的效能提升，在4節點會相比於3節點有所下降。因此部署中節點數不推薦超過5（相比單機，提升幅度還算比較大）。
注：實際配置中，需要根據使用者使用高頻場景（查看儀表板/自助分析），來選擇最優節點數，詳情請參見：工程部署方案選擇。
| 節點數 | 相比單機，全局更新效能提升的百分比 |
|---|---|
| 單節點 | - |
| 2節點 | 31% |
| 3節點 | 39% |
| 4節點 | 37% |
抽取叢集的運作原理
1）更新調度
資料更新請求可以向所有節點均衡轉發。
所有節點均可對更新任務進行預處理，將更新任務的資訊儲存到任務佇列。
所有同步節點可領取資料集更新子任務，並進行實際的抽取。
資料集在某節點抽取完成後，會同步到其他同步節點，全部同步完成後，該資料集才視為更新完成。
2）資料同步
同步節點：
該類節點上的資料檔案狀態都保持最新，即保持資料強一致。更新程式中，必須保證該類節點資料同步完成，才算更新成功。
該類節點是高可用的基本保障，也是查詢和更新高併發的主力。
非同步節點：
6.0.8之前版本，該類節點是查詢高併發的支撐。節點上的資料檔案可以不是最新的，透過聽不的機制，逐漸將該節點上的資料更新為同步節點一樣的狀態。
6.0.8及之後版本，該類節點是查詢轉發的支撐。節點作為不使用引擎功能的查詢節點，本地不儲存抽取資料，只做查詢轉發。
3）查詢請求轉發
資料查詢請求可以向所有節點均衡轉發；
若配置庫傳回的節點資料狀態為最新狀態，則由該節點處理請求；
6.0.8之前版本，若節點資料落後，則BI內部轉發請求到最新資料的節點，並觸發本節點的資料同步。
6.0.8及之後版本，所有請求都會轉發到有最新資料的節點，不需要更新非同步節點的資料。
容器化部署與傳統部署
什麼是容器化部署和傳統部署？
傳統部署：
使用者可以自行準備，或使用帆軟封裝的部署包，搭建最普通的工程架構，即「FineBI工程 jdk環境 tomcat中間軟體」
容器化部署：
將應用“容器化”的程式，就是讓應用能夠運作在 Docker 容器或類似技術中，它們能將工件系統環境和應用封裝在一起（完整的系統鏡像）。
由於容器能給應用提供近似於完整系統的環境，這就為在不修改，或者少量修改應用的情況下，對應用的部署進行現代化改造提供了一種思路。
這也是應用的架構持續能保持“雲友好”的基礎。
容器化部署的優勢
相比於傳統部署架構，容器化部署可大幅降低客戶的維護成本和資源成本。
1）維護成本低
每個工程的環境相互隔離，出現異常時影響範圍小。
升級、災備、回滾方便。
2）資源成本低
多叢集管理、多租戶、微服務化，更高資源使用率。
資源彈性伸縮。
容器化部署和傳統部署的差別
容器在整個應用程式生命週期工作流中提供以下優點：隔離性、可攜性、靈活性、可伸縮性和可控性。
最重要的優點是可在開發和營運之間提供隔離。
| 對比項 | 傳統方式部署 | 容器化部署 |
|---|---|---|
| JVM初始配置 | 需要自行手動修改 Tomcat 配置檔案或其他容器對應配置檔案 大部分使用者可能不會完全配置，導致後續業務上出現異常 | 預設已經在鏡像中配置好了常用的所有jvm參數，避免大多jvm參數造成的問題 yaml檔案中可以單獨配置Xmx記憶體上限 |
| 負載均衡 | 需要單獨安裝 Nginx 或其他負載軟體，並進行轉發配置 存在使用者可能缺少很多配置，導致某些業務出現異常 可以根據需要配置keepalived nginx的高可用架構 | 一鍵部署時，預設自動安裝好nginx且已自動配置好（不支援其他負載） 避免因客戶自行配置錯誤或缺失導致的問題 |
| 硬體要求 | 雖然有推薦，但沒有強制 | 強制要求所有節點至少500G磁碟空間和16G記憶體 防止在不適合的硬體環境中部署工程，埋下隱患 |
| 組件要求 | 沒限制，所有產品支援的組件都可以配置 | 沒限制，所有產品支援的組件都可以配置 同時支援mysql、redis和minio的部署 |
| 工件系統要求 | 基本無限制 | 支援 amd64 架構的 Linux 系統 centos7.3 以下版本不支援 ubuntu18 以下版本不支援 防止因工件系統版本過低，導致工程運作出現問題 |
| 防火牆要求 | 需要對應伺服器開放使用到的埠即可 | 必須開放所有節點所有組件使用的埠，否則無法部署 確定不因埠問題導致工程運作異常 |
| 單機部署 | 不配置外置庫和其他組件的情況，上傳部署包直接啟動即可 否則需要單獨配置外置庫和組件以及需要的環境、如jdk | 本機root使用者可以一鍵部署 支援在yaml檔案中配置相關節點和組件資訊後部署 支援透過yaml檔案配置使用者原有的組件 |
| 權限要求 | 需要保證檔案權限 | 普通使用者需要sudo權限（已經安裝好docker，且使用者屬於docker使用者組則無需權限） cp tar rm groupadd gpasswd groups dockerd systemctl（docker服務開機自啟需要，不強制） |
| web容器配置修改 | 修改如tomcat目錄下的配置檔案後重啟tomcat | 可以透過維運平台實現前端修改 |
| jvm參數修改 | 直接修改對應檔案即可 | 可以透過維運平台實現前端修改 |
| 環境影響 | 使用受到各種環境影響，如：jdk、glibc、系統字體、系統語言、系統時間等都可能造成某些業務問題 | FR/BI應用都使用docker容器部署，環境統一，只要能支援部署，基本沒有環境影響 |
