互聯網 - 大數據

互聯網系統7*24小時不分晝夜的為人民服務，那么這樣長時間服務的背后究竟有哪些手段保證呢？

這其中包括軟硬件，及基礎設施的保障。

IT人的努力

分布式系統

軟件架構師在設計大型互聯網系統時考慮的高可用性是從分布式系統的特點考慮的高可用。主要的思路就是在各個層面做冗余，備份。

訪問所有網頁的第一步，解析DNS, 全球十二個根服務器，從國家，骨干網，各級運營商核心機房，省級機房，局站都有DNS緩存服務器，保證解析速度。當然，大型網站專門自建的DNS服務器也都是一組集群。

提供服務的web應用只有一個服務器不安全，而部署一組同樣功能的服務器集群就降低了單個服務器產生故障的風險。

IDC

一組在同一個IDC中的應用集群在IDC級別是單點（天朝經常遇到挖光纜，遭雷劈），要將應用集群跨機房部署，此時要求應用無狀態，可以隨意部署。

IDC的建設在國內有運營商（電信、聯通、移動）和第三方基礎設施提供商（如世紀互聯），由于國內的現實狀況，運營商提供的IDC網絡質量較好，但是不能提供多線互通；而第三方質量比較參差不齊，有好有壞，但能提供BGP多路接入，一般出口帶寬較小。

最高級的T3機房的設計要求一條就是要能抗8級地震，也就是跟幾年前汶川一樣的震級。

高可用軟件

Heartbeat與keeplived，此類軟件采用IP漂移技術，主要側重在做服務器的主備切換，在一些本身沒有集群功能支持的產品上，如早期Redis上能做簡單的主備高可用，并對應用本身無感知，簡化應用開發。如果單個一組主備的redis不能滿足容量需求，需要做Redis集群，則要用一些簡單工具庫人為對redis的讀寫進行分片（如jedis），此時集群維護成本變高，最好組件本身有原生的集群功能支持。

存儲

數據庫服務器用的硬盤使用raid10保證本地硬盤上的冗余，再通過linux LVM卷管理做本地存儲冗余備份，再通過存儲廠商的商業解決方案或自研技術將單IDC的數據復制到同城異地IDC的存儲系統中，保證如果源站IDC被毀（極端的地震，戰爭），在同城另一個機房仍有可恢復的備份。

當然如果有地震，那么同城容災就不夠了，還需要異地容災，因為地震通常是區域性的，杭州地震不會對上海機房有很大影響。

光在存儲上做異地容災是不夠的，如果是冷備，平時并沒有用起來，也沒有合理的機制做演練切換，真到了一個IDC故障需要將應用讀取切到備庫上去的時候，沒人心里有底敢做這個決策，尤其是金融系統，數據庫一旦出錯會對企業造成可能致命的資損故障。

可以參考工商銀行2013年6月23日波及全國的長時間停機故障，說明我國國有銀行IT信息化技術儲備仍然薄弱，主要解決方案還是被美國廠商綁架。

國企背景的辦事思路一般找500強咨詢公司要方案并實施，這樣負責人可以不用擔職業前途的風險，出問題了全部推到合作方身上，并不考慮自己能為企業提供什么價值，典型的官場思維，當然這是題外話了。這個問題現在運營商高層應該已經認識到了，能看到目前運營商的思路有了一些變化，開始在自營業務上做技術和人才的儲備了。

設備

常用的硬件負載均衡設備如F5，在設計上都是采用雙機冗余，心跳信號可以走設備串口或TCP。

一個4U的機架式服務器，都有冗余的電源設計（2+1，2+2,3+1）等，千兆網卡多塊。冗余的電源可以被芯片控制進行負載均衡，與程序員熟知的keeplived做的HA一樣，當一個電源不行時可以進行切換。

電力

云計算背景下，單機柜服務器部署密度的增加，對于電力的要求也越來越高，在一個部署了4到6個刀片服務器的機柜最高需要30kW的電力。

電力的冗余體現在UPS和柴油發電機上。并且大型數據中心采用兩路獨立供電路徑，保證一路電力掛掉后另一路仍能為整個數據中心進行供電。

用戶享受了

可以看到一個7*24小時的系統需要在方方面面上考慮系統的可用性, 軟件架構師要考慮在架構上支持容災；運維工程師要考慮機房網絡，服務器等能滿足業務需要；而IDC的建設要考慮選址（避開地震帶），電力供應，制冷等建筑規劃，能耗上的約束；設備廠家要考慮的是自己的產品能減少硬件故障宕機時間。

所有的努力，最終改變了人們的生活：

你可以坐在家里購物；快遞提供迅速的物流；用手機打車，叫外賣；不分白天黑夜的玩網絡游戲；隨時隨地用微信搶紅包；在便利店用手機付款；與爸媽遠程聊天。

程序員主宰世界！

文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」轉載請注明。
如果覺得有趣，微信掃一掃關注公眾號。