高可用部署要求

圖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)類型以及模塊的配置等等，這些均可能對服務(wù)可用性造成嚴(yán)重影響，并帶來極大的問題定位成本。

消除單點(diǎn)

單點(diǎn)有兩種場景：一種是某個模塊僅部署了一個實(shí)例;第二種是某個模塊雖然部署了多個實(shí)例，但任意實(shí)例故障都會導(dǎo)致服務(wù)整體或者大面積不可用。

如何識別系統(tǒng)單點(diǎn)?通過排查模塊的實(shí)例數(shù)量和進(jìn)行破壞性測試來發(fā)現(xiàn)系統(tǒng)中是否存在單點(diǎn)。對于已知的單點(diǎn)，則應(yīng)該盡量做好預(yù)案，減少故障時長。

置放群組

要理解置放群組首先要理解故障域(Fault Domain)的概念。故障域指單個機(jī)房內(nèi)由交換機(jī)或電源設(shè)備所造成故障的***影響范圍，通常為一個或一組機(jī)架。同一模塊需要盡可能的分散部署在不同的故障域中，避免由單一故障域異常而導(dǎo)致模塊整體不可用。

公有云下的置放群組就是為了提高業(yè)務(wù)的高可用性，在創(chuàng)建時將實(shí)例以某種策略強(qiáng)制打散，以降低底層硬件/軟件故障給業(yè)務(wù)帶來的影響。

舉例來說，一個模塊的所有實(shí)例絕不應(yīng)該部署在同一個接入交換機(jī)下，因?yàn)橐坏┻@個接入交換機(jī)故障，就會導(dǎo)致該模塊整體故障，而一個機(jī)房內(nèi)，有大量的接入交換機(jī)，是完全可以避免這種悲劇的。

流量隔離

流量隔離是搭建多套同質(zhì)集群根據(jù)流量的屬性進(jìn)行分而治之的管理。常見的隔離策略主要基于流量的來源、重要性和資源消耗進(jìn)行隔離。舉例來說：

• 基于地域分為華北、華中、華南區(qū)域的用戶
• 基于硬件類型分為PC、APP等
• 基于重要性分為VIP用戶和普通用戶
• 基于資源消耗分為報表請求和用戶請求

同城雙活

同城雙活即多AZ部署。同城機(jī)房之間延遲很低，一般ping延遲在5ms以內(nèi)。同城的AZ間，基于網(wǎng)絡(luò)，供電等的物理隔離，因此能夠避免單個機(jī)房故障導(dǎo)致的服務(wù)中斷。同城雙活是建立在“系統(tǒng)消除單點(diǎn)”的前提下。多AZ間，服務(wù)請求應(yīng)該盡量在一個AZ中處理完畢。

N+1冗余

服務(wù)可以根據(jù)同城機(jī)房數(shù)量進(jìn)行多AZ部署。N+1中的“N”指的是處理請求所需要的資源容量，“1”指的是防止機(jī)房故障所做的資源冗余。因此，N+1中的所有機(jī)房應(yīng)該具備同等的請求處理能力，從而避免某機(jī)房故障后，其余機(jī)房無法處理所需請求。N+1會導(dǎo)致一定的資源冗余，合理設(shè)置N的數(shù)量能夠減少成本。舉例來說，2機(jī)房的冗余度就是50%，而5機(jī)房的冗余度僅為20%。

異地多活

異地多活是保證服務(wù)高可用的高階方法。目前國內(nèi)多應(yīng)用在大型互聯(lián)網(wǎng)公司，用以防御單地域整體故障。異地多活的主要問題在于跨地域帶寬、成本問題以及跨地域延時較大。舉例來講，同城的延遲一般在5ms以內(nèi)，而華北到華南的延遲可以達(dá)到50ms延遲，這還是使用專線的前提下。

案例 ：“Yum源服務(wù)”的高可用部署實(shí)踐

Yum源服務(wù)是一種提供Centos系統(tǒng)的Yum倉庫的下載服務(wù)。案例以此服務(wù)為例，討論如何搭建一個高可用的Yum源服務(wù)。Yum源服務(wù)最簡單的架構(gòu)設(shè)計(jì)如下所示：

圖2 簡單服務(wù)架構(gòu)

此服務(wù)由一臺云主機(jī)提供，數(shù)據(jù)存儲在本地，由Nginx提供下載服務(wù)。

