在《世界最大的PHP站點(diǎn) Facebook后臺技術(shù)探秘》一文中介紹了一個(gè)大型SNS網(wǎng)站的技術(shù)組成。今天我們繼續(xù)大型網(wǎng)站探秘，一起來探秘大型B2C網(wǎng)站的架構(gòu)技術(shù)。作為國內(nèi)最大的B2C網(wǎng)站，其網(wǎng)站架構(gòu)一直承載著數(shù)據(jù)量高速增長壓力，要保證良好的負(fù)載和流程的使用體驗(yàn)，一個(gè)可伸縮性的高性能網(wǎng)站架構(gòu)必不可少。

一、應(yīng)用無狀態(tài)

一個(gè)系統(tǒng)的伸縮性的好壞取決于應(yīng)用的狀態(tài)如何管理。試想一下，假如我們在session中保存了大量與客戶端的狀態(tài)信息的話，那么當(dāng)保存狀態(tài)信息的server宕機(jī)的時(shí)候，我們怎么辦？通常來說，我們都是通過集群來解決這個(gè)問題，而通常所說的集群，不僅有負(fù)載均衡，更重要的是要有失效恢復(fù)failover,比如tomcat采用的集群節(jié)點(diǎn)廣播復(fù)制，Jboss采用的配對復(fù)制等session狀態(tài)復(fù)制策略，但是集群中的狀態(tài)恢復(fù)也有其缺點(diǎn)，那就是嚴(yán)重影響了系統(tǒng)的伸縮性，系統(tǒng)不能通過增加更多的機(jī)器來達(dá)到良好的水平伸縮，因?yàn)榧汗?jié)點(diǎn)間session的通信會隨著節(jié)點(diǎn)的增多而開銷增大，因此要想做到應(yīng)用本身的伸縮性，我們需要保證應(yīng)用的無狀態(tài)性，這樣集群中的各個(gè)節(jié)點(diǎn)來說都是相同的，從而是的系統(tǒng)更好的水平伸縮。

上面說了無狀態(tài)的重要性，那么具體如何實(shí)現(xiàn)無狀態(tài)呢？此時(shí)一個(gè)session框架就會發(fā)揮作用了。一般通過cookie來實(shí)現(xiàn)，或者也可以采用集中式session管理來完成，說具體點(diǎn)就是多個(gè)無狀態(tài)的應(yīng)用節(jié)點(diǎn)連接一個(gè)session 服務(wù)器，session服務(wù)器將session保存到緩存中，session服務(wù)器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫，文件系統(tǒng)等等。

二、有效使用緩存

做互聯(lián)網(wǎng)應(yīng)用的兄弟應(yīng)該都清楚，緩存對于一個(gè)互聯(lián)網(wǎng)應(yīng)用是多么的重要，從瀏覽器緩存，反向代理緩存，頁面緩存，局部頁面緩存，對象緩存等等都是緩存應(yīng)用的場景。

一般來說緩存根據(jù)與應(yīng)用程序的遠(yuǎn)近程度不同可以分為：local cache 和 remote cache。一般系統(tǒng)中要么采用local cache，要么采用remote cache,兩者混合使用的話對于local cache和remote cache的數(shù)據(jù)一致性處理會變大比較麻煩。

在大部分情況下,我們所說到的緩存都是讀緩存,緩存還有另外一個(gè)類型:寫緩存。對于一些讀寫比不高，同時(shí)對數(shù)據(jù)安全性需求不高的數(shù)據(jù)，我們可以將其緩存起來從而減少對底層數(shù)據(jù)庫的訪問,比如統(tǒng)計(jì)商品的訪問次數(shù),統(tǒng)計(jì)API的調(diào)用量等等,可以采用先寫內(nèi)存緩存然后延遲持久化到數(shù)據(jù)庫，這樣可以大大減少對數(shù)據(jù)庫的寫壓力。

三、應(yīng)用拆分

