AWS光纜被挖後對架構設計的一點總結（二）

公衆號：大豬蹄子程序員

上篇文章咱們總結了一下同城雙活、異地多活、兩地三中心等一些部署架構，那麼這篇文章我來發表一下我對三地五中心的理解。

咱們上篇文章講過兩地三中心這個架構，以下圖：

這種架構具有容災能力，好比生產數據中心停電了，那麼能夠把全部流量都切到同城災備中心或異地災備中心，那麼如今的問題是假如真到了停電的那一天，你敢把全部的流量都切到災備中心去嗎？

上篇文章說了，災備中心它主要的功能是做爲生產數據中心的一個備份，因此它並無如同生產數據中心同樣不停的在對外提供服務，那麼就有問題了，災備至關於一個新人，一個一直在模仿大哥的一個新人，如今大哥受傷了，按道理是應該小弟頂上，可是小弟仍是個新人，硬頂上去是否是頗有可能會出錯？也就是說：

• 第一，不能保證災備中心有能力接管線上全部的用戶流量，可能剛已接收災備中心被壓垮，或者出現其餘各類各樣預估不到的錯誤；
• 第二，若是生產數據中心接收了用戶的寫請求，還沒來得及同步到災備中心，這個時候停電了，這種狀況下，也不能直接把用戶流量切到災備中心。

因此基於上面的分析，並非說災備中心必定不能頂上，只是在頂上以前可能還要作不少其餘的檢查和準備，這個時間是不肯定的，至少不會很快...。

那麼問題來了，該怎麼辦？

首先對於上面列出來的兩點中的第一點，若是咱們可以讓災備中心再也不僅僅只能用來作災備，還能和生產數據中心同樣正常的對外提供服務呢？以下圖：

能夠看到上面的架構圖：

• 再也不區分生產數據中心和災備數據中心，只有數據中心，並且數據中心之間相互備份數據，保證每一個數據中心都是全量數據。
• 用戶能夠在任意一個數據中心上進行讀寫操做。

好，首先咱們無論這種架構能不能實現，至少它的好處是很是明顯的：

1. 每一個數據中心一直在對外提供服務（不是一個新手），因此當一個數據中心停電後，直接把用戶流量切到另一個數據中心也是問題不大的。
2. 用戶能夠就近訪問數據中心，這樣用戶的體驗更好，而且整個架構的流量也比較平均。

優勢很明顯，若是能實現就再好不過了，那麼這種架構實現起來最重要的一點就是：用戶同時向不一樣數據中心寫入數據，數據中心雙向同步數據時，若是出現衝突該如何解決？

那麼這個問題，目前阿里和螞蟻金服的解決辦法是：將用戶按某一個規則進行分組，每組用戶寫入數據時只能寫入到指定的數據中心，至關於用戶與數據中心綁定在一塊兒了，這樣保證了數據中心在雙向同步以前數據是不會衝突的，由於按用戶分組了，不一樣用戶的數據不會衝突。

固然思路很是簡單，可是實現起來確定是很是麻煩的，可是思路確定是能夠的，阿里也用實踐證實了，咱們先把上面的架構稍微完善一下：

用戶使用網站時，由運營商網絡或CDN選擇最近的機房，機房內部署一個負載均衡，由這個負載均衡最終判斷用戶屬於機房（前文中的數據中心），也就是可能出現，用戶在註冊時在北京，那麼他的uid就和北京某個機房綁定了，那麼當這個用戶在上海使用時，會由上海的負載均衡按照用戶分組規則將請求轉發到北京綁定的那個機房去（固然並非全部請求，好比讀請求確定能夠直接在上海機房進行讀取，因此具體的實現都要看業務怎麼實現了，以及負載均衡具體的配置，這裏只是把最簡單易懂的思路說一下）。

因此，咱們如今能夠：

• 假設北京機房1應用程序或數據庫對應的機器停電了，那麼咱們能夠調整負載均衡是本來屬於這個機房的用戶流量轉移到機房2去，注意這裏不要有疑問，將用戶進行分組是爲了防止用戶同時寫兩個數據庫發生衝突，那麼如今機房1裏其實已經不能寫入數據了，因此將流量遷移到機房2是沒有問題的。
• 假設北京機房1整個停電了，那麼能夠經過運營商網絡或CDN將流量遷移到北京機房2。
• 假設北京停電了，那麼同樣能夠將流量遷移到上海。

這個架構中最重要的其實就是用戶分組，因此包括咱們的應用程序、數據庫負載均衡、數據庫分表等等都須要按用戶進行分組，咱們要保證針對同一個用戶的請求與操做都在同一個機房內，不去跨機房，這樣纔是最快的，這就是單元化。

那麼上面這個架構實際上就是一個高級版的「兩地三中心」，只是這種單元化架構咱們能夠任意去擴展（只要你足夠有錢，由於搭一套全配置的數據中心是須要很高成本的），好比你在上海在增長一個數據中心，在杭州也增長一個，那麼就以下圖：

這就叫三地五中心。

市面上淺顯的講述三地五中心的文章很少，但願這篇文章能給你幫助，固然我也是參考了其餘文章有了本身的理解，若是錯誤的地方歡迎你們指正。

相信你們不喜歡在小小的手機屏幕上還看到一大塊的代碼，閱讀體驗很差，因此我寫做的風格會文字偏多一點。若是以爲有所收穫就給個小小的贊吧。

公衆號：大豬蹄子程序員

參考：

• www.infoq.cn/article/int…
• tech.antfin.com/community/a…