本文簡單介紹：
1）FineBI6.1架構簡介
2）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引擎，提供日誌服務 為什麼需要日誌： 溯源追蹤：能夠確定系統操作的透明性和可追溯性，這對於審核和合規性檢查非常重要 效能分析：記錄系統的運作情況和效能資料，幫助分析和評估系統的效能瓶頸 行為分析：瞭解使用者的行為習慣和使用模式，幫助改進系統功能和使用者體驗 |
| 6.0/5.x | 6.1存算分離 | |
|---|---|---|
| 穩定性提升 | 計算引擎和bi業務在同一個進程中，使用者存取跟查詢更新互相影響，當機之後整個服務當機，使用者可感知 | 引擎服務與bi業務服務剝離拆分 引擎拆分為獨立進程，引擎當機時業務使用者無感知 引擎支援自動重啟，可以在分鐘級別快速重啟 多個引擎節點下，滿足真正高可用需求 |
| 可延伸性提升 | 5.x版本： 抽取資料需要透過插件實現主備叢集，無法高可用 只支援本地磁碟儲存，不能滿足使用者個性化儲存需求 6.0.x版本： 最多支援5個業務節點，叢集擴展節點受限 只支援本地磁碟儲存，不能滿足使用者個性化儲存需求 | 增加統一資料存取層，將計算引擎與資料儲存分離，突破了歷史多節點叢集，本地抽取資料，持久化同步的瓶頸 計算引擎突破節點數限制，支援橫向擴展，資料查詢併發線性提升，可滿足高併發查詢的使用者群體 抽取資料支援使用雲OSS儲存，持久化資料不落地，滿足企業資料安全需求 |
| 效能提升 | 日常維運複雜
磁碟用量緊張
| 日常維運操作簡單化 FineBI 基礎維運操作，均可透過維運平台前端視覺化完成。如工程啓停、下載日誌、生成堆疊dump等，有效降低一部分維運成本 磁碟空間釋放 取消多節點同步儲存抽取資料，只需要持久化一份資料在資料儲存組件，即可確定多個引擎節點呼叫 |
| 優勢 | 說明 |
|---|---|
| 一致 |
|
| 隔離與安全 |
|
| 簡化維運 |
|
| 快速故障恢復 |
|
如果將 Linux 比作一個廚房，那麼Docker技術就像是預製菜品。
廚房可以從中央廚房（雲鏡像倉庫）訂購真空包裝的食品（鏡像），並儲存在自己的冰櫃中（本地鏡像倉庫）。
廚師（維運人員）可以將這些預製的真空包裝食品（鏡像）經過簡單的操作變成一道道菜品（容器），供顧客“享用”（服務）。
Docker的三大特色1）鏡像（Image）：類似於一個安裝包，透過這個安裝包來建立容器。
2）容器（Container）：利用容器技術，獨立運作一個或一組應用，可以透過鏡像建立多個容器。容器可以理解為一個簡易的Linux系統。
3）倉庫（Repository）：存放鏡像的地方，分為公有倉庫和私有倉庫，如Docker Hub、阿里雲、Harbor等。
透過Docker，企業可以實現更加高效和靈活的系統管理，提升服務的穩定性和可維護性。
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
9s后關閉
反馈已提交
网络繁忙
上一篇：FineBI產品優勢