首先，在說明應(yīng)用拆分之前，我們先來回顧一下一個(gè)系統(tǒng)從小變大的過程中遇到的一些問題，通過這些問題我們會發(fā)現(xiàn)拆分對于構(gòu)建一個(gè)大型系統(tǒng)是如何的重要。
系統(tǒng)剛上線初期，用戶數(shù)并不多，所有的邏輯也許都是放在一個(gè)系統(tǒng)中的，所有邏輯跑到一個(gè)進(jìn)程或者一個(gè)應(yīng)用當(dāng)中，這個(gè)時(shí)候因?yàn)楸容^用戶少，系統(tǒng)訪問量低，因此將全部的邏輯都放在一個(gè)應(yīng)用未嘗不可。但是，兄弟們都清楚，好景不長，隨著系統(tǒng)用戶的不斷增加，系統(tǒng)的訪問壓力越來越多，同時(shí)隨著系統(tǒng)發(fā)展，為了滿足用戶的需求，原有的系統(tǒng)需要增加新的功能進(jìn)來，系統(tǒng)變得越來越復(fù)雜的時(shí)候，我們會發(fā)現(xiàn)系統(tǒng)變得越來越難維護(hù)，難擴(kuò)展，同時(shí)系統(tǒng)伸縮性和可用性也會受到影響。那么這個(gè)時(shí)候我們?nèi)绾谓鉀Q這些問題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來的系統(tǒng)根據(jù)一定的標(biāo)準(zhǔn)，比如業(yè)務(wù)相關(guān)性等分為不同的子系統(tǒng)，不同的系統(tǒng)負(fù)責(zé)不同的功能，這樣切分以后，我們可以對單獨(dú)的子系統(tǒng)進(jìn)行擴(kuò)展和維護(hù)，從而提高系統(tǒng)的擴(kuò)展性和可維護(hù)性，同時(shí)我們系統(tǒng)的水平伸縮性scale out大大的提升了，因?yàn)槲覀兛梢杂嗅槍π缘膶毫Υ蟮淖酉到y(tǒng)進(jìn)行水平擴(kuò)展而不會影響到其它的子系統(tǒng)，而不會像拆分以前，每次系統(tǒng)壓力變大的時(shí)候，我們都需要對整個(gè)大系統(tǒng)進(jìn)行伸縮，而這樣的成本是比較大的，另外經(jīng)過切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當(dāng)某個(gè)子系統(tǒng)暫時(shí)不可用的時(shí)候，整體系統(tǒng)還是可用的，從而整體系統(tǒng)的可用性也大大增強(qiáng)了。

因此一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用，肯定是要經(jīng)過拆分，因?yàn)橹挥胁鸱至耍到y(tǒng)的擴(kuò)展性，維護(hù)性,伸縮性，可用性才會變的更好。但是拆分也給系統(tǒng)帶來了問題，就是子系統(tǒng)之間如何通信的問題，而具體的通信方式有哪些呢？一般有同步通信和異步通信，這里我們首先來說下同步通信，下面的主題“消息系統(tǒng)”會說到異步通信。既然需要通信，這個(gè)時(shí)候一個(gè)高性能的遠(yuǎn)程調(diào)用框架就顯得非常總要。
 
上面所說的都是拆分的好處，但是拆分以后必然的也會帶來新的問題，除了剛才說的子系統(tǒng)通信問題外，最值得關(guān)注的問題就是系統(tǒng)之間的依賴關(guān)系，因?yàn)橄到y(tǒng)多了，系統(tǒng)的依賴關(guān)系就會變得復(fù)雜，此時(shí)就需要更好的去關(guān)注拆分標(biāo)準(zhǔn)，比如能否將一些有依賴的系統(tǒng)進(jìn)行垂直化，使得這些系統(tǒng)的功能盡量的垂直，這也是目前公司正在做的系統(tǒng)垂直化，同時(shí)一定要注意系統(tǒng)之間的循環(huán)依賴，如果出現(xiàn)循環(huán)依賴一定要小心，因?yàn)檫@可能導(dǎo)致系統(tǒng)連鎖啟動失敗。

從上面可以看出，一個(gè)大型系統(tǒng)要想變得可維護(hù)，可擴(kuò)展，可伸縮，我們必須的對它進(jìn)行拆分，拆分必然也帶來系統(tǒng)之間如何通信以及系統(tǒng)之間依賴管理等問題。#p#

四、數(shù)據(jù)庫拆分

在前面“應(yīng)用拆分”主題中，我們提到了一個(gè)大型互聯(lián)網(wǎng)應(yīng)用需要進(jìn)行良好的拆分，而那里我們僅僅說了”應(yīng)用級別”的拆分，其實(shí)我們的互聯(lián)網(wǎng)應(yīng)用除了應(yīng)用級別的拆分以外，還有另外一個(gè)很重要的層面就是存儲如何拆分的。因此這個(gè)主題主要涉及到如何對存儲系統(tǒng)，通常就是所說的RDBMS進(jìn)行拆分。

