互聯網系統7*24小時不分晝夜的爲人民服務,那麼這樣長時間服務的背後究竟有哪些手段保證呢?linux
這其中包括軟硬件,及基礎設施的保障。程序員
軟件架構師在設計大型互聯網系統時考慮的高可用性是從分佈式系統的特色考慮的高可用。主要的思路就是在各個層面作冗餘,備份。web
訪問全部網頁的第一步,解析DNS, 全球十二個根服務器,從國家,骨幹網,各級運營商核心機房,省級機房,局站都有DNS緩存服務器,保證解析速度。固然,大型網站專門自建的DNS服務器也都是一組集羣。redis
提供服務的web應用只有一個服務器不安全,而部署一組一樣功能的服務器集羣就下降了單個服務器產生故障的風險。數據庫
一組在同一個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」轉載請註明。
若是以爲有趣,微信掃一掃關注公衆號。