互聯網異地多活方案發展歷史

原創聲明：本文系作者原創，謝絕個人、媒體、公眾號或網站未經授權轉載，違者追究其法律責任。

今日的互聯網環境，已經是標準的大數據規模，各大主流互聯網平台都是PB級別數據及准PB級。異地多活技術是隨著互聯網環境進步發展到PB量級後，出現並逐步完善的一種用於解決高並發、大流量、高可用、熱災備需求的分散式解決方案。近4、5年，隨著互聯網環境的不斷進步，當前異地多活技術是僅次於微服務架構、區塊鏈等領域之後的熱門技術話題，並且已經逐漸形成一套穩定的分散式SOA化理論。本文參考當前全球主流互聯網平台資料，整合異地多活技術進化過程中的來龍去脈。

一、數據中心(IDC)

電信部門利用已有的互聯網通信線路、帶寬資源，建立標準化的電信專業級機房環境，為企業、政府提供伺服器託管、租用以及相關增值等方面的全方位服務，即是一種低於iaas的互聯網基礎環境設施服務。，單IDC說就是為企業等提供伺服器硬體、存儲、寬頻、鏈路監控、安全保障等軟硬體服務的機房。一個IDC機房通常有如下拓撲結構如下：

二、光纖傳輸數據延遲問題

光的傳輸速度是3.0×10^8m/s, 光纖中的數據傳輸速率遠低於此，光纖傳輸延遲是互聯網鏈路層的瓶頸。在IDC之間數據傳輸時更是如此，接下來講到兩地三中心方案、同城多活、異地多活等的底層方案，很大部分都是圍繞解決數據傳輸延遲帶來的問題。例如新浪微博北京的兩個核心機房間延時在1ms左右，但北京機房到廣州機房則有近40ms的延時。對比一下，微博核心Feed介面的總平均耗時也就在120ms左右。微博Feed會依賴幾十個服務上百個資源，如果都跨機房請求，性能將會慘不忍睹等。

三、兩地三中心技術方案

兩地三中心方案是互聯發展之初，主要用於解決銀行、金融、金融級別等電算化平台的業務連續性保障(BCM)、數據災備容災等需求，以應對突發、致命性的災難等問題,並且已經是政府指定的金融級系統的規範性災備標準。直到現在，該方案雖然仍有很多不完善的地方及微升級方案，但仍是銀行、金融等領域的標準災備技術,如下是兩地三中心技術方案的典型架構圖:

這個架構方案在過去的20來年絕大多數解決過去互聯網中的災備等問題，滿足銀行、金融、政企等非高並發、強一致、強安全的業務連續需求。然而隨著互聯網數量級的提升，上述方案與現今的互聯網環境高並發、高可用、大數據環境相對照，存在如下幾個問題:

1. 冷災備中心: 災備中心是冷備份，在真正出現災難性故障後，不能確定冷數據是否能及時恢復運行甚至及時恢復業務線

2. 浪費硬體資源，冷備份中心正常情況下始終全量備份，不對外提供業務，很可能是長期一直不使用的情況。

四、同城多活

傳統兩地三中心架構在互聯網行業的早期實踐成熟方案是同城多活。真正意思上的同城多活是指應用層多活和數據層同時多活，只有這2層多活，才能達到實際的流量切換與連續業務，當然在實施過程中從開發效率及商業目標等考慮，會使用一些偽同城多活的方案，如早期阿里為了應對雙11購物，杭州機房與上海機房採用的就是偽同城多活，應用層多活，2個應用節點同時寫一個機房數據，並且很好的解決雙11大流量購物需求。同城多活里，同城應用可以跨機房寫資料庫，應用層面的多活就實現了。而在強化了應用層面的容錯和故障處置手段之後，因為同城的數據傳輸延遲小，在主資料庫故障時，應用可快速把主資料庫切換到其他機房的從資料庫。在這種機制下，不單可以實現資料庫的多活，而且進一步實現了數據中心層面的同城多活，理論上任何一個數據中心中斷都不會導致業務中斷，切換過程也非常簡單。

無論數據層多活還是偽同城多活，技術上基礎關鍵問題都是高可用數據層支持和富有伸縮彈性的存儲層，基於彈性的存儲層，才能做良好的監控、運維、高效異常處理、運營等。

五、異地多活

異地多活是同城多活技術的高級階段，上面提到，因為物理光纖的熟讀傳輸限制，實際在同城使用的方案，幾乎是不能完全使用在異地多活需求上。所謂異地多活，故名思義，就是在相距有一定遠距離地點的數據中心有多個相同業務需求的交易平台，並且每個地點的交易平台都是用來支撐分擔流量的。通常異地多活是跨地域的，而且距離一定要做到1000公里以上的範圍。異地多活的每個多活數據中心都要承擔用戶的讀寫流量。如果只是備或只讀業務來講，作用不是很大。