確定了這個(gè)小節(jié)的主題之后，我們回顧一下，一個(gè)互聯(lián)網(wǎng)應(yīng)用從小變大的過程中遇到的一些問題，通過遇到的問題來引出我們拆分RDBMS的重要性。

系統(tǒng)剛開始的時(shí)候，因?yàn)橄到y(tǒng)剛上線，用戶不多，那個(gè)時(shí)候，所有的數(shù)據(jù)都放在了同一個(gè)數(shù)據(jù)庫中，這個(gè)時(shí)候因?yàn)橛脩羯賶毫π?，一個(gè)數(shù)據(jù)庫完全可以應(yīng)付的了，但是隨著運(yùn)營那些哥們辛苦的吶喊和拼命的推廣以后，突然有一天發(fā)現(xiàn)，oh,god,用戶數(shù)量突然變多了起來，隨之而來的就是數(shù)據(jù)庫這哥們受不了，它終于在某一天大家都和愜意的時(shí)候掛掉啦。此時(shí)，咱們搞技術(shù)的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)現(xiàn)原來是數(shù)據(jù)庫讀取壓力太大了，此時(shí)咱們都清楚是到了讀寫分離的時(shí)候，這個(gè)時(shí)候我們會配置一個(gè)server為master節(jié)點(diǎn)，然后配幾個(gè)salve節(jié)點(diǎn)，這樣以來通過讀寫分離，使得讀取數(shù)據(jù)的壓力分?jǐn)偟搅瞬煌膕alve節(jié)點(diǎn)上面，系統(tǒng)終于又恢復(fù)了正常，開始正常運(yùn)行了。但是好景還是不長，有一天我們發(fā)現(xiàn)master這哥們撐不住了，它負(fù)載老高了，汗流浹背，隨時(shí)都有翹掉的風(fēng)險(xiǎn)，這個(gè)時(shí)候就需要咱們垂直分區(qū)啦（也就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同的數(shù)據(jù)庫中，同時(shí)還可以針對商品信息的庫采用master，salve模式，OK，通過分庫以后，各個(gè)按照功能拆分的數(shù)據(jù)庫寫壓力被分擔(dān)到了不同的server上面，這樣數(shù)據(jù)庫的壓力終于有恢復(fù)到正常狀態(tài)。但是是不是這樣，我們就可以高枕無憂了呢？NO,這個(gè)NO，不是我說的，是前輩們通過經(jīng)驗(yàn)總結(jié)出來的，隨著用戶量的不斷增加，你會發(fā)現(xiàn)系統(tǒng)中的某些表會變的異常龐大，比如好友關(guān)系表，店鋪的參數(shù)配置表等，這個(gè)時(shí)候無論是寫入還是讀取這些表的數(shù)據(jù)，對數(shù)據(jù)庫來說都是一個(gè)很耗費(fèi)精力的事情，因此此時(shí)就需要我們進(jìn)行“水平分區(qū)”了（這就是俗話說的分表，或者說sharding）。

上面說了很多，無非就是告訴大家一個(gè)事實(shí)“數(shù)據(jù)庫是系統(tǒng)中最不容易scale out的一層”，一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用必然會經(jīng)過一個(gè)從單一DB server,到Master/salve,再到垂直分區(qū)（分庫），然后再到水平分區(qū)（分表，sharding）的過程，而在這個(gè)過程中，Master/salve 以及垂直分區(qū)相對比較容易，對應(yīng)用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個(gè)分區(qū)join查詢數(shù)據(jù)，如何平衡各個(gè)shards的負(fù)載等等，這個(gè)時(shí)候就需要一個(gè)通用的DAL框架來屏蔽底層數(shù)據(jù)存儲對應(yīng)用邏輯的影響，使得底層數(shù)據(jù)的訪問對應(yīng)用透明化。
 
五、異步通信

在”遠(yuǎn)程調(diào)用框架”的介紹中,我們說了一個(gè)大型的系統(tǒng)為了擴(kuò)展性和伸縮性方面的需求,肯定是要進(jìn)行拆分,但是拆分了以后,子系統(tǒng)之間如何通信就成了我們首要的問題,在”遠(yuǎn)程調(diào)用框架”小節(jié)中,我們說了同步通信在一個(gè)大型分布式系統(tǒng)中的應(yīng)用,那么這一小節(jié)我們就來說說異步通信。好了,既然說到了異步通信,那么”消息中間件”就要登場了,采用異步通信這其實(shí)也是關(guān)系到系統(tǒng)的伸縮性,以及最大化的對各個(gè)子系統(tǒng)進(jìn)行解耦。

