概述
本文簡單介紹:
1)專案部署的必要性/部署原理
2)單機和叢集的簡介/差別/適用場景/組成部件
3)部署架構/維運平台的作用
本地部署與伺服器部署
問題:
既然使用者可以直接在自己電腦端安裝 FineBI 和設計器,為什麼還需要在伺服器端部署專案呢?
答案:
官網提供的個人試用版FineBI和設計器,內建了Tomcat伺服器,所以可以直接使用。
但是每個試用版FineBI和設計器,都對應了一個本地工程,大家無法共用同一個工程。
對於正式的企業工程,需要讓多個操作員連結到同一個工程,並讓多個查看者能夠在不同的電腦上存取同一個工程。
因此,需要在伺服器上部署工程,來確定不同的操作員和查看者可以在各自的電腦終端上存取同一個工程。
容器化部署與傳統部署
帆軟為什麼採用容器化部署方案?
相比於傳統的中間軟體+jdk+工程的部署方式,帆軟採用維運平台進行容器化部署。
容器化部署,是使用容器化技術(如Docker),將應用程式和依賴的環境配置,封裝在一個獨立容器中。
相比於傳統部署架構,容器化部署可大幅降低客戶的維護成本和資源成本。
專案生命週期 | 傳統部署 | 維運平台部署 | |
---|---|---|---|
環境準備 | 作業系統 硬體配置 | 無法進行檢查 可能會因為作業系統版本過低、磁碟空間不足、記憶體不足,為工程埋下隱患,導致當機 | 對部署環境的作業系統、記憶體、磁碟空間均進行強制檢查,防止部署在不適合的伺服器中 |
叢集組件 配置庫 維運組件 | 需要自行準備組件介質,自行安裝,並在工程部署成功後手動對接 | 1)維運平台部署的專案中,自帶各類組件,支援一鍵部署 2)使用者也可自行準備各類高可用組件,在部署專案時接入 | |
專案部署 | 埠檢查 網路檢查 | 無法在安裝專案時指定工程埠 只能在專案部署成功後,手動修改 如埠被佔用、無法連通,也需手動排查 | 在部署專案時,支援修改各個組件的佔用埠 對於各個組件的埠占用和網路連通情況進行檢查和提示 |
權限檢查 | 只確定可以上傳檔案,但對啟動工程的伺服器使用者權限無法進行檢測 可能會因為權限不足,導致工程運作/功能使用存在問題 | 在部署專案時,對所用使用者的權限進行檢查和提示 防止因為使用者權限步驟,導致運作/功能異常 | |
參數配置 | 對於容器配置、JVM參數、glibc、各項記憶體等,不會進行配置 一般都在工程出現問題後,才會進行排查調整,存在滯後性 | 維運平台使用的鏡像中,已經配置好了這些常用參數 | |
工程部署 | 需要使用終端遠端伺服器,進行檔案上傳、解壓和運作 | 透過維運平台,介面視覺化完成部署全部操作 | |
工程註冊 | 提供多種註冊方案,需要根據環境選擇 不合適的註冊方案,可能會在工程重啟或網路情況出現變化後失效 | 介面化進行容器私有雲認證,簡單快捷不失效 | |
專案維運 | 工程升級 | 需要手動更換JAR包,手動啟停 如升級失敗,無法回滾,需要自行手動再更換 | 介面化更換鏡像包實現升級 升級前備份,升級失敗支援快速回滾 |
工程備份 | 僅支援備份關鍵配置、JAR包、插件等 其他內容需要使用者自行手動備份 | 支援一鍵備份,支援自動備份 支援將專案備份到維運平台所在伺服器,實現異地備份 包括:工程組件、配置組件、叢集組件、依賴鏡像 | |
工程還原 | 僅支援在工程啟動的情況下使用平台還原功能 如工程無法啟動,需要手動更換檔案進行還原 | 支援透過維運平台,介面視覺化完成還原操作 支援在專案不可用的情況下對工程進行還原 若存在不可用伺服器,支援在還原時重新指定新節點 | |
工程維運 | 不提供相關功能/作用範圍小 | 支援且不限於: 集中專案健康管理 快速排查故障問題 快速定位效能問題 自動監測與警報 |
finekey、維運平台、維運專案之間的關係是什麼?
產品/功能 | 說明 |
---|---|
finekey與維運平台 | 一鍵部署CLI工具 1)初始化部署環境:搭建docker環境、處理容器網路 2)部署維運平台:透過finekey自帶的鏡像/雲端拉取鏡像,來部署維運平台 3)內網升級維運平台:內網環境下的維運平台無法直接從雲端拉取鏡像,因此需要藉助離線版finekey更新鏡像 |
維運平台與維運專案 | 帆軟專案的全方位維運管理工具 1)部署、對接單機/叢集的維運專案,包括FineReport、FineBI、FineDataLink 2)部署的維運專案中,不僅僅包括工程,還包括配套的外接配置庫、叢集組件、維運組件等 3)一個維運平台支援對接管理多個維運專案 4)對於接入的維運專案,維運平台可以對其進行啟停、註冊、升級、巡檢、監視、警報等全方位維運操作 |
單節點應用與多節點叢集
單節點應用
就是一個部署好的工程。
多節點叢集
叢集(cluster)就是將多個相同的工程集中起來提供同一種服務,這些單個的工程就是叢集的節點(node)。
基於叢集的橫向擴展性,使用者可透過增加節點數量使併發趨於線性增長,進而獲得較高的併發支撐效能。
同時也可以用多個工程做備份,避免單機不可用導致系統停止造成的損失(業務中斷、資料/範本丟失),確定系統 7*24h 穩定運作。
叢集的優勢
帆軟叢集具有高可用性、高效能、易於管理、可伸縮性和安全保障等優點,適用於企業級的報表生成和管理需求。
可以幫助企業更好地管理和控制報表資料的儲存、生成、共享等方面的效能和效果。
優勢 | 說明 |
---|---|
高可靠性 | 帆軟叢集透過叢集節點、負載均衡器、狀態伺服器等多個組件協同工作,有多個節點來分擔處理請求的負荷。 當叢集節點發生故障時,負載均衡器會自動將請求轉發到其他可用節點,保證系統的高可靠性。 |
高併發 | 帆軟叢集允許平行處理多個儀表板生成和資料計算任務,透過多個節點進而實現任務的分散式處理。 透過叢集的橫向擴展,實現資料計算與儀表板生成的加速,進而提高整體的效能。 節點數量越多,支援的併發越高。 |
易於管理 | 帆軟叢集提供了完整的管理平台,包括叢集節點的監視、配置、部署和故障自動修復等功能,可以大大降低叢集維護和維運的難度和風險,幫助企業更好地管理和維護系統。
|
強擴展性 | 基於良好的架構設計,Web叢集具有良好的橫向擴展性,帆軟叢集可以快速增加叢集節點的數量,使併發趨於線性增長,以應對高峯期和流量波動,做到系統的可伸縮性和高效性。 |
叢集和單機的差別/叢集解決什麼問題?
當我們把叢集和單機比作一組出租車承接客人的話,它們的差別可以這樣解譯:
1)解決高負載問題
單機就像是一輛出租車,它可以接受乘客的訂單,但是如果訂單請求變得非常多,該出租車的服務能力可能無法滿足,並可能會出現效能瓶頸。
此時,你需要多輛出租車來分擔訂單處理工作。而這些出租車可以被組成為一個出租車隊的形式稱之為叢集。
這樣,您可以將乘客分配到不同的車輛中,並將他們同時送到目的地,進而提高服務效率。
2)解決高可靠問題
但是,僅僅增加車輛的數量只能解決工程高負載問題,並不足以保證高可靠性。
您還需要一個良好的車隊管理系統來確定每輛車都可以順利地運作,並提供相同的服務品質和客戶體驗。
在叢集設計中,這意味着您需要將多個伺服器組合在一起,以實現負載均衡、配置資訊資料庫、狀態伺服器和檔案伺服器等功能。
這些組件可以確定整個叢集的高可靠性,並提供穩定的服務。
3)總結
叢集和單機的主要差別在於共享資源和協作工作。
叢集中,多個工程相互通訊共享資料和任務,可以提供更好的可延伸性和更高的效能。
單機中,所有的資源都被獨佔使用,沒有擴展性和動態性可言。
總之,叢集設計是一種有效的解決方案,可以提高系統的負載能力和可用性,並確定系統的穩定性和一致。
叢集為什麼需要多類組件?
在搭建叢集時,需要注意到這不是一件輕鬆簡單的事情。
為了提供無縫絲滑的服務,必須提高服務品質並組建一個優秀的車隊。
我們需要考慮如何構建一個良好的車隊,這是叢集架構需要解決的問題。
組件 | 說明 |
---|---|
工程節點 | 叢集節點就是一輛輛出租車。 當某個出租車出現了故障,會自動安排其他出租車來代替它的工作,以確定整個車隊仍然正常工作。 帆軟叢集設計避免了主節點的概念,只將第一個加入叢集的節點作為基準節點。每個節點都平等地提供服務和進行管理操作。 每個節點都是一個可以獨立運作的工程,負責處理使用者的請求,處理生成報表的任務和管理其他組件的工作。叢集節點間透過一系列的網路協定和服務進行通訊和協作。 |
負載均衡 | 負載均衡就像出租車隊的調度中心,用於協調和分配所有的工作和請求。 在接待客戶時,負載均衡作為統一入口,負責對接客戶,不需要讓客戶一個個查詢司機。 在叢集中,負載均衡用於分配任務到各個節點上,使它們能夠更高效地工作。 負載均衡器會在所有節點之間平衡負載,確定每個節點都分配到足夠的任務並保持忙碌狀態。 |
外接資料庫 | 配置庫,即外接資料庫FineDB,類似於出租車隊的車管所。 它儲存並維護所有車輛和司機的資訊,為每個司機提供相同的車輛裝飾、報價、出行路線等資訊。讓每一輛車都給顧客提供一致的出行體驗。 在叢集中,配置庫用於儲存和維護所有節點的配置資訊和參數,這些參數是為了使叢集節點協調工作而必須合理設定的。 |
狀態伺服器 | 狀態伺服器就像出租車隊的管理中心。 它負責監視和維護車隊的整體狀態,包括車輛和司機的位置,以及服務進度。 在叢集中,狀態伺服器也執行相似的任務。它監視每個節點及整個叢集的運作狀態、記錄日誌和錯誤資訊、協調節點間的通訊和任務分配等。 |
檔案伺服器 | 檔案伺服器類似於出租車隊的儲存倉庫。 它儲存所有與車隊相關的檔案,包括車輛維護記錄、保險單、車輛位置資料等。 在叢集中,檔案伺服器用於儲存和共享叢集中所需的檔案和資料資源,以確定每個節點都可以存取並使用它們。 |