跨AZ部署是實現服務高可用較爲有效的方法，同時也極具性價比。如果實現了跨AZ部署，不僅可以消除服務中的單點，同時還可以逐步建設如下能力：服務隔離，灰度發佈，N+1冗餘，可謂一舉多得。因此，接下來我們會對有狀態的開源軟件進行一系列的跨AZ部署的介紹，本次介紹Zookeeper。
ZK容錯數
Zookeeper有這樣一個特性：集羣中只要有過半的機器是正常工作的，那麼整個集羣對外就是可用的（完整機器列表是預先定義在ZK的配置文件中）。也就是說，一個ZK集羣有3個實例，一個死了，還剩下2個正常的，過半了，所以3實例的Zookeeper的容忍度爲1。同理，一個ZK集羣有5個實例，2個死了，還剩下3個正常的，過半了，所以5實例的Zookeeper的容忍度爲2。因此可以用2n+1來描述ZK集羣的容忍度。考慮到3實例的集羣只能故障一個實例，因此，線上集羣一般都是五個實例的。
按照上述的邏輯，七個實例甚至更多的實例不是更好嗎？從實踐角度看，如果一個集羣5個實例扛不住的情況下，基本就需要做集羣拆分了。7個實例的集羣也許沒啥問題，但是這麼大壓力的集羣，一旦故障，影響面也是非常嚴重的，因此，更多的採用集羣拆分而不是持續擴容的方式。
最佳實踐
以線上最爲常見的5實例的ZK集羣爲例進行說明，5實例的ZK集羣主要有如下兩種部署方式：
延時敏感型：單AZ部署方案（AZ1:5），這種部署模式適用於Zookeeper服務的系統全部集中在同一個AZ內。在這種情況下，如果該AZ故障，那麼系統必然不可用，這時，ZK即使可用也沒有意義，因此也就沒有必要去做跨AZ的部署了，並且跨AZ後，還會增加常態下的網絡延時
高可用型：三AZ部署方案（AZ1:2 + AZ2:2+ AZ3:1），這種部署模式適用於Zookeeer服務的系統做了2-3個AZ的部署，從而確保業務系統所在的AZ，任意一個故障，ZK服務自身依然可用
其他部署形式的缺點
除去上述推薦的兩種部署形式外，不推薦的部署方式有兩AZ部署方案（AZ1:2 + AZ2:3），這種部署方式，僅能保證AZ1故障後整體服務的可用性，而三AZ部署方案則可以接受任意一個AZ的故障，本質上等同於單AZ部署的效果，因此不做推薦和介紹。
AZ數量是不是越多越好
如此類推，是不是說採用五個AZ每個AZ部署一個實例的方式是最好的呢？答案是否定的，有如下幾點考慮：
-
從故障域角度講，如果一個Region有較多的AZ，一般會拆分爲兩個故障域從而獲得更好的可用性。例如華北區域有6個AZ，將這6個AZ分爲兩個故障域，每個故障域3個AZ，這樣，任意機房的故障其影響範圍只會在一個故障域的三個AZ內，而不會擴散到整個區域。這樣對服務能力來講，損失面得到更好的控制。
-
從服務質量角度講，在冗餘度確定的情況下（5實例），且都能滿足業務可用性的同時（業務部署2-3個AZ），ZK部署在5個AZ，並不會帶來更高的可用性，相反，卻需要面對更多的機房抖動，延時和故障。假設一個機房一年平均故障一次，那麼五個機房一年就會故障五次，單個機房的故障時，服務會發生請求超時和重連，服務質量會略降低
-
從成本角度講，在冗餘度確定的情況下（5實例），且都能滿足業務可用性的同時（業務部署2-3個AZ），ZK部署在5個AZ，任意機房的故障都需要干預和關注，同比3AZ的情況，會增加更多的干擾，消耗人員的精力
關於機房規劃
在公有云的一個Region裏，往往有多個AZ可供選擇，拋開ZK泛泛的講一個服務應該部署在幾個AZ，主要是成本和可用性之間的平衡，在不同的環境下，得出的結果不盡相同，因此這裏只能給一些分析的思路：
-
如果部署2個AZ，按照N+1的冗餘要求，可以故障1個AZ，冗餘度是50%，雖然達成了可用性的要求，但成本較高，有一半的機器是冗餘的
-
如果部署3個AZ，按照N+1的冗餘要求，冗餘度爲33.33%，和2個AZ相比，成本節省16.67%
-
如果部署10個AZ，按照N+1的冗餘要求，冗餘度爲10.00%，從成本角度看，非常不錯。但是和8個AZ的情況相比，成本僅僅節省了2.50%，而多維護兩個機房的成本，可能會遠遠高於成本節省的2.50%，且服務可能大量進行跨AZ交互，延時增加
因此，一個服務應該選擇幾個AZ，既有上面提到的隔離域的考量，也有成本和可用性之間的平衡，以及當下採用的技術方案對網絡延時的要求等。所以，只有最適合的方案，而沒有標準答案。
對於實現了異地多活部署能力的業務，一般來講，其部署形式爲：華北、華中、華南三個Region，每個Region部署兩個服務單元，整體形成六個服務單元。華北、華中、華南三個Region之間可以實現較好的隔離性，地震，洪水等各種嚴重自然災害都不大會在三個Region間同時發生，因此從冗餘度角度講，可以防止任一單個Region的故障，因此從Region的冗餘度看，依然還是N+1的標準。