說到異步通信，我們需要關(guān)注的一點(diǎn)是這里的異步一定是根據(jù)業(yè)務(wù)特點(diǎn)來的，一定是針對業(yè)務(wù)的異步，通常適合異步的場合是一些松耦合的通信場合，而對于本身業(yè)務(wù)上關(guān)聯(lián)度比較大的業(yè)務(wù)系統(tǒng)之間，我們還是要采用同步通信比較靠譜。

OK,那么下一步我們說說異步能給系統(tǒng)帶來什么樣子的好處。首先我們想想，假如系統(tǒng)有A和B兩個(gè)子系統(tǒng)構(gòu)成，假如A和B是同步通信的話，那么要想使得系統(tǒng)整體伸縮性提高必須同時(shí)對A和B進(jìn)行伸縮，這就影響了對整個(gè)系統(tǒng)進(jìn)行scale out。其次，同步調(diào)用還會影響到可用性，從數(shù)學(xué)推理的角度來說，A同步調(diào)用B，如果A可用，那么B可用，逆否命題就是如果B不可用，那么A也不可用，這將大大影響到系統(tǒng)可用性，再次，系統(tǒng)之間異步通信以后可以大大提高系統(tǒng)的響應(yīng)時(shí)間，使得每個(gè)請求的響應(yīng)時(shí)間變短，從而提高用戶體驗(yàn)，因此異步在提高了系統(tǒng)的伸縮性以及可用性的同時(shí)，也大大的增強(qiáng)了請求的響應(yīng)時(shí)間（當(dāng)然了，請求的總體處理時(shí)間也許不會變少）。
 
六、非結(jié)構(gòu)化數(shù)據(jù)存儲

在一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用當(dāng)中，我們會發(fā)現(xiàn)并不是所有的數(shù)據(jù)都是結(jié)構(gòu)化的，比如一些配置文件，一個(gè)用戶對應(yīng)的動態(tài)，以及一次交易的快照等信息，這些信息一般不適合保存到RDBMS中，它們更符合一種Key-value的結(jié)構(gòu)，另外還有一類數(shù)據(jù)，數(shù)據(jù)量非常的大，但是實(shí)時(shí)性要求不高，此時(shí)這些數(shù)據(jù)也需要通過另外的一種存儲方式進(jìn)行存儲，另外一些靜態(tài)文件，比如各個(gè)商品的圖片，商品描述等信息，這些信息因?yàn)楸容^大，放入RDBMS會引起讀取性能問題，從而影響到其它的數(shù)據(jù)讀取性能，因此這些信息也需要和其它信息分開存儲，而一般的互聯(lián)網(wǎng)應(yīng)用系統(tǒng)都會選擇把這些信息保存到分布式文件系統(tǒng)中。

隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)界從08年下半年開始逐漸流行了一個(gè)概念就是NOSQL。我們都知道根據(jù)CAP理論，一致性，可用性和分區(qū)容錯(cuò)性3者不能同時(shí)滿足，最多只能同時(shí)滿足兩個(gè)，我們傳統(tǒng)的關(guān)系數(shù)據(jù)采用了ACID的事務(wù)策略，而ACID的事務(wù)策略更加講究的是一種高一致性而降低了可用性的需求，但是互聯(lián)網(wǎng)應(yīng)用往往對可用性的要求要略高于一致性的需求，這個(gè)時(shí)候我們就需要避免采用數(shù)據(jù)的ACID事務(wù)策略，轉(zhuǎn)而采用BASE事務(wù)策略，BASE事務(wù)策略是基本可用性，事務(wù)軟狀態(tài)以及最終一致性的縮寫，通過BASE事務(wù)策略，我們可以通過最終一致性來提升系統(tǒng)的可用性，這也是目前很多NOSQL產(chǎn)品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，這些產(chǎn)品非常適合一些非結(jié)構(gòu)化的數(shù)據(jù)，比如key-value形式的數(shù)據(jù)存儲，并且這些產(chǎn)品有個(gè)很好的優(yōu)點(diǎn)就是水平伸縮性。目前公司也在研究和使用一些成熟的NOSQL產(chǎn)品。
     
