b站崩了那一晚上我想該寫點什麼了

 

昨晚氵羣的時候，幾個讀者羣都很熱鬧，點開幾乎都在討論B站崩了的事情，你們還不斷在給B站作壓測，訪問從沒中止過。

寫段子、調侃B站的文章已經太多了，做爲技術人，正好藉此次機會說說互聯網公司是怎麼作高可用的。

通常互聯網公司，通過了這十幾二十年的增加，技術的一輪一輪迭代，中型以上互聯網公司基本都有一套本身的高可用的架構，經歷了一個階段：

• 單機房
• 同城多機房
• 異地多活（二地三中心）

大多數互聯網公司都是走了這樣一個架構升級歷程，可是真正在容災方面作的怎麼樣？估計只有他們本身最清楚。

國內互聯網公司的SRE不少都是參考Google 來作的，方法論是Google在2015年發表的一篇論文《High-Availability at Massive Scale: Building Google’s Data Infrastructure for Ads》，爲此Google還寫了一本書（書圖片放下面了），相信不少人都看過。不過即便是強如Google，也有服務宕機的狀況。

美國東部時間 12 月 14 日，大量用戶反饋 Google 公司服務中斷， YouTube、Gmail、Google 雲端硬盤、Google Search 等服務沒法正常使用。此外，很多熱門手機遊戲也受到了波及，由於須要用谷歌帳戶登陸。長達 50 分鐘的宕機，導致全球多個國家及地區用戶受到嚴重影響。

緣由：Google Cloud Platform 和 Google Workspace 經歷了一次全球中斷，影響了全部須要 Google 帳戶認證的服務，持續時間爲 50 分鐘。根本緣由是咱們的自動配額管理系統出現了問題，下降了谷歌中央身份管理系統的容量，致使其在全球範圍內返回錯誤。所以，咱們沒法驗證用戶請求是否通過認證，並向用戶提供錯誤。

簡單來講，是因爲內部存儲配額的問題使 Google 身份驗證系統中斷，致使宕機了 50 分鐘。

其實就算是作了異地多活，也不能徹底保證系統服務徹底不宕機，沒有銀彈，這是軟件系統自己的複雜性決定的，一方面互聯網技術在不斷迭代，從最開始的單機，到雙機HA、虛擬化、分佈式、容器、再到上雲、雲原生、Service Mesh等。另外一方面業務需求也愈來愈複雜，從原來的注重用戶和業務的野蠻增加，到用戶的精細化運營，從增量市場到存量博弈，業務的複雜度愈來愈高，隨之也加劇了技術的複雜度。

下面說一說互聯網公司基礎架構的演進。

單機房

通常對於不少服務連續性要求不高，可用性要求沒那麼高的，好比公司內部的系統，不少就是單機房部署，有的甚至是單機部署。

安琪拉之前大學給老師搞的軟件，那時候用的C#寫的，本地部署，說簡單點就是直接在實驗室老師的電腦上部署好，整臺電腦（軟件帶硬件）一塊兒賣給人家的，由於只是工具軟件，數據都是保持在本地的，軟件卡了直接關機重啓，????。架構圖以下：

通常雖然是單機房，可是不少都是分佈式部署的，因此若是機房出現故障，就只能死等。

同城雙機房

單個機房在出現不可抗拒的問題（如斷電、斷網等因素）時，會致使沒法正常提供服務，會對業務形成潛在的損失。因此在金融級的高可用設計上，爲了不用戶損失，須要一種能夠基於同城或異地的多個不一樣機房之間的多活機制，在保障數據一致性的同時，可以最大程度下降因爲機房的單點可用所致使的潛在高可用問題。同城雙活就是其中的一種機制。

由於同城雙機房實際就是在一個城市，創建了二個機房，從物理位置上能夠離的足夠近，因此能夠在二個機房之間拉根專線，機房之間部署的系統能夠相互調用，接口層的DNS、四層設備、反向代理、網關/Web層能夠隨機路由。

有一個機房出現故障時，可在基本不丟失數據的狀況下進行應急切換，保持業務連續。邏輯架構圖以下：

若是從設計上，按服務維度拆分應用，應用之間用rpc服務調用連通，平臺層面設計服務治理的策略，服務可作水平擴展，彈性擴縮容，機房以前近似與同機房部署，內部服務路由策略能夠自由選擇，例如：輪詢、一致性哈希、同機房優先、sticky session、自定義路由規則等。

