集群方案介紹

1.1 集群簡介

集群（cluster）就是将多個相同的工程集中起來提供同一種服務，這些單個的工程就是集群的節點（node）。基於集群的橫向擴展性，用戶可通過增加節點數量使并發趨於線性增長，從而獲得較高的并發支撐性能。

同時也可以用多個工程做備份，避免單機不可用導緻系統停止造成的損失（業務中斷、數據/模板丢失），确保系統 7*24h 穩定運行。

視頻鏈接：【集群原理介紹】   

1.2 集群架構

如下圖所示：

1.3 集群優勢

1）高可用性

• 無主機模式，某一節點宕機後集群系統仍可正常提供服務。

• 節點宕機後，自動切換其他節點，已登錄的用戶無需重新登錄。

2）高并發

同一個時間點，服務器響應了多個請求。比如 11:01:00 存在請求 A，11:01:03 服務器處理結束，如果 11:01:02 增加一個請求B、11:01:04 增加一個請求 C，此時的并發是 2（請求 A 和請求 B ）。

節點數量越多，支持的并發越高。由於并發是根據用戶的實際業務場景，查看模板和制作模板，占用的服務器資源是不一樣的。所以實際的服務器資源并發數量與業務使用情況有關，需要帆軟專業的性能測試，結合實際的網絡環境、文件讀寫效率、數據庫并發性能等因素，得出實際能夠支持的并發大小。

并發和容器沒有關系，比如 Tomcat 、WebLogic、WebSphere 容器，并發相差不大。

3）高一緻性

• 各節點間平台配置信息和資源文件修改更新能夠實時同步。
  

• 對於節點間JAR包不一緻情況，啓動時可自動檢測對比并提醒。

4）強擴展性

基於良好的架構設計，Web集群具有良好的橫向擴展性，通過增加節點數量使并發趨於線性增長，從而獲得較高的并發支撐性能。

5）使用簡單

• 簡單可視化配置，80% 的配置都可在平台上完成。
  

• 支持熱部署，增加删除節點無須重啓集群，只需要拷貝節點文件即可。

• 實時監控各節點的運行狀态，對於節點宕機、節點間時間不一緻等情況可以及時進行提醒。

帆軟集群方案對於 Windows 系統和 Linux 系統均能支持。但考慮到穩定性和性能情況，推薦選用 Linux 系統作爲服務器的操作系統。下面簡單介紹 Linux 系統作爲服務器操作系統對比：

1）穩定性

• Linux 系統穩定性極佳，大部分硬件和配置更新無需重啓。

• Linux 系統相對 Windows 系統，宕機機率更低，常常一年都不用關機。

2）性能優勢

• Linux 系統處理多線程比 Windows 要好的多，是真正的多用戶多線程，而 Windows 是單用戶僞多線程。

• Linux 系統不像 Windows 系統必備圖形化操作界面，因此占用資源會少一些，性能也更好。

• 内存管理和調度方式優秀，有效利用一切硬件資源。

但是影響我們最終哪種系統的因素，還有一個最關鍵的點——運維能力，如果公司不具備 Linux 系統的運維能力，那只能選擇Windows 系統了。

負載均衡分爲軟件負載均衡和硬件負載均衡，兩種負載均衡核心作用是一樣的，負載均衡作爲集群的入口，起到請求分發和節點健康檢查的作用。

注：不支持 Apache 負載均衡。

3.1 硬件負載均衡

硬件負載均衡很穩定，性能也相對較好，但是成本也高，最常用的負載均衡就是 F5 。若公司有硬件負載均衡且具備較好的配置和運維能力，确認硬件負載均衡具備主動健康檢查功能後，即可選擇使用硬件負載均衡。

簡單介紹一下硬件負載均衡的優缺點：

• 優點：能夠直接通過智能交換機實現,處理，而且與系統無關，負載性能強更适用於一大堆設備、大訪問量、簡單應用。

• 缺點：成本高，除設備價格高昂，而且配置冗餘．很難想象後面服務器做一個集群，但最關鍵的負載均衡設備卻是單點配置；無法有效掌握服務器及應用狀态。

使用文檔：負載均衡配置指導

3.2 軟件負載均衡

簡單介紹一下軟件負載均衡的優缺點：

• 優點：基於系統與應用的負載均衡，能夠更好地根據系統與應用的狀況來分配負載。這對於複雜應用是很重要的，性價比高，實際上如果只有幾台服務器，用 F5 之類的硬件産品顯然有些浪費，而用軟件就要劃算的多，因爲服務器同時還可以跑應用做集群（雖然不太推薦），或者僅提供一般配置的服務器來給負載均衡應用。

• 缺點：負載能力會受服務器本身性能的影響。

帆軟官方驗證過的軟件負載均衡有兩種：Traefik 和 Nginx，兩種均爲開源軟件，更新頻率和維護力度穩定，下面說一下兩個負載均衡的适用場景。

3.2.1 Nginx

