瞭解FineBI6.1部署原理

  • 最後修改時間:2024-11-11
  • 概述

    本文簡單介紹:

    1)FineBI6.1架構簡介

    2)FineBI6.1的優勢說明

    FineBI6.1工程架構

    架構一覽


    組件一覽



    負載均衡網關

    作用:

    負載均衡網關,處於用戶端和bi-web組件之間

    它負責接收用戶端的請求,並將這些請求分發到bi-web組件上

    因此負載均衡必須要能存取每一個bi節點

    優點(為什麼需要負載均衡?為什麼不能直接用戶端到bi?):

    效能優化:智慧分配請求到各個bi節點,防止伺服器過載,提升效率

    故障隔離:自動檢查並排查故障bi節點,避免影響整體服務

    安全增強:作為第一道防線,過濾和監視流量,防止惡意攻擊

    對話保持:負載均衡網關支援配置對話保持策略,確定使用者請求連續性,保持對話狀態

    可延伸性:用戶端只需要知道負載均衡網關地址,隨業務增長,增加bi節點不影響客戶存取地址

    類型:

    帆軟項目內網關,對帆軟業務進行了客製調整,以均衡的分發使用者請求,提升效能,因此不支援自備

    如需使用F5、SLB、ELB等其他類型的負載均衡網關,可以自行配置轉發,讓用戶端請求轉發到自備網關,再轉發到帆軟項目內網關,再分發到各個bi節點上

    bi節點

    bi節點,切分為兩層:網路轉發層、業務處理層

    網路轉發層(怎麼確定單個使用者的業務,能被同一個節點連續的處理掉?):

    由於可能存在多個bi節點,必須確定單個使用者的請求能被同一個bi節點持續處理,因此在用戶端與bi節點建立連結時,會生成一個唯一的session ID

    後續該用戶端的請求無論被轉發到了哪個bi節點,都可以根據session ID識別,並將請求轉發到首次接待的bi節點,以保持對話狀態,確定服務的一致

    業務處理層:

    用於處理用戶端的請求,包括平台的功能、前端介面渲染等。

    在處理請求的程式中,如果涉及到資料更新或計算,這些任務將被智慧分配給後端引擎worker

    引擎master

    引擎master,有兩個作用:儲存和提供worker資訊、儲存元資料

    儲存和提供worker資訊(bi節點的任務是直接分配到worker的嘛?答案:是,但不完全是):

    bi節點需要進行資料更新和計算時,任務會被智慧分配給引擎worker來執行。

    但是,引擎worker是無狀態服務,這意味着它們不負責儲存任何持久化的資料(可以想象成worker沒有固定的"身分證"),因此bi節點無法直接識別或聯絡到任何一個引擎worker。

    此時,bi節點會先與引擎master進行通訊,引擎master負責動態地為bi節點提供一個可用的worker地址,這個地址是隨機分配的,專門用於完成當前的任務。

    一旦bi節點從引擎master獲取到了引擎worker的地址資訊,它就能夠將任務順利地分發給相應的引擎worker,確定資料處理和計算工作的順利進行。

    儲存元資料(worker是怎麼從資料儲存組件裏取數的?)

    元資料,也就是每個bi資料表的資訊(並非bi資料表中的資料),比如bi某個資料表的表名稱、欄位名、儲存在資料儲存組件的哪個位置

    這些元資料儲存在master組件的掛載目錄下,即儲存在伺服器磁碟裏

    當worker需要從資料儲存組件取數計算/更新資料時,需要先找master得到這些資料表的元資料,然後worker才能正確的找到所需要的各個表,並完成工作

    引擎worker

    worker分為兩個部分:探活monitor和引擎worker

    引擎worker:

    用於執行bi節點分發的資料更新和計算任務。

    預設情況下,每個引擎worker既可以執行資料更新,也可以執行資料查詢計算任務

    什麼是讀寫分離?什麼情況下配置?

    正式業務系統,往往白天工作時間進行業務資料查詢計算,夜晚下班時間進行資料更新。

    那麼在白天如果有資料更新,不能佔用查詢的資源;在夜晚如果有資料計算,不能佔用更新的資源。

    此時可以對引擎worker進行屬性配置,讓部分節點在指定時間段內專注進行某一件事(即讀寫分離)

    探活monitor(為什麼master和worker的重啟有順序要求?

    worker會定期(3秒)向引擎master傳送心跳信號,讓master知道該worker仍然存活。

    如果沒有正常匯報,此時master就會認為這個worker出現了故障,需要重啟。

    master會向monitor傳送任務,讓他執行kill指令強制關閉worker,再關閉monitor自身。

    此時worker自身的機制就會被觸發,自動重啟這個引擎worker。

    因此如果需要重啟master,master重啟成功後,必須重啟所有worker,否則master將無法判斷worker是死是活

    資料儲存

    用來儲存FineBI中抽取的基礎表和自助資料集資料

    注意,資料儲存組件中不包括以下資料:

    Excel資料集:相關檔案儲存在檔案伺服器的/WEB-INF/assets/temp_attach資料夾中

    直連資料:直連相關快取資料,由伺服器記憶體+磁碟共同儲存

    配置庫

    配置庫,也就是老版本所說的finedb,用來儲存工程中的一些配置信息。

    比如工程裏有哪些使用者,有哪些目錄,使用者有什麼權限,資料更新任務什麼時候執行。

    這些配置資訊單獨存放在一個資料庫裏,與工程時刻對接,確定了工程長久穩定的運作。

    這也就是配置庫為什麼必須一個項目用一個,為什麼不能多個項目共用?會導致配置混亂。

    舉個例子:

    一個多bi業務節點的叢集,無論從負載均衡入口進入工程,還是從某個節點存取,都會看到同樣的平台風格,看到同樣的目錄。因為每一個節點,都是從配置庫中讀取相關資訊,然後進行展示。

    狀態服務狀態伺服器是一個監視,它監視每個節點及整個BI項目中各個組件的運作狀態、記錄日誌和錯誤資訊、協調節點間的通訊和任務分配等。

    舉個例子:

    當使用者在A節點處於登入狀態,正常處理業務。但此時A節點當機了,業務轉移到B節點處理,此時B節點怎麼知道這個使用者在當前電腦處於登入狀態?這就依賴狀態服務判斷,這些資訊都儲存在redis裏

    檔案服務

    檔案伺服器用於儲存和共享叢集中所需的檔案和資料資源,以確定每個bi節點都可以存取並使用它

    此處列舉下一些檔案,即可理解檔案伺服器的作用:

    FineReport範本檔案

    FineReport範本備份檔案

    FineBI的Excel原始檔案資訊

    驅動管理上傳的驅動

    工程資源檔案(地圖、圖片)

    排程管理生成的快照檔案

    雲端健檢分析生成的資料包

    工程歷史備份檔案

    日誌服務

    日誌服務,是用於記錄每一位使用者在系統中的每一次操作,包括登入、存取資料、修改記錄等

    對於FineBI6.1,ElasticSearch組件取代了原有的Swift引擎,提供日誌服務

    為什麼需要日誌:

    溯源追蹤:能夠確定系統操作的透明性和可追溯性,這對於審核和合規性檢查非常重要

    效能分析:記錄系統的運作情況和效能資料,幫助分析和評估系統的效能瓶頸

    行為分析:瞭解使用者的行為習慣和使用模式,幫助改進系統功能和使用者體驗

    FineBI6.1對比老版本有何優勢?


    6.0/5.x
    6.1存算分離
    穩定性提升

    計算引擎和bi業務在同一個進程中,使用者存取跟查詢更新互相影響,當機之後整個服務當機,使用者可感知

    引擎服務與bi業務服務剝離拆分

    引擎拆分為獨立進程,引擎當機時業務使用者無感知

    引擎支援自動重啟,可以在分鐘級別快速重啟

    多個引擎節點下,滿足真正高可用需求

    可延伸性提升

    5.x版本:

    抽取資料需要透過插件實現主備叢集,無法高可用

    只支援本地磁碟儲存,不能滿足使用者個性化儲存需求

    6.0.x版本:

    最多支援5個業務節點,叢集擴展節點受限

    只支援本地磁碟儲存,不能滿足使用者個性化儲存需求

    增加統一資料存取層,將計算引擎與資料儲存分離,突破了歷史多節點叢集,本地抽取資料,持久化同步的瓶頸

    計算引擎突破節點數限制,支援橫向擴展,資料查詢併發線性提升,可滿足高併發查詢的使用者群體

    抽取資料支援使用雲OSS儲存,持久化資料不落地,滿足企業資料安全需求

    效能提升

    日常維運複雜

    • 非容器化部署,工程啓停、獲取日誌、查看監視系統記憶體CPU使用情況等都需要在後台執行命令操作

    • 整個工程資源使用情況缺少監視預警手段(只有插件功能在前端能夠看到記憶體、CPU使用情況)

    磁碟用量緊張

    • 5.1.X 主節點會將抽取資料無盡同步到備節點伺服器上,主備兩個伺服器都需要準備很大的磁碟空間來儲存抽取資料

    • 6.0.X 節點內部會進行抽取資料同步,每個同步節點伺服器都需要準備一個很大的磁碟來儲存抽取資料

    日常維運操作簡單化

    FineBI 基礎維運操作,均可透過維運平台前端視覺化完成。如工程啓停、下載日誌、生成堆疊dump等,有效降低一部分維運成本

    磁碟空間釋放

    取消多節點同步儲存抽取資料,只需要持久化一份資料在資料儲存組件,即可確定多個引擎節點呼叫

    FineBI6.1為什麼使用容器化部署?

    優勢
    說明
    一致
    • 環境一致:容器將應用及其依賴關係打包,確定無論在開發、測試還是生產環境中,應用都能保持一致,避免出現由於環境因素引發的各種疑難問題

    隔離與安全
    • 組件隔離:每個容器都是一個獨立的運作環境,進程相互隔離,提高了安全性,避免了不同應用之間的干擾

    • 資源合理分配:可以為每個容器配置資源限制(如CPU、記憶體),進而確定資源的合理分配

    簡化維運
    • 簡化維運管理:容器的啓停和管理透過維運平台實現自動化,簡化維運任務

    • 更好的可觀察性維運平台提供日誌和監視解決方案,可以方便地觀察和分析容器的運作狀態,提前識別效能當機風險

    快速故障恢復
    • 故障容許度能力:worker的進程可以自動重啟,其他服務遇到故障時也可以透過維運平台快速啟動恢復


    附:容器化技術介紹

    如果將 Linux 比作一個廚房,那麼Docker技術就像是預製菜品

    廚房可以從中央廚房(雲鏡像倉庫)訂購真空包裝的食品(鏡像),並儲存在自己的冰櫃中(本地鏡像倉庫)。

    廚師(維運人員)可以將這些預製的真空包裝食品(鏡像)經過簡單的操作變成一道道菜品(容器),供顧客“享用”(服務)。

    Docker的三大特色

    1)鏡像(Image):類似於一個安裝包,透過這個安裝包來建立容器。

    2)容器(Container):利用容器技術,獨立運作一個或一組應用,可以透過鏡像建立多個容器。容器可以理解為一個簡易的Linux系統。

    3)倉庫(Repository):存放鏡像的地方,分為公有倉庫和私有倉庫,如Docker Hub、阿里雲、Harbor等。

    透過Docker,企業可以實現更加高效和靈活的系統管理,提升服務的穩定性和可維護性。

    附件列表


    主題: 部署帆軟專案
    已經是第一篇
    已經是最後一篇
    • 有幫助
    • 沒幫助
    • 只是瀏覽