服務(wù)部署如何做到高可用?這份“三級(jí)跳”秘籍送給你
高可用部署要求
圖1 高可用部署
(*注:隨著服務(wù)滿足高可用要求的增多,服務(wù)的高可用能力就越強(qiáng))
一致性
這里的一致性指的是模塊依賴的方方面面,包括但不限于硬件規(guī)格和配置、操作系統(tǒng)、基礎(chǔ)軟件、系統(tǒng)參數(shù),還包括模塊自身的相關(guān)信息,如配置文件、版本、上下游依賴組件等的一致性。
可以通過配置管理工具(如Puppet)進(jìn)行管理和周期性維護(hù),確保配置始終如一。列舉一些不一致的問題,如CPU是否開啟超線程、內(nèi)存是否關(guān)閉SWAP、操作系統(tǒng)版本、JDK版本、內(nèi)核各種參數(shù)、文件系統(tǒng)類型以及模塊的配置等等,這些均可能對(duì)服務(wù)可用性造成嚴(yán)重影響,并帶來(lái)極大的問題定位成本。
消除單點(diǎn)
單點(diǎn)有兩種場(chǎng)景:一種是某個(gè)模塊僅部署了一個(gè)實(shí)例;第二種是某個(gè)模塊雖然部署了多個(gè)實(shí)例,但任意實(shí)例故障都會(huì)導(dǎo)致服務(wù)整體或者大面積不可用。
如何識(shí)別系統(tǒng)單點(diǎn)?通過排查模塊的實(shí)例數(shù)量和進(jìn)行破壞性測(cè)試來(lái)發(fā)現(xiàn)系統(tǒng)中是否存在單點(diǎn)。對(duì)于已知的單點(diǎn),則應(yīng)該盡量做好預(yù)案,減少故障時(shí)長(zhǎng)。
置放群組
要理解置放群組首先要理解故障域(Fault Domain)的概念。故障域指單個(gè)機(jī)房?jī)?nèi)由交換機(jī)或電源設(shè)備所造成故障的***影響范圍,通常為一個(gè)或一組機(jī)架。同一模塊需要盡可能的分散部署在不同的故障域中,避免由單一故障域異常而導(dǎo)致模塊整體不可用。
公有云下的置放群組就是為了提高業(yè)務(wù)的高可用性,在創(chuàng)建時(shí)將實(shí)例以某種策略強(qiáng)制打散,以降低底層硬件/軟件故障給業(yè)務(wù)帶來(lái)的影響。
舉例來(lái)說,一個(gè)模塊的所有實(shí)例絕不應(yīng)該部署在同一個(gè)接入交換機(jī)下,因?yàn)橐坏┻@個(gè)接入交換機(jī)故障,就會(huì)導(dǎo)致該模塊整體故障,而一個(gè)機(jī)房?jī)?nèi),有大量的接入交換機(jī),是完全可以避免這種悲劇的。
流量隔離
流量隔離是搭建多套同質(zhì)集群根據(jù)流量的屬性進(jìn)行分而治之的管理。常見的隔離策略主要基于流量的來(lái)源、重要性和資源消耗進(jìn)行隔離。舉例來(lái)說:
- 基于地域分為華北、華中、華南區(qū)域的用戶
- 基于硬件類型分為PC、APP等
- 基于重要性分為VIP用戶和普通用戶
- 基于資源消耗分為報(bào)表請(qǐng)求和用戶請(qǐng)求
同城雙活
同城雙活即多AZ部署。同城機(jī)房之間延遲很低,一般ping延遲在5ms以內(nèi)。同城的AZ間,基于網(wǎng)絡(luò),供電等的物理隔離,因此能夠避免單個(gè)機(jī)房故障導(dǎo)致的服務(wù)中斷。同城雙活是建立在“系統(tǒng)消除單點(diǎn)”的前提下。多AZ間,服務(wù)請(qǐng)求應(yīng)該盡量在一個(gè)AZ中處理完畢。
N+1冗余
服務(wù)可以根據(jù)同城機(jī)房數(shù)量進(jìn)行多AZ部署。N+1中的“N”指的是處理請(qǐng)求所需要的資源容量,“1”指的是防止機(jī)房故障所做的資源冗余。因此,N+1中的所有機(jī)房應(yīng)該具備同等的請(qǐng)求處理能力,從而避免某機(jī)房故障后,其余機(jī)房無(wú)法處理所需請(qǐng)求。N+1會(huì)導(dǎo)致一定的資源冗余,合理設(shè)置N的數(shù)量能夠減少成本。舉例來(lái)說,2機(jī)房的冗余度就是50%,而5機(jī)房的冗余度僅為20%。
異地多活
異地多活是保證服務(wù)高可用的高階方法。目前國(guó)內(nèi)多應(yīng)用在大型互聯(lián)網(wǎng)公司,用以防御單地域整體故障。異地多活的主要問題在于跨地域帶寬、成本問題以及跨地域延時(shí)較大。舉例來(lái)講,同城的延遲一般在5ms以內(nèi),而華北到華南的延遲可以達(dá)到50ms延遲,這還是使用專線的前提下。
案例 :“Yum源服務(wù)”的高可用部署實(shí)踐
Yum源服務(wù)是一種提供Centos系統(tǒng)的Yum倉(cāng)庫(kù)的下載服務(wù)。案例以此服務(wù)為例,討論如何搭建一個(gè)高可用的Yum源服務(wù)。Yum源服務(wù)最簡(jiǎn)單的架構(gòu)設(shè)計(jì)如下所示:
圖2 簡(jiǎn)單服務(wù)架構(gòu)
此服務(wù)由一臺(tái)云主機(jī)提供,數(shù)據(jù)存儲(chǔ)在本地,由Nginx提供下載服務(wù)。
以上架構(gòu)服務(wù)完全可以實(shí)現(xiàn)Yum源服務(wù)的功能。但是若此架構(gòu)的服務(wù)要對(duì)外提供服務(wù)會(huì)面對(duì)如下幾個(gè)問題:
- 單機(jī)部署,服務(wù)器一旦宕機(jī),服務(wù)就會(huì)故障;
- 性能瓶頸,一臺(tái)機(jī)器一次處理的請(qǐng)求數(shù)是有上限的,服務(wù)器IO也會(huì)成為性能瓶頸。
我們需要對(duì)架構(gòu)進(jìn)行調(diào)整以達(dá)到高可用的服務(wù)架構(gòu)。
高可用服務(wù)2.0v
高可用2.0v目的是解決上文中的問題。
首先識(shí)別服務(wù)中是否模塊都支持多實(shí)例部署(消除單點(diǎn)):
- 對(duì)于Nginx模塊,Nginx 是無(wú)狀態(tài)的,可以進(jìn)行橫向擴(kuò)容;
- 數(shù)據(jù)存儲(chǔ)在本地磁盤也可以進(jìn)行橫向擴(kuò)展,但是此時(shí)數(shù)據(jù)一致性將是主要問題。建議使用分布式文件系統(tǒng)解決數(shù)據(jù)存儲(chǔ)一致性的問題。
服務(wù)要滿足一定的并發(fā)量的要求,Nginx具有高并發(fā)的能力,并且支持橫向擴(kuò)展。使用分布式文件系統(tǒng)以達(dá)到并發(fā)量和解決數(shù)據(jù)一致性的要求。
我們使用Puppet對(duì)服務(wù)器進(jìn)行配置管理,保證服務(wù)器的配置一致(一致性)。每臺(tái)服務(wù)器都要求不在同一個(gè)故障域中(置放群組)。高可用的服務(wù)架構(gòu)如下:
圖3 高可用部署架構(gòu)2.0v
高可用服務(wù)3.0v
3.0v的高可用部署考慮同城雙活的場(chǎng)景。我們選擇華北兩個(gè)AZ進(jìn)行高可用服務(wù)的部署。架構(gòu)圖如下圖所示。兩個(gè)AZ部署同配置的服務(wù),通過云解析將流量分配到兩個(gè)AZ中,達(dá)到故障切換和負(fù)載均衡。
圖4 高可用部署架構(gòu)3.0v
高可用服務(wù)4.0v
再考慮異地多活的架構(gòu),上文提到異地多活難點(diǎn)是數(shù)據(jù)同步。對(duì)于此服務(wù)來(lái)說,其對(duì)數(shù)據(jù)一致性并不是強(qiáng)依賴,短時(shí)間的數(shù)據(jù)不一致可以接受?;诘赜?qū)α髁窟M(jìn)行隔離,從而實(shí)現(xiàn)分而治之的目的(流量隔離)。我們選擇在華南兩個(gè)機(jī)房部署一套和華北機(jī)器配置一樣的服務(wù)。服務(wù)架構(gòu)如下:
圖5 高可用部署4.0v
寫在***
以上僅僅是高可用部署的一次簡(jiǎn)單實(shí)踐。實(shí)際情況下,服務(wù)的模塊幾十到幾百個(gè)都有,服務(wù)的復(fù)雜性與高可用是反比例關(guān)系。而且,隨著服務(wù)的高可用部署特征越多,也會(huì)增加服務(wù)的復(fù)雜度,若做不好故障切換和預(yù)案建設(shè),可能還會(huì)降低服務(wù)的可用性指標(biāo)。
另一方面,服務(wù)的高可用部署與成本也有密切關(guān)系,跨機(jī)房、跨地域服務(wù)部署無(wú)論在資源成本和技術(shù)能力都會(huì)帶來(lái)挑戰(zhàn)。所以說高可用部署需要做到的是服務(wù)復(fù)雜度和成本之間的平衡,達(dá)到滿足服務(wù)當(dāng)前和未來(lái)一段時(shí)間內(nèi)需求的目標(biāo)。
本期作者:勿忘我
京東云 應(yīng)用研發(fā)部
一個(gè)高可用的服務(wù)需要從部署、變更、預(yù)案、監(jiān)控、安全等多方面考慮。如何做到99.99%服務(wù)高可用的要求,需要各個(gè)角色的工程師共同努力。從部署的角度,本文介紹了高可用服務(wù)所需具備的規(guī)范,案例部分通過對(duì)Yum源服務(wù)架構(gòu)的演變讓讀者更好的理解高可用服務(wù)部署,希望對(duì)大家有所幫助。
【本文為51CTO專欄作者“京東云”的原創(chuàng)稿件,轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)JD-jcloud獲取授權(quán)】