對(duì)于用戶量較大的系統(tǒng)以及系統(tǒng)穩(wěn)定性要求極高的企業(yè)，每一次計(jì)劃外的系統(tǒng)停機(jī)都是嚴(yán)重事故。想要降低計(jì)劃外系統(tǒng)停機(jī)的概率，有兩個(gè)關(guān)鍵動(dòng)作，一是執(zhí)行計(jì)劃內(nèi)維護(hù)來及時(shí)更新硬件或者軟件，另外一個(gè)有效的動(dòng)作就是搭建一套高可用系統(tǒng)來降低系統(tǒng)意外停機(jī)的概率。

[[287044]]

隨著企業(yè)用戶對(duì)集群方案需求的多樣性提升、系統(tǒng)環(huán)境的復(fù)雜度增加，為了進(jìn)一步滿足企業(yè)用戶的需求，帆軟全新web集群方案就顯得很重要。截止今天已經(jīng)有140余家帆軟客戶選擇使用web集群方案來提升系統(tǒng)的高可用性。

既然上面提到我們可以滿足客戶多樣性、復(fù)雜性的需求，今天就給大家介紹一下如何選擇集群方案，來量身打造一套適合企業(yè)的高可用性系統(tǒng)。

什么是集群和分布式?

想要深入了解一個(gè)東西，概念和基礎(chǔ)知識(shí)很重要，我給你用大白話講明白。

小飯店原來只有一個(gè)廚師，切菜洗菜備料炒菜全干。后來客人多了，廚房一個(gè)廚師忙不過來，又請(qǐng)了個(gè)廚師，兩個(gè)廚師都能炒一樣的菜，兩個(gè)廚師的關(guān)系是集群。

為了讓廚師專心炒菜，把菜做到極致，再請(qǐng)了個(gè)配菜師負(fù)責(zé)切菜，備菜，備料 ... 廚師和配菜師的關(guān)系是分布式。

一個(gè)配菜師也忙不過來了，又請(qǐng)了個(gè)配菜師，兩個(gè)配菜師關(guān)系是集群。

一個(gè)配菜師因故請(qǐng)假了，但是其余的配菜師還是該啥就干啥，只是沒請(qǐng)假的配菜師任務(wù)均勻的加量了，但他們的任務(wù)和職責(zé)是不變的，這是集群。

• 集群：多個(gè)人在一起作同樣的事
• 分布式 ：多個(gè)人在一起作不同的事

正式介紹之前，先說一點(diǎn)基礎(chǔ)知識(shí)：帆軟的web集群架構(gòu)負(fù)載均衡+狀態(tài)服務(wù)器+文件服務(wù)器/節(jié)點(diǎn)間同步+外置數(shù)據(jù)庫(kù)，支持的組件比較多樣化，我們可以針對(duì)不同場(chǎng)景進(jìn)行選擇和搭配。

第一步：選擇操作系統(tǒng)

帆軟web集群方案對(duì)Windows操作系統(tǒng)、Linux操作系統(tǒng)均能支持，如果企業(yè)還在考慮選擇什么樣的操作系統(tǒng)，這里推薦大家選擇Linux操作系統(tǒng)，有兩個(gè)關(guān)鍵：性能和穩(wěn)定性。

• Linux系統(tǒng)處理多線程比Windows要好的多，而且不像Windows系統(tǒng)必備圖形化操作界面，因此占用資源會(huì)少一些，性能也更好;
• Linux系統(tǒng)穩(wěn)定性很好，大部分硬件和配置更新無需重啟;相對(duì)Windows系統(tǒng)，宕機(jī)機(jī)率更低，常常一年都不用關(guān)機(jī);

但是影響我們最終哪種系統(tǒng)的因素，還有一個(gè)最關(guān)鍵的點(diǎn)——運(yùn)維能力，如果公司不具備Linux系統(tǒng)的運(yùn)維能力，只能選擇Windows系統(tǒng)了。

第二步：選擇負(fù)載均衡

負(fù)載均衡作為集群的入口，起到請(qǐng)求分發(fā)和節(jié)點(diǎn)健康檢查的作用。不管是軟件負(fù)載均衡，還是硬件負(fù)載均衡，核心作用都是一樣的。

硬件負(fù)載均衡穩(wěn)定，性能也較好，但是采購(gòu)和維護(hù)成本都比較高。軟件負(fù)載均衡性價(jià)比高，像我們常用的Nginx、Traefik都是開源免費(fèi)的，許多超大型的企業(yè)也在使用，可用性得到了有效的驗(yàn)證。

帆軟官方驗(yàn)證過的軟件負(fù)載均衡有兩種：Treafik和Nginx，Linux系統(tǒng)推薦選用Nginx作為負(fù)載均衡，Windows系統(tǒng)推薦選用Treafik。如果希望負(fù)載均衡層面也具備高可用性，避免單點(diǎn)故障，可以再做一個(gè)Keepalived+Nginx方案，確保一個(gè)Nginx服務(wù)宕機(jī)或異常后，有備用的Nginx服務(wù)可以接手。

