知名網(wǎng)站的技術(shù)實(shí)現

　　在上一篇《知名網(wǎng)站的技術(shù)發(fā)展歷程》中，介紹了一些知名網(wǎng)站在發(fā)展的過(guò)程中技術(shù)的演變，在這篇文章中則會(huì )根據這些網(wǎng)站的發(fā)展經(jīng)驗，來(lái)總結通常網(wǎng)站是如何來(lái)應對可伸縮性、可用性、高性能以及低成本這四方面的挑戰的。

　　在上一篇文章中，介紹了一些Alexa排名較前的網(wǎng)站的技術(shù)發(fā)展歷程，在這篇文章中，將結合提及到的網(wǎng)站的技術(shù)發(fā)展歷程，來(lái)總結下網(wǎng)站在可伸縮性、可用性、高性能以及低成本四點(diǎn)上通常采用的技術(shù)。

　　對于一個(gè)網(wǎng)站而言，最重要的是要支撐住不斷增長(cháng)的訪(fǎng)問(wèn)量和數據量，如果能做到簡(jiǎn)單的增加機器即可支撐，那自然是最好的，但這就要求技術(shù)上必須付出一定的努力，這也是網(wǎng)站都追求的可伸縮性(Scalability)，而在做到可伸縮性后，不斷增加的機器也帶來(lái)了成本的上升，因此發(fā)展到了一定規模后，成本也會(huì )成為關(guān)注的重點(diǎn)。

　　除了可伸縮性外，可用性對于各網(wǎng)站而言也非常重要，一個(gè)經(jīng)常不能使用的網(wǎng)站必被用戶(hù)拋棄，這也是為什么各網(wǎng)站都很強調全年的可用性。

　　除了上面這三點(diǎn)外，還有另外一點(diǎn)影響也很明顯，就是性能，美國的一個(gè)對網(wǎng)站訪(fǎng)問(wèn)速度的調查數據：1/4的用戶(hù)因為一個(gè)網(wǎng)站載入的時(shí)間超過(guò)4秒而放棄這個(gè)網(wǎng)站，50%的手機用戶(hù)會(huì )放棄一個(gè)超過(guò)10秒還沒(méi)載入完成的網(wǎng)站，其中的3/5用戶(hù)將不再光顧這個(gè)網(wǎng)站，而Google對其數據分析后，發(fā)現搜索結果只要慢1/4秒，一天的搜索量就要減少800萬(wàn)。

　　可伸縮

　　可伸縮分為垂直伸縮和水平伸縮，垂直伸縮為通過(guò)升級機器的硬件來(lái)解決問(wèn)題，水平伸縮為通過(guò)增加機器來(lái)解決問(wèn)題，不同網(wǎng)站在可伸縮上采用了不同的策略，例如Google完全依賴(lài)水平伸縮來(lái)解決問(wèn)題，而其他網(wǎng)站多數是先依賴(lài)垂直伸縮來(lái)解決數據存儲的問(wèn)題。

　　垂直伸縮要求的是軟件上要能在硬件升級的情況下，發(fā)揮出硬件的能力，例如可配置的并行數、內存等，硬件的發(fā)展速度非常迅猛，網(wǎng)站的機器的配置自然也是每年都在升級，因此其實(shí)我們的軟件時(shí)刻都在被檢驗是否能垂直伸縮。

　　水平伸縮主要要解決的是如何做到僅通過(guò)增加機器就解決問(wèn)題，主要又分成了應用層和存儲層兩個(gè)層次來(lái)解決。

　　在應用層要做到水平伸縮，通常采用的策略是Share Nothing/Stateless，狀態(tài)信息放入客戶(hù)端或存儲層(例如用戶(hù)的Session信息放入Cookie，或放入服務(wù)器端的緩存系統)，應用系統做到了無(wú)狀態(tài)，那么在訪(fǎng)問(wèn)量上漲后只需要增加機器即可，在應用系統由單臺增加到多臺組成Cluster時(shí)，這時(shí)就會(huì )有負載均衡的引入，可能是硬件的也可能是軟件的。

　　在應用層的結構演變上，我們會(huì )發(fā)現，隨著(zhù)網(wǎng)站的不斷發(fā)展，以上提到的各家網(wǎng)站在應用層上最后形成的結構幾乎都完全一樣，均為前端Web系統Cluster + Services Cluster，前端Web系統和Services到了一定的階段后通常又會(huì )按照一定的規則來(lái)進(jìn)行拆分，如按業(yè)務(wù)領(lǐng)域等，可見(jiàn)SOA其實(shí)在大網(wǎng)站中是落地了的，而不像企業(yè)領(lǐng)域中宣傳的那么虛。