七 監(jiān)控、預(yù)警系統(tǒng)

對于大型的系統(tǒng)來說，唯一可靠的就是系統(tǒng)的各個(gè)部分是不可靠。

因?yàn)橐粋€(gè)大型的分布式系統(tǒng)中勢必會涉及到各種各樣的設(shè)備，比如網(wǎng)絡(luò)交換機(jī)，普通PC機(jī)，各種型號的網(wǎng)卡，硬盤，內(nèi)存等等，而這些東東都在數(shù)量非常多的時(shí)候，出現(xiàn)錯(cuò)誤的概率也會變大，因此我們需要時(shí)時(shí)刻刻監(jiān)控系統(tǒng)的狀態(tài)，而監(jiān)控也有粒度的粗細(xì)之分，粒度粗一點(diǎn)的話，我們需要對整個(gè)應(yīng)用系統(tǒng)進(jìn)行監(jiān)控，比如目前的系統(tǒng)網(wǎng)絡(luò)流量是多少，內(nèi)存利用率是多少，IO，CPU的負(fù)載是多少，服務(wù)的訪問壓力是多少，服務(wù)的響應(yīng)時(shí)間是多少等這一系列的監(jiān)控，而細(xì)粒度一點(diǎn)的話，我們就需對比如應(yīng)用中的某個(gè)功能，某個(gè)URL的訪問量是多，每個(gè)頁面的PV是多少，頁面每天占用的帶寬是多少，頁面渲染時(shí)間是多少，靜態(tài)資源比如圖片每天占用的帶寬是多少等等進(jìn)行進(jìn)一步細(xì)粒度的監(jiān)控。因此一個(gè)監(jiān)控系統(tǒng)就變得必不可少了。

前面說了一個(gè)監(jiān)控系統(tǒng)的重要性，有了監(jiān)控系統(tǒng)以后，更重要的是要和預(yù)警系統(tǒng)結(jié)合起來，比如當(dāng)某個(gè)頁面訪問量增多的時(shí)候，系統(tǒng)能自動預(yù)警，某臺Server的CPU和內(nèi)存占用率突然變大的時(shí)候，系統(tǒng)也能自動預(yù)警，當(dāng)并發(fā)請求丟失嚴(yán)重的時(shí)候，系統(tǒng)也能自動預(yù)警等等，這樣以來通過監(jiān)控系統(tǒng)和預(yù)警系統(tǒng)的結(jié)合可以使得我們能快速響應(yīng)系統(tǒng)出現(xiàn)的問題，提高系統(tǒng)的穩(wěn)定性和可用性。

八、配置統(tǒng)一管理

一個(gè)大型的分布式應(yīng)用，一般都是有很多節(jié)點(diǎn)構(gòu)成的，如果每次一個(gè)新的節(jié)點(diǎn)加入都要更改其它節(jié)點(diǎn)的配置，或者每次刪除一個(gè)節(jié)點(diǎn)也要更改配置的話，這樣不僅不利于系統(tǒng)的維護(hù)和管理，同時(shí)也更加容易引入錯(cuò)誤。另外很多時(shí)候集群中的很多系統(tǒng)的配置都是一樣的，如果不進(jìn)行統(tǒng)一的配置管理，就需要再所有的系統(tǒng)上維護(hù)一份配置，這樣會造成配置的管理維護(hù)很麻煩，而通過一個(gè)統(tǒng)一的配置管理可以使得這些問題得到很好的解決，當(dāng)有新的節(jié)點(diǎn)加入或者刪除的時(shí)候，配置管理系統(tǒng)可以通知各個(gè)節(jié)點(diǎn)更新配置，從而達(dá)到所有節(jié)點(diǎn)的配置一致性，這樣既方便也不會出錯(cuò)。
 

【編輯推薦】

1. 淘寶Open API初學(xué)者入門教程
2. 淘寶試運(yùn)行開放平臺 獨(dú)立開發(fā)者成主角
3. 對話阿里架構(gòu)師：走進(jìn)SaaS應(yīng)用開發(fā)
4. 大型網(wǎng)站架構(gòu)演變和知識體系
5. 視頻專題：大型網(wǎng)站架構(gòu)技術(shù)專家堂

本文轉(zhuǎn)載自狂放不羈的博客，原文標(biāo)題：構(gòu)建可伸縮，高性能的互聯(lián)網(wǎng)應(yīng)用。