第三步：選擇Redis方案

帆軟集群方案里，狀態(tài)服務(wù)器是用Redis實(shí)現(xiàn)的，常用的Redis方案有Redis單機(jī)、Redis集群、Redis哨兵三種。Redis單機(jī)方案簡(jiǎn)單易部署，運(yùn)維成本低。但是如果希望Redis服務(wù)也達(dá)到高可用性，就需要選擇Redis集群或者Redis哨兵方案了。

Redis集群是官方推薦方案，既能夠保證Redis服務(wù)的高可用性，又因?yàn)閿?shù)據(jù)是分區(qū)存儲(chǔ)在不同的主節(jié)點(diǎn)上，可以大幅度提升Redis服務(wù)的性能支撐。不足之處就是運(yùn)維和資源成本相對(duì)Redis單機(jī)要高一些。

Redis哨兵模式是通過哨兵節(jié)點(diǎn)來實(shí)現(xiàn)自動(dòng)化監(jiān)控Redis主節(jié)點(diǎn)健康狀態(tài)，并提供故障恢復(fù)功能。最常用的Redis哨兵方案為1主2從3哨兵，能夠做到較好的高可用。缺點(diǎn)是不能支持高并發(fā)，能提供寫入功能的也就只有主節(jié)點(diǎn)。

注：FineReport和FineBI產(chǎn)品需要安裝Redis哨兵插件來對(duì)接Redis哨兵服務(wù)，插件還在測(cè)試階段，預(yù)計(jì)2020年2月份正式上線。

第四步：選擇文件一致性方案

集群一致性里很關(guān)鍵的點(diǎn)就是文件一致性，帆軟提供了多種方案來保障節(jié)點(diǎn)間資源文件的一致性。我們可以基于運(yùn)維能力，實(shí)際場(chǎng)景來進(jìn)行選擇。

• 節(jié)點(diǎn)間同步

節(jié)點(diǎn)間同步是保障節(jié)點(diǎn)間文件一致性的最簡(jiǎn)方案。無須開啟文件服務(wù)器，無須做任何配置即可使用。而且各節(jié)點(diǎn)均存儲(chǔ)文件，具備高可用性。不過節(jié)點(diǎn)間同步方案建議僅在兩節(jié)點(diǎn)時(shí)選用，因?yàn)楫?dāng)節(jié)點(diǎn)增多時(shí)，節(jié)點(diǎn)間通信和同步效率會(huì)逐漸變低。

• 文件服務(wù)器

當(dāng)使用文件服務(wù)器時(shí)，各個(gè)節(jié)點(diǎn)都從同一個(gè)文件服務(wù)器讀取資源文件，不涉及到節(jié)點(diǎn)間同步，因此各個(gè)節(jié)點(diǎn)讀取的資源文件永遠(yuǎn)會(huì)保持一致性，節(jié)點(diǎn)數(shù)較多的場(chǎng)景下建議使用文件服務(wù)器。常用的幾種文件服務(wù)器：FTP、SFTP、HDFS、NAS、NFS。

第五步：選擇緩存模式

2019年12月更新的jar包里增加了緩存模式，當(dāng)我們開啟集群時(shí)，可以選擇主動(dòng)緩存、被動(dòng)緩存、關(guān)閉緩存。主動(dòng)緩存就是直接緩存所有資源文件，被動(dòng)緩存是對(duì)訪問到的資源文件進(jìn)行緩存，開啟緩存可以提高文件讀寫的性能。

而且配合文件服務(wù)器使用時(shí)，可以提升集群的高可用性，因?yàn)楫?dāng)文件服務(wù)器宕機(jī)時(shí)，系統(tǒng)可以繼續(xù)從緩存文件中讀取資源。

第六步：選擇外置數(shù)據(jù)庫(kù)

外置數(shù)據(jù)庫(kù)在集群方案里也是很關(guān)鍵的點(diǎn)，由于各個(gè)節(jié)點(diǎn)均使用同一個(gè)外置數(shù)據(jù)庫(kù)，因此節(jié)點(diǎn)間的配置可以保持一致性。FineReport和FineBI對(duì)常用的數(shù)據(jù)庫(kù)都可以支持，包括MySQL、SqlServer、Oracle、DB2等。

若公司已有數(shù)據(jù)庫(kù)服務(wù)，數(shù)據(jù)庫(kù)版本符合帆軟的要求則可直接使用，如果想要保證數(shù)據(jù)庫(kù)的高可用性，還可以采用主從的數(shù)據(jù)庫(kù)部署方案。

讀完上面的內(nèi)容，相信你已經(jīng)知道了如何選擇一套符合自己企業(yè)的集群方案了。不過值得說明的是，世上沒有100%高可用的方案，不過我們通過選用完備的高可用方案，加上對(duì)系統(tǒng)定期運(yùn)維檢查和更新，是可以讓系統(tǒng)的高可用性盡可能地接近100%。