異地多活架構設計系列(一): Why and How
很多全球化的產品， 比如facebook、twitter， 它們的使用者遍佈世界各地。 工程師們往往會在全球設立多個數據中心（DC）供使用者訪問， 我們可以稱之為異地多活。在後續一段時間裡， 我會寫一系列的部落格，和大家一起探索異地多活架構。
這篇文章主要是討論我們為什麼需要異地多活， 以及實現這種架構所需要解決的問題。
一、異地多活的好處
1. 提高使用者體驗
一個產品最重要的是提供良好的使用者體驗，這對後端服務提出了幾個要求：
- 服務的高可用 對於一些服務而言， 需要提供6個9甚至以上的可用性。 高可用的原則就是避免單點+自動故障轉移。 為了避免機房粒度的單點， 我們需要提供多個DC， 彼此做災備。
- 良好的響應速度 如果全球只有一個DC，那麼所有的使用者都只能訪問這一個。 這種情況下，跨洲級別的RTT（一般來說>200ms），對於使用者體驗而言是個災難。 所以全球級的產品需要在世界各地部署DC，供使用者就近訪問。
2. 降低成本
廉價的機器
我們都知道， 很多商品在不同地方的價格是不一樣的，伺服器也不例外。 如果能讓非洲使用者訪問本地廉價的後端服務， 為什麼要讓他們的流量跑到美東去呢？
流量的分攤
一般而言，我們需要控制機器資源大於峰值流量的某個百分比（比如為1w日活備好2w日活的機器)。 如果你的DC已經遍佈世界各地， 那麼如果某地的流量瘋漲時，你不需要擔心機器資源不能及時到位、為高峰期擴容後的資源浪費這種問題。 比如過萬聖節、聖誕節時，facebook美國流量瘋長， 這時候我們可以選擇把一部分流量切到亞洲地區的DC。
二、如何做到異地多活
要做到異地多活， 有幾個問題我們必須解決：
-
接入層流量控制 使用者預設訪問哪個DC？ 什麼時候做切換？ 如何控制這個切換過程？
-
各DC業務邏輯一致 對於使用者來說， 他的流量被排程前後，業務邏輯是一致的。 比如facebook上有一些內容對於亞洲使用者是不可見的，不能因為亞洲使用者的流量被遷移到了美洲機房，這個限制就失效了。
-
跨DC的實時資料同步與衝突處理 還是以fb為例， 如果訪問非洲機房的使用者A給訪問南美洲機房的使用者B的一個帖子點了贊， 那麼B應該能及時收到相關的通知。這背後就依賴資料的實時同步。
在多活情況下， 多DC的資料寫入勢必會引入資料的衝突， 比如facebook位於美東的的稽核系統和位於東南亞的使用者同時操作了一條帖子， 就會產生資料的衝突。
-
提供全球級別的強一致性 對於大多數業務而言， 我們只需要最終一致性即可（比如點贊之類的計數）。 但是某些業務，需要全球的強一致保障(比如下單、支付之類的操作）。