Nginx 作爲負載均衡在 Linux 系統上具備很好的并發性能，并且占用極小的内存。許多大公司都在用，穩定性和性能是經過充分驗證的。但是在 Windows 系統上并不支撐較高并發，所以在 Windows 系統上選用 Nginx 作爲負載均衡，需要考慮并發情況，若并發需求低於 200，部署集群僅以熱備爲目的，則可選用 Nginx 作爲負載均衡，若并發需求超過 200 ，則不建議使用Nginx，須換用其他負載均衡。

如果希望 Nginx 層面也具備高可用性，避免單點故障，那麽可以再做一個 Keepalived+Nginx 方案，确保一個 Nginx 服務宕機或異常後，有備用的 Nginx 服務可以接手。

使用文檔：Linux 系統安裝配置 Nginx、Windows系統安裝配置Nginx、Keepalived+Nginx部署方案

3.2.2 Traefik

Traefik 是 Go 語言編寫的單一可執行文件，無需安裝，只要在命令行裏執行即可，部署和使用非常簡單，适用於對運維能力要求不高的用戶使用。和 Nginx 相比，有兩大優點：

• 在 Windows 系統上具備良好的性能，因此 Windows 系統推薦使用 Traefik 。

• 支持自動化更新反向代理和負載均衡配置。

使用文檔：windows系統安裝配置Traefik

Nginx 在 Linux 系統下的性能和穩定性、Traefik 在 Windows 系統下的性能和穩定性，帆軟都已經進行了測試和驗證。理論上Traefik 在 Linux 系統上也具備較好的性能，但是爲了避免方案的繁雜以及考慮維護成本，未對 Traefik 在 Linux 系統上的性能和穩定性做充分的驗證。

總的來說，Linux 系統推薦選用 Nginx 作爲負載均衡，Windows 系統不建議選擇 Nginx ，推薦選用 Traefik 。

Web容器是一種服務程序，是能夠支持發布Web程序的軟件，在服務器一個端口就有一個提供相應服務的程序，而這個程序就是處理從客戶端發出的請求。

常規推薦：Tomcat 容器、WebLogic 容器、WebSphere 容器。

帆軟集群方案裏，狀态服務器是用 Redis 實現的，常用的 Redis 方案有 Redis 單機、Redis 集群、Redis 哨兵三種，這裏對如何選擇三種方案進行介紹。

如果公司已有 Redis 服務，不管是下面哪一種，都可以直接使用，這樣可以減少額外維護一個應用的成本，但是如果沒有 Redis 服務，我們爲了使用集群，就要新安裝 Redis 服務了。

5.1 Redis單機

Redis 單機指的是只部署一個 Redis 應用，此種方案簡單易部署，運維成本低，能夠保證集群的可用性。

使用文檔：Linux 系統安裝配置單機 Redis

5.2 Redis集群

如果對於系統/方案的高可用性要求高，希望能夠避免單點故障，那麽 Redis 集群可以很好地滿足需求。

5.2.1 架構介紹

Redis 集群結構是 N 個平權主節點（master），每個主節點對應 M 個從節點（slave），由於 Redis 集群的投票機制，N 須爲奇數，且必須大於等於 3 ，否則創建集群時會失敗。

業界經過大量檢驗最常用的 Redis 集群架構是 3 主 3 從。

5.2.2 資源需求

部署 3 主 3 從的 Redis 集群時，建議至少主從 3 台服務器，主從節點在構建 Redis 集群時會進行随機分配。

如果想要達到更加極緻的高可用，避免主節點和從節點剛好分配到一台機器并且遇到服務器宕機導緻整個 Redis 集群不可用的情況發生，可以準備 6 台服務器來做 3 主 3 從的 Redis 集群，這樣任何一台服務器宕機都不會影響 Redis 集群對外提供服務。

5.2.3 優缺點說明

優點：

• 主節點宕機後，基於投票機制從節點可自動上升爲主節點，可讓 Redis 服務更加高可用。

• 數據分區存儲在不同的主節點上，可以大幅度提升 Redis 服務的性能支撐。

缺點：

• 由於數據分區存儲，所以當一個主節點及其對應的從節點全部宕機後，整個 Redis 集群将不能使用。

• 當存活的主節點數小於總節點數的一半時，整個 Redis 集群也會無法提供服務。

• 不管是 3 台服務還是 6 台服務器，我們都能感受到 Redis 集群對資源的要求是比較多的，且運維成本也會比 Redis 單機更高。

使用文檔：linux系統安裝配置Redis集群

簡單總結，Redis 集群方案可以讓 Redis 服務更加高可用，但是運維和資源成本更高，建議選擇時仔細考慮。

5.3 Redis哨兵

5.3.1 架構介紹

Redis 哨兵模式是基於 Redis 主從模式的方案，Redis 2.8 及以後版本提供了哨兵工具來實現自動化的系統監控和故障恢複功能。哨兵的作用就是監控 master、slave 是否正常運行，master出現故障後自動将 slave 轉換爲 master。

建議至少使用 2 個哨兵（因爲哨兵模式中将主服務器判斷爲失效至少需要 2 個 Sentinel 同意，所以至少要部署兩個及以上的Sentinel ），

最常用的 Redis 哨兵方案爲 1 主 2 從 3 哨兵，能夠做到較好的高可用。

5.3.2 資源需求

