真正「多活」，看青雲交出的答卷

北京時間10月22日早上6點52分，GitHub.com出現大面積網站宕機。

從問題出現開始到解決的這24小時里，GitHub團隊顯然處於崩潰狀態。

北京時間下午2點51分開始，狀態消息不斷在更新：再給我2小時！再給我1.5小時！再給我半小時！......

然而，「小時復小時，小時何其多」，承諾了太多，做到的太少，無奈，官方發布致歉函，表示真摯的歉意。

讀完這段新聞，作為報道科技圈十餘年的賽迪網記者來說，還是想和大家聊聊「多活」，那麼什麼是多活呢？青雲QingCloud運營副總裁林源的解讀很專業、明了：就是增強系統可靠性、提升業務連續性以及使業務運行不受故障/災難影響。

但是，真正實現多活，並不簡單。因為只要是設備、硬體，就有出故障的概率，「多活要做的就是必須規避任何的單點，包括一個數據中心內部的單點甚至是整個數據中心宕機的單點。而我們探討的多活是業務上的多活，它會依賴部署在多個數據中心。」林源這樣解讀。

多活里有兩個公認的技術指標：業務恢復時間（RTO）和數據的丟失量（RPO），這二者在不同的企業中的重要性是不同的，對於互聯網企業來說，其更關注業務恢復時間；對於銀行、保險等跟民生相關的企業，則不允許數據丟失。

不過理想的場景是，二者（RTO/RPO）都趨於零。

對於選擇多活業務的企業，林源的建議是兩類企業，其一是業務故障後會影響公司整體的業務，導致客戶資金受損；其二是業務面向的客戶數目比較廣泛，影響較大。

具體來說，包括兩大類別。第一種是大規模線上運營業務，比如電商網站、微信、微博等，業務的中斷是不能容忍的，因為每天都有大量的客戶在使用這個服務。第二種是銀行、保險、重型製造等場景，銀行IT架構需要符合銀監會的規定，需要有兩地三中心。

以上多活的好處已經毋庸置疑了，但是巨大的投入也讓很多企業對於多活的選擇望而卻步，總結來說有硬體成本高、人力成本高以及前期部署投入成本高。

那麼怎麼解決呢？其實很簡單，用青雲的多活。

林源在三個層面做了解讀：基礎設施、基礎架構以及分散式應用。通過這三個層面，可以讓客戶以更低的成本、更低的門檻部署他自己的多活業務。

在基礎設施層面，「兩地三中心」至少需城市、機房、光纖、網路。青雲目前有三個大區提供多活服務：北京3區、廣東2區、上海1區。

林源特別提到了多機房之間的互聯問題，互聯的帶寬和延遲都有保障。每個數據中心之間是波分互聯，大概是幾百Gbps的通道，這就保證了多個數據中心之間的低延時性。

以一個銀行業務為例，它在北京有兩個數據中心做多活。當取款和轉賬時，這筆交易要同時寫在北京的兩個數據中心裡。如果這兩個機房之間的延遲很低，很快返回。從用戶的體驗來說，你轉一筆賬很快就成功了。如果兩個機房之間的延遲很長，對用戶體驗來說可能是轉賬半分鐘還沒返回。

在採訪中對於記者提出的多活與災備的區別，林源強調了「真正」多活的概念，最簡單的模式是雙活，就是兩個數據中心同時提供服務。任意一個數據中心宕掉不會影響另一個數據中心，所以它的RPO和RTO都有保障。這不是傳統意義上的「災備」概念。

而且這個多活的基礎架構包含了友商經常不具備的私有網路和VIP多活的能力。

林源最後表示，青雲的多活不光在公有雲上使用，包括混合雲、私有雲，青雲都有全面的交付能力。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！