導語

基於京東雲豐富的實戰經驗，我們將陸續分享運維方面的乾貨，幫助小夥伴們進階為運維達人，歡迎持續關注。此次帶來的是"高可用"系列——部署篇。

一個高可用的服務需要從部署、變更、預案、監控、安全等多方面考慮。如何做到99.99%服務高可用的要求，需要各個角色的工程師共同努力。

從部署的角度，本文介紹了高可用服務所需具備的規範，案例部分通過對Yum源服務架構的演變讓讀者更好的理解高可用服務部署，希望對大家有所幫助。高可用部署要求

圖1 高可用部署

（*註：隨着服務滿足高可用要求的增多，服務的高可用能力就越強）

一致性

這裏的一致性指的是模塊依賴的方方面面，包括但不限於硬件規格和配置、操作系統、基礎軟件、系統參數，還包括模塊自身的相關信息，如配置文件、版本、上下游依賴組件等的一致性。

可以通過配置管理工具（如Puppet）進行管理和週期性維護，確保配置始終如一。列舉一些不一致的問題，如CPU是否開啟超線程、內存是否關閉SWAP、操作系統版本、JDK版本、內核各種參數、文件系統類型以及模塊的配置等等，這些均可能對服務可用性造成嚴重影響，並帶來極大的問題定位成本。

消除單點

單點有兩種場景：一種是某個模塊僅部署了一個實例；第二種是某個模塊雖然部署了多個實例，但任意實例故障都會導致服務整體或者大面積不可用。

如何識別系統單點？通過排查模塊的實例數量和進行破壞性測試來發現系統中是否存在單點。對於已知的單點，則應該盡量做好預案，減少故障時長。

置放羣組

要理解置放羣組首先要理解故障域（Fault Domain）的概念。故障域指單個機房內由交換機或電源設備所造成故障的最大影響範圍，通常為一個或一組機架。同一模塊需要盡可能的分散部署在不同的故障域中，避免由單一故障域異常而導致模塊整體不可用。

公有雲下的置放羣組就是為了提高業務的高可用性，在創建時將實例以某種策略強制打散，以降低底層硬件/軟件故障給業務帶來的影響。

舉例來說，一個模塊的所有實例絕不應該部署在同一個接入交換機下，因為一旦這個接入交換機故障，就會導致該模塊整體故障，而一個機房內，有大量的接入交換機，是完全可以避免這種悲劇的。

流量隔離

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

· 基於地域分為華北、華中、華南區域的用戶

· 基於硬件類型分為PC、APP等

· 基於重要性分為VIP用戶和普通用戶

· 基於資源消耗分為報表請求和用戶請求

同城雙活

同城雙活即多AZ部署。同城機房之間延遲很低，一般ping延遲在5ms以內。同城的AZ間，基於網絡，供電等的物理隔離，因此能夠避免單個機房故障導致的服務中斷。同城雙活是建立在"系統消除單點"的前提下。多AZ間，服務請求應該盡量在一個AZ中處理完畢。

N+1冗餘

服務可以根據同城機房數量進行多AZ部署。N+1中的"N"指的是處理請求所需要的資源容量，"1"指的是防止機房故障所做的資源冗餘。因此，N+1中的所有機房應該具備同等的請求處理能力，從而避免某機房故障後，其餘機房無法處理所需請求。N+1會導致一定的資源冗餘，合理設置N的數量能夠減少成本。舉例來說，2機房的冗餘度就是50%，而5機房的冗餘度僅為20%。

異地多活

異地多活是保證服務高可用的高階方法。目前國內多應用在大型互聯網公司，用以防禦單地域整體故障。異地多活的主要問題在於跨地域帶寬、成本問題以及跨地域延時較大。舉例來講，同城的延遲一般在5ms以內，而華北到華南的延遲可以達到50ms延遲，這還是使用專線的前提下。案例 ："Yum源服務"的高可用部署實踐

Yum源服務是一種提供Centos系統的Yum倉庫的下載服務。案例以此服務為例，討論如何搭建一個高可用的Yum源服務。Yum源服務最簡單的架構設計如下所示：

圖2 簡單服務架構

此服務由一臺雲主機提供，數據存儲在本地，由Nginx提供下載服務。

以上架構服務完全可以實現Yum源服務的功能。但是若此架構的服務要對外提供服務會面對如下幾個問題：

· 單機部署，服務器一旦宕機，服務就會故障；

· 性能瓶頸，一臺機器一次處理的請求數是有上限的，服務器IO也會成為性能瓶頸。

我們需要對架構進行調整以達到高可用的服務架構。

高可用服務2.0v

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

首先識別服務中是否模塊都支持多實例部署（消除單點）：

· 對於Nginx模塊，Nginx 是無狀態的，可以進行橫向擴容；

· 數據存儲在本地磁盤也可以進行橫向擴展，但是此時數據一致性將是主要問題。建議使用分佈式文件系統解決數據存儲一致性的問題。

服務要滿足一定的並發量的要求，Nginx具有高並發的能力，並且支持橫向擴展。使用分佈式文件系統以達到並發量和解決數據一致性的要求。

我們使用Puppet對服務器進行配置管理，保證服務器的配置一致（一致性）。每臺服務器都要求不在同一個故障域中（置放羣組）。高可用的服務架構如下：

圖3 高可用部署架構2.0v

高可用服務3.0v

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

圖4 高可用部署架構3.0v

高可用服務4.0v

再考慮異地多活的架構，上文提到異地多活難點是數據同步。對於此服務來說，其對數據一致性並不是強依賴，短時間的數據不一致可以接受。基於地域對流量進行隔離，從而實現分而治之的目的（流量隔離）。我們選擇在華南兩個機房部署一套和華北機器配置一樣的服務。服務架構如下：

圖5 高可用部署4.0v總結

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

另一方面，服務的高可用部署與成本也有密切關系，跨機房、跨地域服務部署無論在資源成本和技術能力都會帶來挑戰。所以說高可用部署需要做到的是服務復雜度和成本之間的平衡，達到滿足服務當前和未來一段時間內需求的目標。