時間過得很快，來淘寶已經(jīng)兩個月了，在這兩個月的時間里，自己也感受頗深。下面就結(jié)合淘寶目前的一些底層技術(shù)框架以及自己的一些感觸來說說如何構(gòu)建一個可 伸縮，高性能，高可用性的分布式互聯(lián)網(wǎng)應用。
一 應用無狀態(tài)（淘寶session框架）
俗話說，一個系 統(tǒng)的伸縮性的好壞取決于應用的狀態(tài)如何管理。為什么這么說呢？咱們試想一下，假如我們在session中保存了大量與客戶端的狀態(tài)信 息的話，那么當保存狀態(tài)信息的server宕機的時候，我們怎么辦？通常來說，我們都是通過集群來解決這個問題，而通常 所說的集群，不僅有負載均衡，更重要的是要有失效恢復failover,比如tomcat采 用的集群節(jié)點廣播復制，jboss采 用的配對復制等session狀 態(tài)復制策略，但是集群中的狀態(tài)恢復也有其缺點，那就是嚴重影響了系統(tǒng)的伸縮性，系統(tǒng)不能通過增加更多的機器來達到良好的水平伸縮，因為集群節(jié)點間session的 通信會隨著節(jié)點的增多而開銷增大，因此要想做到應用本身的伸縮性，我們需要保證應用的無狀態(tài)性，這樣集群中的各個節(jié)點來說都是相同的，從而是的系統(tǒng)更好的 水平伸縮。
OK， 上面說了無狀態(tài)的重要性，那么具體如何實現(xiàn)無狀態(tài)呢？此時一個session框架就會發(fā)揮作用了。幸運的是淘 寶已經(jīng)具有了此類框架。淘寶的session框架采用的是client cookie實現(xiàn)，主要將狀態(tài) 保存到了cookie里 面，這樣就使得應用節(jié)點本身不需要保存任何狀態(tài)信息，這樣在系統(tǒng)用戶變多的時候，就可以通過增加更多的應用節(jié)點來達到水平擴展的目的.但 是采用客戶端cookie的 方式來保存狀態(tài)也會遇到限制，比如每個cookie一般不能超過4K的大小，同時很多瀏覽器都限制一個站點最 多保存20個cookie.淘 寶cookie框 架采用的是“多值cookie”， 就是一個組合鍵對應多個cookie的 值，這樣不僅可以防止cookie數(shù) 量超過20， 同時還節(jié)省了cookie存 儲有效信息的空間，因為默認每個cookie都會有大約50個字節(jié)的元信息來描述cookie。
除 了淘寶目前的session框 架的實現(xiàn)方式以外，其實集中式session管理來完成，說具體點就是多個無狀態(tài)的應用節(jié)點連接一個session 服 務器，session服 務器將session保 存到緩存中，session服 務器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫，文件系統(tǒng)等等。
二 有效使用緩存（Tair）
做互聯(lián)網(wǎng)應用的兄弟應該都清楚，緩存對于一個互聯(lián)網(wǎng)應用是多么的重要，從瀏覽器緩存，反向代理緩存，頁面緩存，局部頁面緩存，對象緩存等等都是緩存應用的場 景。
一般來說緩存根據(jù)與應用程序的遠近程度不同可以分為：local cache 和 remote cache。 一般系統(tǒng)中要么采用local cache，要么采用remote cache,兩者混合使用的話對 于local cache和remote cache的數(shù)據(jù)一致性處理會變 大比較麻煩.
在大部分情況下,我 們所說到的緩存都是讀緩存,緩存還有另外一個類型:寫緩存. 對 于一些讀寫比不高，同時對數(shù)據(jù)安全性需求不高的數(shù)據(jù)，我們可以將其緩存起來從而減少對底層數(shù)據(jù)庫的訪問,比如 統(tǒng)計商品的訪問次數(shù),統(tǒng) 計API的 調(diào)用量等等,可 以采用先寫內(nèi)存緩存然后延遲持久化到數(shù)據(jù)庫，這樣可以大大減少對數(shù)據(jù)庫的寫壓力。
OK， 我以店鋪線的系統(tǒng)為例，在用戶瀏覽店鋪的時候，比如店鋪介紹，店鋪交流區(qū)頁面，店鋪服務條款頁面，店鋪試衣間頁面，以及店鋪內(nèi)搜索界面這些界面更新不是非 常頻繁，因此適合放到緩存中，這樣可以大大減低DB的負載。另外寶貝詳情頁面相對也更新比較 少，因此也適合放到緩存中來減低DB負載。
三 應用拆分（HSF）
首 先，在說明應用拆分之前，我們先來回顧一下一個系統(tǒng)從小變大的過程中遇到的一些問題，通過這些問題我們會發(fā)現(xiàn)拆分對于構(gòu)建一個大型系統(tǒng)是如何的重要。
系 統(tǒng)剛上線初期，用戶數(shù)并不多，所有的邏輯也許都是放在一個系統(tǒng)中的，所有邏輯跑到一個進程或者一個應用當中，這個時候因為比較用戶少，系統(tǒng)訪問量低，因此 將全部的邏輯都放在一個應用未嘗不可。但是，兄弟們都清楚，好景不長，隨著系統(tǒng)用戶的不斷增加，系統(tǒng)的訪問壓力越來越多，同時隨著系統(tǒng)發(fā)展，為了滿足用戶 的需求，原有的系統(tǒng)需要增加新的功能進來，系統(tǒng)變得越來越復雜的時候，我們會發(fā)現(xiàn)系統(tǒng)變得越來越難維護，難擴展，同時系統(tǒng)伸縮性和可用性也會受到影響。那 么這個時候我們?nèi)绾谓鉀Q這些問題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來的系統(tǒng)根據(jù)一定的標準，比如業(yè)務相關(guān)性等分為不同的子系統(tǒng)， 不同的系統(tǒng)負責不同的功能，這樣切分以后，我們可以對單獨的子系統(tǒng)進行擴展和維護，從而提高系統(tǒng)的擴展性和可維護性，同時我們系統(tǒng)的水平伸縮性scale out大 大的提升了，因為我們可以有針對性的對壓力大的子系統(tǒng)進行水平擴展而不會影響到其它的子系統(tǒng)，而不會像拆分以前，每次系統(tǒng)壓力變大的時候，我們都需要對整 個大系統(tǒng)進行伸縮，而這樣的成本是比較大的，另外經(jīng)過切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當某個子系統(tǒng)暫時不可用的時候，整體系統(tǒng)還是可用的，從而整 體系統(tǒng)的可用性也大大增強了。
因 此一個大型的互聯(lián)網(wǎng)應用，肯定是要經(jīng)過拆分，因為只有拆分了，系統(tǒng)的擴展性，維護性,伸 縮性，可用性才會變的更好。但是拆分也給系 統(tǒng)帶來了問題，就是子系統(tǒng)之間如何通信的問題，而具體的通信方式有哪些呢？一般有同步通信和異步通信，這里我們首先來說下同步通信，下面的主題“消息系 統(tǒng)”會說到異步通信。既然需要通信，這個時候一個高性能的遠程調(diào)用框架就顯得非?？傄玻虼嗽蹅兲詫氁灿辛俗约旱?/span>HSF框 架。
上 面所說的都是拆分的好處，但是拆分以后必然的也會帶來新的問題，除了剛才說的子系統(tǒng)通信問題外，最值得關(guān)注的問題就是系統(tǒng)之間的依賴關(guān)系，因為系統(tǒng)多了， 系統(tǒng)的依賴關(guān)系就會變得復雜，此時就需要更好的去關(guān)注拆分標準，比如能否將一些有依賴的系統(tǒng)進行垂直化，使得這些系統(tǒng)的功能盡量的垂直，這也是目前淘寶正 在做的系統(tǒng)垂直化，同時一定要注意系統(tǒng)之間的循環(huán)依賴，如果出現(xiàn)循環(huán)依賴一定要小心，因為這可能導致系統(tǒng)連鎖啟動失敗。
OK， 既然明白了拆分的重要性，我們看看隨著淘寶的發(fā)展，淘寶本身是如何拆分系統(tǒng)的。
首 先我們來看以下這個圖：
從 上面的圖可以看出淘寶系統(tǒng)的一個演變過程，在這個演變的過程中，我們所說的拆分就出現(xiàn)V2.2和V3.0之 間。在V2.2版 本中，淘寶幾乎所有的邏輯都放在(Denali)系統(tǒng)中，這樣導致的問題就是系統(tǒng)擴展和修改非常麻煩，并且更加致命的是隨 著淘寶業(yè)務量的增加，如果按照V2.2的架構(gòu)已經(jīng)沒有辦法支撐以后淘寶的快速發(fā)展，因此大家決定對整個系統(tǒng)進行拆分，最 終V3.0版 本的淘寶系統(tǒng)架構(gòu)圖如下：
從 上圖可以看出V3.0版 本的系統(tǒng)對整個系統(tǒng)進行了水平和垂直兩個方向的拆分，水平方向上，按照功能分為交易，評價，用戶，商品等系統(tǒng)，同樣垂直方向上，劃分為業(yè)務系統(tǒng)，核心業(yè)務 系統(tǒng)以及以及基礎(chǔ)服務，這樣以來，各個系統(tǒng)都可以獨立維護和獨立的進行水平伸縮，比如交易系統(tǒng)可以在不影響其它系統(tǒng)的情況下獨立的進行水平伸縮以及功能擴 展。
從上面可以看出，一個大型系統(tǒng)要想變得可維 護，可擴展，可伸縮，我們必須的對它進行拆分，拆分必然也帶來系統(tǒng)之間如何通信以及系統(tǒng)之間依賴管理等問題，關(guān)于通信方面，淘寶目前獨立開發(fā)了自己的高性 能服務框架HSF， 此框架主要解決了淘寶目前所有子系統(tǒng)之間的同步和異步通信（目前HSF主要用于同步場合，FutureTask方 式的調(diào)用場景還比較少）。至于系統(tǒng)間的依賴管理，目前淘寶還做的不夠好，這應該也是我們以后努力解決的問題。
四 數(shù)據(jù)庫拆分（TDDL）
在 前面“應用拆分”主題中，我們提到了一個大型互聯(lián)網(wǎng)應用需要進行良好的拆分，而那里我們僅僅說了”應用級別”的拆 分，其實我們的互聯(lián)網(wǎng)應用除了應用級別的拆分以外，還有另外一個很重要的層面就是存儲如何拆分的。因此這個主題主要涉及到如何對存儲系統(tǒng)，通常就是所說的RDBMS進 行拆分。
好 了，確定了這個小節(jié)的主題之后，我們回顧一下，一個互聯(lián)網(wǎng)應用從小變大的過程中遇到的一些問題，通過遇到的問題來引出我們拆分RDBMS的 重要性。
系 統(tǒng)剛開始的時候，因為系統(tǒng)剛上線，用戶不多，那個時候，所有的數(shù)據(jù)都放在了同一個數(shù)據(jù)庫中，這個時候因為用戶少壓力小，一個數(shù)據(jù)庫完全可以應付的了，但是 隨著運營那些哥們辛苦的吶喊和拼命的推廣以后，突然有一天發(fā)現(xiàn)，oh,god,用戶數(shù)量突然變多了起來，隨之而 來的就是數(shù)據(jù)庫這哥們受不了，它終于在某一天大家都和愜意的時候掛掉啦。此時，咱們搞技術(shù)的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)現(xiàn)原來是數(shù)據(jù) 庫讀取壓力太大了，此時咱們都清楚是到了讀寫分離的時候，這個時候我們會配置一個server為master節(jié) 點，然后配幾個salve節(jié) 點，這樣以來通過讀寫分離，使得讀取數(shù)據(jù)的壓力分攤到了不同的salve節(jié)點上面，系統(tǒng)終于又恢復了正常，開 始正常運行了。但是好景還是不長，有一天我們發(fā)現(xiàn)master這哥們撐不住了，它負載老高了，汗 流浹背，隨時都有翹掉的風險，這個時候就需要咱們垂直分區(qū)啦（也就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同的數(shù)據(jù)庫中，同時還 可以針對商品信息的庫采用master，salve模式，OK， 通過分庫以后，各個按照功能拆分的數(shù)據(jù)庫寫壓力被分擔到了不同的server上面，這樣數(shù)據(jù)庫的壓力終于有恢復 到正常狀態(tài)。但是是不是這樣，我們就可以高枕無憂了呢？NO,這個NO， 不是我說的，是前輩們通過經(jīng)驗總結(jié)出來的，隨著用戶量的不斷增加，你會發(fā)現(xiàn)系統(tǒng)中的某些表會變的異常龐大，比如好友關(guān)系表，店鋪的參數(shù)配置表等，這個時候 無論是寫入還是讀取這些表的數(shù)據(jù)，對數(shù)據(jù)庫來說都是一個很耗費精力的事情，因此此時就需要我們進行“水平分區(qū)”了（這就是俗話說的分表，或者說sharding）.
OK,上 面說了一大堆，無非就是告訴大家一個事實“數(shù)據(jù)庫是系統(tǒng)中最不容易scale out的一層”，一個大型的互聯(lián)網(wǎng) 應用必然會經(jīng)過一個從單一DB server,到Master/salve,再到垂直分區(qū)（分 庫），然后再到水平分區(qū)（分表，sharding）的過程，而在這個過程中，Master/salve 以 及垂直分區(qū)相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區(qū)join查 詢數(shù)據(jù)，如何平衡各個shards的 負載等等，這個時候就需要一個通用的DAL框架來屏蔽底層數(shù)據(jù)存儲對應用邏輯的影響，使得底層數(shù)據(jù)的訪問對應用透明化。
拿 淘寶目前的情況來說，淘寶目前也正在從昂貴的高端存儲（小型機+ORACLE）切換到MYSQL,切 換到MYSQL以 后，勢必會遇到垂直分區(qū)（分庫）以及水平分區(qū)（Sharding）的問題，因此目前淘寶根據(jù)自 己的業(yè)務特點也開發(fā)了自己的TDDL框架，此框架主要解決了分庫分表對應用的透明化以及異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)復制。
五 異步通信（Notify）
在”遠 程調(diào)用框架”的 介紹中,我 們說了一個大型的系統(tǒng)為了擴展性和伸縮性方面的需求,肯定是要進行拆分,但是 拆分了以后,子 系統(tǒng)之間如何通信就成了我們首要的問題,在”遠程調(diào)用框架”小節(jié) 中,我 們說了同步通信在一個大型分布式系統(tǒng)中的應用,那么這一小節(jié)我們就來說說異步通信.好了,既 然說到了異步通信,那 么”消 息中間件”就 要登場了,采 用異步通信這其實也是關(guān)系到系統(tǒng)的伸縮性,以及最大化的對各個子系統(tǒng)進行解耦.
說 到異步通信，我們需要關(guān)注的一點是這里的異步一定是根據(jù)業(yè)務特點來的，一定是針對業(yè)務的異步，通常適合異步的場合是一些松耦合的通信場合，而對于本身業(yè)務 上關(guān)聯(lián)度比較大的業(yè)務系統(tǒng)之間，我們還是要采用同步通信比較靠譜。
OK,那 么下一步我們說說異步能給系統(tǒng)帶來什么樣子的好處。首先我們想想，假如系統(tǒng)有A和B兩個 子系統(tǒng)構(gòu)成，假如A和B是 同步通信的話，那么要想使得系統(tǒng)整體伸縮性提高必須同時對A和B進行 伸縮，這就影響了對整個系統(tǒng)進行scale out.其次，同步調(diào)用還會影響到可用性，從數(shù)學推理的角度來說，A同 步調(diào)用B， 如果A可 用，那么B可 用，逆否命題就是如果B不 可用，那么A也 不可用，這將大大影響到系統(tǒng)可用性，再次，系統(tǒng)之間異步通信以后可以大大提高系統(tǒng)的響應時間，使得每個請求的響應時間變短，從而提高用戶體驗，因此異步在 提高了系統(tǒng)的伸縮性以及可用性的同時，也大大的增強了請求的響應時間（當然了，請求的總體處理時間也許不會變少）。
下 面我們就以淘寶的業(yè)務來看看異步在淘寶的具體應用。交易系統(tǒng)會與很多其它的業(yè)務系統(tǒng)交 互，如果在一次交易過程中采用同步調(diào)用的話，這就要求要向交易成功，必須依賴的所有系統(tǒng)都可用，而如果采用異步通信以后，交易系 統(tǒng)借助于消息中間件Notify和 其它的系統(tǒng)進行了解耦，這樣以來當其它的系統(tǒng)不可用的時候，也不會影響到某此交易，從而提高了系統(tǒng)的可用性。
最后，關(guān)于異步方面的討論，我可以 推薦大家一些資源：
1 . J2EE meets web2.0
2. Ebay架構(gòu)特點(HPTS 2009)
六 非結(jié)構(gòu)化數(shù)據(jù)存儲 ( TFS,NOSQL)
在 一個大型的互聯(lián)網(wǎng)應用當中，我們會發(fā)現(xiàn)并不是所有的數(shù)據(jù)都是結(jié)構(gòu)化的，比如一些配置文件，一個用戶對應的動態(tài)，以及一次交易的快照等信息，這些信息一般不 適合保存到RDBMS中， 它們更符合一種Key-value的 結(jié)構(gòu)，另外還有一類數(shù)據(jù)，數(shù)據(jù)量非常的大，但是實時性要求不高，此時這些數(shù)據(jù)也需要通過另外的一種存儲方式進行存儲，另外一些靜態(tài)文件，比如各個商品的圖 片，商品描述等信息，這些信息因為比較大，放入RDBMS會引起讀取性能問題，從而影響到其它 的數(shù)據(jù)讀取性能，因此這些信息也需要和其它信息分開存儲，而一般的互聯(lián)網(wǎng)應用系統(tǒng)都會選擇把這些信息保存到分布式文件系統(tǒng)中，因此淘寶目前也開發(fā)了自己的 分布式文件系統(tǒng)TFS，TFS目 前限制了文件大小為2M， 適合于一些小于2M數(shù) 據(jù)的存放。
隨 著互聯(lián)網(wǎng)的發(fā)展，業(yè)界從08年 下半年開始逐漸流行了一個概念就是NOSQL。我們都知道根據(jù)CAP理論，一致性，可用性和分區(qū)容錯性3者 不能同時滿足，最多只能同時滿足兩個，我們傳統(tǒng)的關(guān)系數(shù)據(jù)采用了ACID的事務策略，而ACID的 事務策略更加講究的是一種高一致性而降低了可用性的需求，但是互聯(lián)網(wǎng)應用往往對可用性的要求要略高于一致性的需求，這個時候我們就需要避免采用數(shù)據(jù)的ACID事 務策略，轉(zhuǎn)而采用BASE事 務策略，BASE事 務策略是基本可用性，事務軟狀態(tài)以及最終一致性的縮寫，通過BASE事務策略，我們可以通過最終一致性來提 升系統(tǒng)的可用性，這也是目前很多NOSQL產(chǎn)品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，這些產(chǎn)品非常適合一些非結(jié)構(gòu)化的數(shù)據(jù)，比如key-value形 式的數(shù)據(jù)存儲，并且這些產(chǎn)品有個很好的優(yōu)點就是水平伸縮性。目前淘寶也在研究和使用一些成熟的NOSQL產(chǎn)品。
七 監(jiān)控、預警系統(tǒng)
對于大型的系統(tǒng) 來說，唯一可靠的就是系統(tǒng)的各個部分是不可靠。
因 為一個大型的分布式系統(tǒng)中勢必會涉及到各種各樣的設備，比如網(wǎng)絡交換機，普通PC機，各種型號的網(wǎng)卡，硬盤，內(nèi)存等等，而這 些東東都在數(shù)量非常多的時候，出現(xiàn)錯誤的概率也會變大，因此我們需要時時刻刻監(jiān)控系統(tǒng)的狀態(tài)，而監(jiān)控也有粒度的粗細之分，粒度粗一點的話，我們需要對整個 應用系統(tǒng)進行監(jiān)控，比如目前的系統(tǒng)網(wǎng)絡流量是多少，內(nèi)存利用率是多少，IO，CPU的 負載是多少，服務的訪問壓力是多少，服務的響應時間是多少等這一系列的監(jiān)控，而細粒度一點的話，我們就需對比如應用中的某個功能，某個URL的 訪問量是多，每個頁面的PV是 多少，頁面每天占用的帶寬是多少，頁面渲染時間是多少，靜態(tài)資源比如圖片每天占用的帶寬是多少等等進行進一步細粒度的監(jiān)控。因此一個監(jiān)控系統(tǒng)就變得必不可 少了。
前 面說了一個監(jiān)控系統(tǒng)的重要性，有了監(jiān)控系統(tǒng)以后，更重要的是要和預警系統(tǒng)結(jié)合起來，比如當某個頁面訪問量增多的時候，系統(tǒng)能自動預警，某臺Server的CPU和 內(nèi)存占用率突然變大的時候，系統(tǒng)也能自動預警，當并發(fā)請求丟失嚴重的時候，系統(tǒng)也能自動預警等等，這樣以來通過監(jiān)控系統(tǒng)和預警系統(tǒng)的結(jié)合可以使得我們能快 速響應系統(tǒng)出現(xiàn)的問題，提高系統(tǒng)的穩(wěn)定性和可用性。
八 配置統(tǒng)一管理
一 個大型的分布 式應用，一般都是有很多節(jié)點構(gòu)成的，如果每次一個新的節(jié)點加入都要更改其它節(jié)點的配置，或者每次刪除一個節(jié)點也要更改配置的話，這樣不僅不利于系統(tǒng)的維護 和管理，同時也更加容易引入錯誤。另外很多時候集群中的很多系統(tǒng)的配置都是一樣的，如果不進行統(tǒng)一的配置管理，就需要再所有的系統(tǒng)上維護一份配置，這樣會 造成配置的管理維護很麻煩，而通過一個統(tǒng)一的配置管理可以使得這些問題得到很好的解決，當有新的節(jié)點加入或者刪除的時候，配置管理系統(tǒng)可以通知各個節(jié)點更 新配置，從而達到所有節(jié)點的配置一致性，這樣既方便也不會出錯。