將業務系統拆分爲模塊化、標準化、鬆耦合、可插拔、可擴展的微服務架構。

存儲層以MySQL數據庫爲例，主從複製，主節點故障時候能夠手工或者自動切換從爲主，可是這種方案只是解決可用性問題，對於數據一致性是有損的，覺得這種架構設計一個時間點只有一個Master節點，目前更合理的設計是採用分佈式數據庫，利用Paxos、Raft分佈式多數派原則，好比存在5個Master節點，寫時須要3個節點都寫成功纔算成功，這樣經過一致性協議保證數據強一致。

二地三中心（異地主備）

由於出現某個城市出現洪澇、地震等天然災害，會出現城市級機房不可用的狀況，因此跨城機房就是避免這種狀況出現而產生，可是不少公司由於成本和服務可用性要求沒這麼高，沒有作異地主備。

這種架構模式是在同一個城市，弄二個機房，在另外一個城市弄一個備用機房，叫作同城雙活+異地災備，也是不少CTO經常提的兩地三中心。

通常跨城調用是有必定延遲的，上海杭州大概是30ms左右，通常異地主備主要仍是一個作主，另外一個主要起到數據備份，服務backup的功能，若是主機房服務出現可靠性問題，例如訪問成功率斷崖式下跌，能夠當即讓異地的備份機房當即切主，等到主機房故障恢復，再切回主機房。

備機房有點相似於主機房的鏡像，因此訪問層、服務層和存儲層都是獨立部署的。備機房訪問層和服務層一直會有health check，以及仿真流量，保證備機房服務隨時啓用的時候都是可用狀態，否則主機房掛了，啓用備用機房的時候發現備用機房也是不可用的，那就完蛋了。

同城雙活+異地災備雖然對可用性有幫助，對於可用性要求不高的不須要作這種架構。這種同城雙活+異地災備架構也有一些弊端：

1. 異地災備沒有業務流量，可是備份了二個主機房的全部業務數據，異地機房的機器容量、配置要求也不低，日常大部分狀況機器都是空跑的，利用率比較低，因此成本仍是比較高的。
2. 跨城同步仍是有必定延遲，若是平時沒有常常演練，即便主機房出故障，也不敢貿然切異地災備機房；每一年螞蟻5月份都有機房演練，好比直接把一個機房斷電，斷網，還有紅藍對抗，人爲故障注入。
3. 故障災備策略每每不是自動化的，不能一有業務異常就切備，因此決策仍是比較複雜的，通常也不會作出自動化的，須要測試演練，因此維護的成本、切換的風險也很高；
4. 由於主備資源系統的類似性，因此伸縮性很差，擴容困難，由於主備確定要一塊兒擴一塊兒縮容，服務和容量都要對應。

由於這些弊端的存在，就衍生了異地多活。

異地多活

異地多活指的是否是隻有同城的二個機房提供服務，物理地址不一樣的機房同時提供服務。

架構設計圖以下：

異地多活下，能夠按照就近原則，用戶訪問更快，如上圖，華東用戶就訪問上海機房，華南用戶就走深圳機房，時效性更好，若是機房出故障，路由層把流量切到異地機房。業務流量能夠自定義配置，不均等的分配到各個地域機房裏面。與異地單機房相比，

• 具有更快的恢復能力。流量動態分配，一個區域掛掉，流量能夠自由的在地域間調度、切換。

• 不用備份全站，成本更低。

• 數據異地backup，同機房也有數據備份，數據流量支持自定義，機房維度擴縮容更靈活，好比我能夠99%流量給到其中一個機房，把某個機房流量調到只剩1%，在雲環境中，可擴展性更好。

固然並非全部業務都須要作異地多活，對可用性有極致要求，核心應用，數據規模大的才優先作，不然整個技術複雜度也會比較複雜。

邏輯架構以下：

 

LDC 單元化

LDC 單元化架構是能夠實現異地多活和高併發場景的架構體系，LDC（Logic Data Center）邏輯數據中心是相對於傳統的 IDC（Internet Data Center）提出的。邏輯數據中心所表達的中心思想是不管物理結構如何的分佈，整個數據中心在邏輯上是協同和統一的。主要適用於大型互聯網公司在線交易系統支持，好比淘寶、支付寶、攜程等。

關於LDC架構，由於技術敏感方面緣由，我隱去一些信息，週末整理之後再發出來，這個是目前阿里雲和螞蟻採用的部署架構。