可以将主節點、從節點、哨兵節點部署在一台或多台服務器上，但是和 Redis 集群一樣，如果我們想要達到極緻的高可用，避免一台服務器宕機就導緻整個 Redis 服務不可用，那麽就把每個節點部署在一個獨立的服務器上。

5.3.3 優缺點說明

優點：

• 主從可以自動切換，故障可以轉移，系統可用性更好。

• 哨兵模式是主從模式的升級，系統更健壯，可用性更高。

缺點：

• 不能支持高并發，能提供寫入功能的也就只有主節點。

簡單總結，Redis 哨兵模式也可以讓 Redis 服務更加高可用，但是也是比較耗費運維和資源的，而且與 Redis 集群相比最大的缺點就是性能和單機一樣，無法提升 Redis 服務的性能。

集群一緻性裏有一個很關鍵的點就是文件一緻性，帆軟提供了多種方案來保障節點間資源文件的一緻性。我們可以基於運維能力，實際場景來進行選擇。

注：「節點間自動同步」不适用於多節點，否則會因節點間通信問題影響使用，建議僅兩個節點時使用，大於兩個節點時最好使用「文件服務器」。

6.1 節點間同步

節點間同步是保障節點間資源文件一緻性的最簡單的方案了。

優點：

• 無須開啓文件服務器，無須做任何配置即可使用，無運維成本，使用成本很低。

• 各個節點均存儲有文件，因此可以達到熱備的效果，具備高可用性。

缺點：

• 節點間同步方案不适用於多節點，建議僅在使用兩節點時選用節點間同步方案，因爲節點越多，由於通信和同步效率等原因，可能會同步失敗或者由於同步不及時影響使用。

簡單總結，節點間自動同步的方案能夠滿足雙機熱備的需求，運維和使用成本很低，無須額外維護組件，但是不适用於多節點，建議僅在兩個節點時選用。

注：10.0.5 版本即 2020-04-26 發布的10.0 中已經可以滿足節點間能夠同步空文件夾，且從 Nginx 入口進行遠程設計不會出現文件夾消失的情況。

6.2 文件服務器

帆軟支持多種文件服務器，下面會對各個類型的文件服務器優缺點進行說明。

6.2.1 共性優缺點

先說明一下文件服務器共性的優缺點，共性優缺點指不管選擇哪種文件服務器，都具備的。

優點：

• 文件一緻性高，由於各個節點都是從同一個文件服務器讀取資源文件，不涉及到同步，各個節點讀取的資源文件永遠會保持一緻性。

• 适用於多節點、超多節點的場景。

缺點：

• 使用成本比節點間同步高，由於額外使用一個組件，導緻部署運維成本會略高一些，需要更多的資源支撐這些組件。

6.2.2 特性優缺點

使用文檔：Linux 系統安裝配置 FTP、Windows系統配置FTP服務、Linux 系統配置使用 SFTP、HDFS 資源倉庫

總結一下，當我們有超過2個節點時，爲了保證各個節點文件的高一緻性，建議使用文件服務器。基於高可用性、性能需求，以及公司實際的情況（是否已有文件服務器），再選擇對應的文件服務器。

2019-11-08 号的 JAR 包增加了緩存模式，前端可進行選擇，緩存和文件服務器搭配使用時可以增加文件服務器的高可用性，下面介紹一下如何選擇。

7.1 緩存功能

緩存的資源文件：包含報表文件、儀表板文件、配置文件、地圖數據等，目前是"reportlets/" ,"resources/", "assets/"，"dashboards"四個文件夾。

主動緩存：緩存所有資源文件。

被動緩存：僅對訪問到的資源文件進行緩存。

7.2 緩存作用

優點：

• 提高文件服務器的高可用性，若使用文件服務器時開啓了緩存，當文件服務器宕機時，系統從緩存中讀取資源文件，仍可正常對外提供服務。

• 提高工程的性能，無法充分從節點下或者文件服務器中讀取文件，可大幅提高模板的訪問性能。

缺點：

• 緩存會占用系統内存資源。

總結一下，開啓緩存功能可以大幅提高工程的性能，并且配合文件服務器使用時，可提高系統的高可用性，建議使用文件服務器時開啓緩存。

外置數據庫在集群方案裏也是很關鍵的點，由於各個節點均使用同一個外置數據庫，因此節點間的配置可以保持一緻性。 FineReport 和 FineBI 對常用的數據庫都可以支持，包括 MySQL 、SqlServer、Oracle、DB2，這裏不作詳細介紹。若公司已有數據庫服務，數據庫版本符合帆軟的要求則可直接使用，若需要新部署數據庫服務，則建議部署mysql，部署比較簡單。

使用文檔：配置外接數據庫

帆軟集群支持 TCP 和 UDP 兩種通信協議，目前默認是 TCP 協議，下面列舉兩種協議的區别：

其中需要注意的是，大部分雲服務器（阿裏雲、亞馬遜雲等）都不支持UDP協議，因此只能選擇TCP協議。

若服務器對TCP/UDP協議均支持，當節點數較少時選擇TCP/UDP協議差異不大， 當節點數較多時，建議選擇UDP協議，通信效率更高。