以上架構(gòu)服務(wù)完全可以實(shí)現(xiàn)Yum源服務(wù)的功能。但是若此架構(gòu)的服務(wù)要對外提供服務(wù)會面對如下幾個問題：

• 單機(jī)部署，服務(wù)器一旦宕機(jī)，服務(wù)就會故障;
• 性能瓶頸，一臺機(jī)器一次處理的請求數(shù)是有上限的，服務(wù)器IO也會成為性能瓶頸。

我們需要對架構(gòu)進(jìn)行調(diào)整以達(dá)到高可用的服務(wù)架構(gòu)。

高可用服務(wù)2.0v

高可用2.0v目的是解決上文中的問題。

首先識別服務(wù)中是否模塊都支持多實(shí)例部署(消除單點(diǎn))：

• 對于Nginx模塊，Nginx 是無狀態(tài)的，可以進(jìn)行橫向擴(kuò)容;
• 數(shù)據(jù)存儲在本地磁盤也可以進(jìn)行橫向擴(kuò)展，但是此時數(shù)據(jù)一致性將是主要問題。建議使用分布式文件系統(tǒng)解決數(shù)據(jù)存儲一致性的問題。

服務(wù)要滿足一定的并發(fā)量的要求，Nginx具有高并發(fā)的能力，并且支持橫向擴(kuò)展。使用分布式文件系統(tǒng)以達(dá)到并發(fā)量和解決數(shù)據(jù)一致性的要求。

我們使用Puppet對服務(wù)器進(jìn)行配置管理，保證服務(wù)器的配置一致(一致性)。每臺服務(wù)器都要求不在同一個故障域中(置放群組)。高可用的服務(wù)架構(gòu)如下：

圖3 高可用部署架構(gòu)2.0v

高可用服務(wù)3.0v

3.0v的高可用部署考慮同城雙活的場景。我們選擇華北兩個AZ進(jìn)行高可用服務(wù)的部署。架構(gòu)圖如下圖所示。兩個AZ部署同配置的服務(wù)，通過云解析將流量分配到兩個AZ中，達(dá)到故障切換和負(fù)載均衡。

圖4 高可用部署架構(gòu)3.0v

高可用服務(wù)4.0v

再考慮異地多活的架構(gòu)，上文提到異地多活難點(diǎn)是數(shù)據(jù)同步。對于此服務(wù)來說，其對數(shù)據(jù)一致性并不是強(qiáng)依賴，短時間的數(shù)據(jù)不一致可以接受。基于地域?qū)α髁窟M(jìn)行隔離，從而實(shí)現(xiàn)分而治之的目的(流量隔離)。我們選擇在華南兩個機(jī)房部署一套和華北機(jī)器配置一樣的服務(wù)。服務(wù)架構(gòu)如下：

圖5 高可用部署4.0v

寫在***

以上僅僅是高可用部署的一次簡單實(shí)踐。實(shí)際情況下，服務(wù)的模塊幾十到幾百個都有，服務(wù)的復(fù)雜性與高可用是反比例關(guān)系。而且，隨著服務(wù)的高可用部署特征越多，也會增加服務(wù)的復(fù)雜度，若做不好故障切換和預(yù)案建設(shè)，可能還會降低服務(wù)的可用性指標(biāo)。

另一方面，服務(wù)的高可用部署與成本也有密切關(guān)系，跨機(jī)房、跨地域服務(wù)部署無論在資源成本和技術(shù)能力都會帶來挑戰(zhàn)。所以說高可用部署需要做到的是服務(wù)復(fù)雜度和成本之間的平衡，達(dá)到滿足服務(wù)當(dāng)前和未來一段時間內(nèi)需求的目標(biāo)。

[[264384]]

本期作者：勿忘我

京東云 應(yīng)用研發(fā)部

一個高可用的服務(wù)需要從部署、變更、預(yù)案、監(jiān)控、安全等多方面考慮。如何做到99.99%服務(wù)高可用的要求，需要各個角色的工程師共同努力。從部署的角度，本文介紹了高可用服務(wù)所需具備的規(guī)范，案例部分通過對Yum源服務(wù)架構(gòu)的演變讓讀者更好的理解高可用服務(wù)部署，希望對大家有所幫助。

【本文為51CTO專欄作者“京東云”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號JD-jcloud獲取授權(quán)】

戳這里，看該作者更多好文