異地多活，從整個業界的做法上來講，主要有幾家公司，比如Google、Facebook，這些是技術強悍切比較典型的，Google做到了全球多個數據中心，都是多活的。但是Google具體怎麼做的，也沒有多少人了解。另外就是Facebook，我們相對更了解一些，Facebook在做多個數據中心時，比如說美國和歐洲兩個數據中心，確實都在支撐流量。但是歐洲的用戶有可能需要訪問美國的數據中心，當出現這種狀況時，整個用戶體驗不好。國內目前將異地多活做成熟的公司比較多，像阿里的單元化異地多活、餓了么、新浪微博、京東購物等，都已經做得非常成熟。

如下是異地多活的拓撲圖:

圍繞上述的拓撲結構，所有程序員都要解決上述結構帶來的問題，比如: 數據傳輸延時、請求延遲、消息延遲、專線、數據一致性、分散式事務、服務依賴、隊列依賴、流量控制、部署便捷等等一系列問題及怎樣解決。

六、異地多活的實施和運維成本

上面的章節我們提到了異地多活粗略的架構藍圖。今天的互聯網，每個有一定規模的公司都在儘可能結合自己業務，實踐自己的多活技術棧。互聯網環境有一個很出名的定律，叫做墨菲定律(Murphy"s Law)：

一、任何事都沒有表面看起來那麼簡單；

二、所有的事都會比你預計的時間長；

三、會出錯的事總會出錯；

四、如果你擔心某種情況發生，那麼它就更有可能發生。

其中第一、二條: "任何事情都沒有表面看起來那麼簡單，所有的事都會比你預計的時間長"。即是描述了工程性項目的實施成本與時間成本，我想說的是，上面我們提到的異地多活設計藍本雖然邏輯上很簡單，但是我們的軟體世界並不像自然社會，軟體發展的當前階段，圍繞此多活藍本去實施的成本遠比設計成本多得多，一代代優秀的程序員在不斷實踐中總結這套設計理論，同時又不斷從理論中去實踐，努力構建出更穩定、更低成本的多活方案。

圍繞多活技術，大致有如下比較大的實施和運維成本:

1.機房之間的延時。

2.專線問題: 機房專線成本巨大。同時單條專線的穩定性也很難保障，基本上每個月都會有或大或小的問題；

3.數據同步問題: MySQL如何做數據同步？HBase如何做數據同步？還有各種自研的組件，這些統統要做多機房數據同步。幾十毫秒的延時，加上路途遙遠導致的較弱網路質量（我們的專線每個月都會有或大或小的問題），數據同步最最大的挑戰(不是之一)。

4.依賴服務部署問題: 如同阿里目前只做了交易單元的「異地雙活」，微博部署時也面臨核心服務過多依賴小服務的問題。將小服務全部部署改造成本、維護成本過大，不部署則會遇到之前提到的機房之間延時導致整體性能無法接受的問題；

5.運維體系問題: 服務部署沒有流量引入就不能稱為「雙活」，而要引入流量就要求配套的服務和流程都能支持異地部署，包括預覽、發布、測試、監控、降級等一系列高實施成本的運維改造方案。

七、結束語

多活的技術成本非常高，每家公司都不斷在成本與業務之間綜合平衡各種利弊，選擇最好的方式服務業務。總之， 多活技術並不能100%解決全部業務多活，只能盡量保證絕大部分用戶的核心業務異地多活，希望學習者、實踐者能儘可能評估到其中利弊，領會其中精粹。

現代多活方案常常會利用雲計算平台的低部署和彈性運營成本與雲計算平台搭建混合雲環境，分散式多活數據中心與雲計算建設的思路既有相同之處也有差別，雲的形成可以基於數據中心的分散式技術，建設模型更接近互聯網數據中心，而分散式多活數據中心的實現和實踐門檻相對要低，用戶在建設運維時更多的會關注於自身業務聯繫性的要求與業務的快速響應及IT建設的持續優化，對複雜的企業級應用提供更好的支撐，使得IT建設更多的基於自身現有資源和能力。總之使用混合方式，而不盲目追求先進，體現了企業對於自身IT建設的把握與未來方向的掌控，是大型企業數據中心、大型多活系統持續穩健前行的必經之路。

參考:

1.http://www.zte.com.cn/cndata/magazine/zte_technologies/2016/2016_6/magazine/201606/t20160620_458639.html

2.http://www.infoq.com/cn/articles/interview-alibaba-bixuan

3.http://www.infoq.com/cn/presentations/the-structure-of-alibaba-double-living-in-the-same-city

4.https://yq.aliyun.com/articles/65068?spm=a2c4e.11153940.blogrightarea57715.21.4b2925d8uGb88i

5.http://dc.idcquan.com/ywgl/71559.shtml

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