Google寫了一篇關於部署架構的總結性文章，包含了常見部署架構的定義，我向來比較喜歡這一類綜述性的文章，能夠挖到最原始的資訊，也能看到最新的進展，閱讀並稍作記錄。文章儘可能的簡短以提高動筆意願，否則就太懶而不可得。

文中講了6種部署架構，從小到大分別是Zone/Regional/Multi-Regional/Global/Hybrid/Multi-Cloud。Zone一般理解為獨立的機房設施（有的文章裡，zone和機房是對等的），比如供電獨立，網路獨立，一個zone掛了不影響另外的zone。有時候我們看到AZ是指available zone，也就是可用區。Region由多個地理位置上相距不遠的zone組成，比如阿里雲有北京/杭州等region，每個region有若干個zone。

文章的主要角度是可用性，兼顧考慮了複雜度/成本等問題，所以列出的各個部署架構的解釋，主要圍繞可用性進行說明。可用性簡單理解就是，如果掛了，怎麼辦？複雜理解，就是服務可靠性是幾個9？5個9就是說1年只能掛5分鐘，做過雲服務的同學應該理解這是非常苛刻的標準。

逐一列出部署模式，

Zone部署：服務程序全部部署在一個zone內部，如果zone掛了（比如停電），乾等著，直到zone恢復後服務才能繼續。主備zone部署也屬於這個模式，平時只有主zone提供服務，主zone掛了，備zone啟動起來提供服務，其可用性比單zone好，但是從主zone掛到備zone提供服務仍然需要較長時間，所以主備zone也歸屬為zone部署模式。

Regional部署：一個region一般是3+個zone。服務程序部署在多個zone且任何時候，多個zone都同時提供服務。一個zone掛了，其所承擔的流量可以被分流到其他zone。模式包括單region和主備region，可類比上面的單zone和主備zone。Regional部署比主備zone部署主要的好處是如果zone掛了，服務幾乎不受影響，我們平時網上看到的“多活”多指這個級別，已經非常厲害了。主備region部署一般用於自然災難容災，比如某個地方突然被洪水淹了，所有zone都掛了，此時備zone還可以載入之前備份的資料，繼續提供服務。

Multi-Regional：將應用按照某種緯度切分然後分別在不同的region提供服務，比如西邊網友都分配到靠西的region，東邊網友分配到靠東的region，這樣延時比較低，客戶體驗較好。一個region掛了只有部分客戶收受到影響，其他客戶照常服務。和上面的主備region的區別是，主備region部署中，如果主region掛了，全部客戶不可服務，直到備region啟用或者主region恢復。這個部署模式有2種細分，一種是我上面提到的分片，按使用者地理位置分東西兩邊。這種模式，東邊region掛了，東邊網友用不了，因為資料都在東邊region，只能等待region恢復，同時西邊網友不受影響。一種是東西網友的資料互聯互通，每個region都具備全量資料，這樣東邊region掛了，因為西邊region具備全量資料，東邊網友可以被排程到西邊region，延時可能有所上升，但是至少比沒有好，當然，此時需要擴容西邊region的服務能力，不然沒法承擔這麼大流量。

Global：我們想，上面Multi-Regional不就是global了嗎？文章說這兩者的區別是Multi-Regional部署的軟體，其需要意識到是在一個region內，也就是某個region內的代理服務不能訪問另一個region內的後端服務，而global這種模式就不需要關注region了，按照需求（距離，服務能力等）直接訪問即可，這當然也意味著任何region掛了都可以很快恢復服務，甚至做到客戶無感。一個非常大的挑戰是資料要實時或者準實時全球複製，非常難，可能Spanner做到了。

Hybrid：是指客戶on-premises部署和雲服務提供商混部。上雲是大勢所趨，但是也不是一撮而就，這種模式是一個過渡階段，主要是利用雲的一些能力先解決痛點問題，比如安全，流量突增，資料備份等，和我們通常說的可用性有較大區別，勉強算一類。

多雲：理論上說，雲服務商可能多個region掛，比如某個運維操作配置失誤之類的。多個雲廠商同時犯錯的事情應該還沒有發生過，所以多雲算是一種可用性提高的方案，但是這種方案的代價還是比較大的，包括各個雲廠商API行為不一致，跨雲流量費用，對多雲技能的學習等，個人認為不會是主流方式，lock in焦慮未來將越來越弱。

上面幾種模式中通用的技術包括，健康度探測（總得知道誰掛了，靠客戶打電話也是一種手段），負載均衡（流量如何在多個zone之間分配，自己做還是藉助雲廠商產品），資料複製（資料要在多個點可用），每一個都是很難的問題，也非常有趣，尚不知道是否有比較好的綜述類的文章。

［1］。 Deployment Archetypes for Cloud Applications