　　在存儲層要做到水平伸縮，難度就比應用層大多了，從前面各家網(wǎng)站的發(fā)展歷程也可看出，很多時(shí)候都在解決存儲層的問(wèn)題，而且可以看出，很多網(wǎng)站由于業(yè)務(wù)發(fā)展的壓力較大，一開(kāi)始都會(huì )選擇采用垂直伸縮的方式來(lái)解決存儲層的問(wèn)題。

　　存儲層主要是Cache、文件和數據三種類(lèi)型。

　　Cache可以看到基本上各家網(wǎng)站都采用了Memcache來(lái)保證伸縮性，在規模大了，也會(huì )碰到一些問(wèn)題，具體可以看看facebook所做的改造，現在也有些網(wǎng)站開(kāi)始采用redis了，但redis本身不具備可伸縮性，需要自行進(jìn)行改造。

　　文件的存儲可以看到各家網(wǎng)站都采用了分布式文件系統來(lái)保證伸縮性，思路多數都源于GFS，但由于存儲的文件的大小不同、對響應時(shí)間和吞吐量的要求不同，各家網(wǎng)站可能都各自實(shí)現。

　　數據的存儲上可以看到各家網(wǎng)站基本都采用了分庫分表的策略，分庫分表后由于很多關(guān)系型數據庫的特性(例如自增ID、join、事務(wù)等)都難以再使用了，對應用的設計會(huì )帶來(lái)一些挑戰，不過(guò)最大難點(diǎn)還是在于需要根據業(yè)務(wù)來(lái)考慮如何分是合適的，在最近幾年也有一些網(wǎng)站開(kāi)始采用NoSQL來(lái)更好的做到數據存儲的可伸縮性。

　　存儲層為了做到可伸縮性，通常采用的方案是單點(diǎn)寫(xiě)(是指在某個(gè)粒度的單點(diǎn)，例如對HBase而言，是單行數據一定是在同一臺機器上進(jìn)行寫(xiě)操作)，但讀可能是多點(diǎn)，讀多點(diǎn)的話(huà)主要要考慮不一致的問(wèn)題，無(wú)論讀是單點(diǎn)還是多點(diǎn)，數據都會(huì )在軟件層面做到寫(xiě)多份，策略主要有同步寫(xiě)多份、投票寫(xiě)多份、異步復制最終一致等(例如HDFS、Cassandra、Zookeeper)，采用自動(dòng)分裂的方法來(lái)實(shí)現數據量增長(cháng)時(shí)的自動(dòng)伸縮，采用一致性hash或根據某種規則的自動(dòng)balance策略等來(lái)實(shí)現機器增減時(shí)的相應處理，同時(shí)也需要有感知機器增減的方法(例如采用zookeeper)。

　　從上面可以看到存儲層上要做到可伸縮，技術(shù)上的難點(diǎn)很多，這也是為什么大規模的網(wǎng)站都不在數據庫上做復雜的運算，而只是把其當做一種存儲來(lái)使用，例如存儲過(guò)程這種就更是基本不會(huì )出現了，以降低數據庫的壓力。

　　除了應用層和存儲層需要做到可伸縮外，硬件層面的可伸縮在設計系統時(shí)也是需要考慮的，例如硬件負載設備只能支撐到一定的流量，同樣也需要考慮如何讓其能夠可伸縮。

　　除了盡可能做到系統可伸縮外，減少對系統的壓力也是緩解系統的可伸縮面臨挑戰的方法，例如批量提交、最終一致、youtube提到的“欺騙”、適當的正確性等策略。

　　可伸縮性是網(wǎng)站從小到大要經(jīng)歷的第一關(guān)挑戰，而且隨著(zhù)網(wǎng)站的不斷發(fā)展，還要不斷的做技術(shù)改造才能保證網(wǎng)站在每個(gè)不同的階段(例如同機房階段、同城多機房階段、異地多機房階段)都具備優(yōu)秀的可伸縮性，不過(guò)幸運的是不同階段的可伸縮性方案都已經(jīng)比較成熟。

　　可用性

　　可伸縮性保證了網(wǎng)站在不斷增長(cháng)的訪(fǎng)問(wèn)量和數據量的情況下生存下來(lái)，這也一定程度保證了網(wǎng)站的可用性，但除了這點(diǎn)外，要保障系統的可用性，還得付出很多的努力。

　　在設計高可用性的系統時(shí)，避免單點(diǎn)是其中最重要的一點(diǎn)，通常采用主備和集群的方法來(lái)避免單點(diǎn)，例如負載均衡設備、MySQL等通常采用主備的方式，在BigTable里采取了一種比較特殊的方法來(lái)避免Tablet Server的單點(diǎn)：通過(guò)Chubby來(lái)感知Tablet Server的健康狀況，如發(fā)現Tablet Server掛掉了，則由Master將此Tablet Server負責的Tablet遷移到其他的Tablet Servers上。

原文轉自：http://bluedavy.me/?p=396