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