淘寶網架構

淘寶用的是JBoss，框架是iBATIS，緩存服務器是本身開發的，基本遵循SNA架構，水平擴展，數據庫是Oracle，阿里集團的DBA幾乎是國內最強悍的。目前淘寶的系統架構正在重構，計劃用兩到三年時間重寫，目標有兩個：

一、水平擴展已經不知足需求了，還須要水平加垂直擴展
二、開放API，讓店家能夠把外部網站資源集成到淘寶，沒必要直接在淘寶開店

淘寶首席架構師是原來JBoss的Ben Wang，如今正在招募技術高手加盟，從事這項頗有挑戰性的工做：設計下一代開放性、支撐數十億訪問量的在線電子商務網站，有意着能夠和我聯繫，向我投遞簡歷： fankai@gmail.com

淘寶架構更詳細的狀況就不方便透露了。

淘寶網，是一個在線商品數量突破一億，日均成交額超過兩億元人民幣，註冊用戶接近八千萬的大型電子商務網站，是亞洲最大的購物網站。那麼對於淘寶網這樣大 規模的一個網站，我猜測你們必定會很是關心整個網站都採用了什麼樣的技術、產品和架構，也會很想了解在淘寶網中是否採用了開源的軟件或者是徹底採用的商業 軟件。那麼下面我就簡單的介紹一下淘寶網中應用的開源軟件。

對於規模稍大的網站來講，其IT必然是一個服務器集羣來提供網站服務，數據庫也必然要和應用服務分開，有單獨的數據庫服務器。對於像淘寶網這樣規模 的網站而言，就是應用也分紅不少組。那麼下面，我就從應用服務器操做系統、應用服務器軟件、Web Server、數據庫、開發框架等幾個方面來介紹一下淘寶網中開源軟件的應用。

操做系統
咱們首先就從應用服務器的操做系統提及。一個應用服務器，從軟件的角度來講他的最底層首先是操做系統。要先選擇操做系統，而後纔是操做系統基礎上的應用軟 件。在淘寶網，咱們的應用服務器上採用的是Linux操做系統。Linux操做系統從1991年第一次正式被公佈到如今已? ? 走過了十七個年頭，在PC Server上有普遍的應用。硬件上咱們選擇PC Server而不是小型機，那麼Server的操做系統供咱們選擇的通常也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。若是不許備採用微軟的一系列產品構建應用，而且有能力維護Linux或者FreeBSD，再加上成本的考慮，那麼仍是應該在Linux和 FreeBSD之間進行選擇。能夠說，如今Linux和FreeBSD這兩個系統難分伯仲，很難說哪一個必定比另一個要優秀不少、可以全面的超越對手，應 該是各有所長。那麼在選擇的時候有一個因素就是企業的技術人員對於哪一種系統更加的熟悉，這個熟悉一方面是系統管理方面，另一方面是對於內核的熟悉，對內 核的熟悉對於性能調優和對操做系統進行定製剪裁會有很大的幫助。而應用全面的優化、提高性能也是從操做系統的優化開始的。

應用服務器
在肯定了服務器的硬件、服務器的操做系統以後，下面咱們來講說業務系統的構建。淘寶網有不少業務系統應用是基於JEE規範的系統。還有一些是C C++構建的應用或者是Java構建的Standalone的應用。那麼咱們要選擇一款實現了JEE規範的應用服務器。咱們的選擇是JBoss Applcation Server。JBoss AS是RedHat的一個開源的支持JEE規範的應用服務器。在幾年前，若是採用Java技術構建互聯網應用或者企業級應用，在開源軟件中的選擇通常也就 是Apache組織的Tomcat、JBoss的 JBoss AS和Resin。嚴格意義上講，Tomcat和Resin並不能算是一個應用服務器，他們是實現了部分J2EE規範的一個容器。而商業軟件的選擇就是 IBM的WebSphere和BEA的WebLogic。到了如今，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很優秀的JEE應用服務器。也給如今的開發人員提供了更多的選擇。具體對於目 前JEE應用服務器的比較。這邊就不在贅述。
在應用服務器前端，咱們採用了Web Server作了一次轉發，咱們選擇的Web服務器是大名鼎鼎的Apache。幾年前，Apache幾乎是Linux系統上開源Web Server的惟一選擇。那個時候雖然也有一些其餘的開源的Web Server，可是從功能和穩定性上來講都沒法和Apache相對。在今天來講，Lighty也會是一個很是好的選擇。Lighty是一個很是輕量級、佔 用內存資源也比較少的Web Server。雖然功能上沒有Apache強大，可是在很多場景下，性能是很是出色、強於Apache的。而微軟的IIS，就只能工做在Windows的 系統上了。而且使用IIS的話，基本上也就是選擇了ISAPI、ASP或者ASP.NET進行Web應用的開發了。

數據庫
說完了咱們採用的操做系統、應用服務器、WebServer後，下面就來談談咱們的數據庫。在淘寶網的應用中，採用了兩種關係型數據庫管理系統。一個是 Oracle公司的Oracle 10g，另一個是Sun MySQL的MySQL。Oracle是一款優秀的、普遍採用的商業數據庫管理軟件。有很強大的功能和安全性，能夠處理相對海量的數據。而MySQL是一 款很是優秀的開源數據庫管理軟件，很是適合用多臺PC Server組成多點的存儲節點陣列(這裏我所指的不是MySQL自身提供的集羣功能)，每單位的數據存儲成本也很是的低廉。用多臺PC Server安裝MySQL組成一個存儲節點陣列，經過MySQL自身的Replication或者應用自身的處理，能夠很好的保證容錯(容許部分節點失 效)，保證應用的健壯性和可靠性。能夠這麼說，在關係數據庫管理系統的選擇上，能夠考慮應用自己的狀況來決定。
一個互聯網應用，除了服務器的操做系統，Web Server軟件，應用服務器軟件，數據庫軟件外，咱們還會涉及到一些其餘的系統，好比一些中間件系統、文件存儲系統、搜索、分佈式框架、緩存系統等等。 在淘寶網，這些系統都是自主開發的，沒有采用目前商業的或者開源的產品。有些系統，會存在着一些開源的產品或者商業產品。可是，考慮到淘寶網本身的需求和 大併發量的壓力，這些系統都選擇了自主開發。

開發框架
前面談的都是系統級的產品，下面咱們說說開發框架的使用。可能有朋友想問，做爲一個如此大規模的網站，淘寶網的Web展示層採用的是什麼框架，是怎麼實現 的呢？曾? ? 也有到淘寶的應聘者問過我這個問題，他問我說是否是用的 struts。我告訴他說不是的。其實淘寶網的Web展示層的框架用的不是struts，不是webwork，不是spring mvc等等。淘寶網的Web展示層的框架用的是集團內部自主開發的一套Web框架。這個框架可以解決一些其餘Web框架不能解決的、在淘寶的應用中又會出 現並須要解決的問題。在淘寶的多個應用中，也採用了一些開源的框架，好比Spring、iBatis、jBPM、Hessian、Mina等等。這些開源 軟件的採用爲咱們構建應用系統提供了很大的幫助。
採用開源軟件構建系統，我想有兩個很大的好處：
一個是下降成本。假設你有1000 臺應用服務器，若是你每臺服務器上採用的不是JBoss AS或者其餘開源的軟件，而是使用商業的Oracle BEA的Weblogic或者IBM的WebSphere，那麼爲這1000臺機器的應用購買License的費用是很是高的。
另一個好處(我以爲最大的好處)是你能夠看到軟件的源碼，你能夠研究瞭解軟件內部的工做過程、原理。這對於應用設計、開發、查錯、優化都是很是有幫助的。

淘寶網的開源觀
對於開源軟件的應用，有些人可能擔憂質量的問題，有些人可能擔憂軟件自己發展更新的問題，等等。對於質量的問題，我想如今不少的開源軟件尤爲是一些很著名 的開源軟件都有很完善的組織，有完善的開發、測試、發佈流程。在一個新版本完成前，會有屢次的測試版本發佈，最後纔是正式版。這和商業軟件是同樣的。而且 由於代碼公開，反而更加的容易發現錯誤，提升質量。至於第二個問題，我想跟第一個問題同樣，關鍵是組織和規劃而不在是否開源，而且在不少著名的開源軟件背 後，會有廠商在進行支持。軟件自己的發展應該是不會成爲問題的，不太會出現軟件忽然中止發展的狀況。
在從此的發展中，咱們仍是會一如既往的關注開源軟件的發展，也還會根據須要採用不一樣的開源軟件。在選擇一個開源產品的時候，我會考慮如下幾點：
1. 這個軟件目前的功能和它的RoadMap
2. 軟件自己的架構
3. 該軟件開發的活躍度
4. 該開源軟件是不是遵照該領域內的國際規範的
5. 在同類產品中，要挑選有比較優點的。而且要考慮可能存在的移植代價。這個移植指的是採用了這款開源軟件後現有系統的移植，或者是從這個開源軟件到其餘軟件的移植。
對於企業級系統、互聯網應用來講，採用開源軟件不只能夠下降成本，更重要的是可以真正瞭解軟件的內部工做機制。還能夠在如今的基礎上進行加強和定製，也能 夠從開源軟件中借鑑到不少好的設計和實現。但願國內能有更多的企業在使用開源軟件的同時，也能開源自身的一些軟件，或者可以成爲一些開源軟件的貢獻者。而 做爲淘寶網，咱們也會很是積極的參與到開源的活動中，也會努力爲開源的發展作出咱們應有的貢獻。

淘寶網高性能可伸縮架構技術探祕
文章轉載自網管之家：http://www.bitscn.com/pdb/php/201007/188788.html

今天咱們繼續大型網站探祕，一塊兒來探祕淘寶網的架構技術。做爲國內最大的B2C網站，淘寶網的網站架構一直承載着數據量告訴增加壓力，要保證良好的負載和流程的使用體驗，一個可伸縮性的高性能網站架構必不可少。
1、應用無狀態

一個系統的伸縮性的好壞取決於應用的狀態如何管理。試想一下，假如咱們在session中保存了大量與客戶端的狀態信 息的話，那麼當保存狀態信息的server宕機的時候，咱們怎麼辦？一般來講，咱們都是經過集羣來解決這個問題，而一般 所說的集羣，不只有負載均衡，更重要的是要有失效恢復failover,好比tomcat採 用的集羣節點廣播複製，jboss採 用的配對複製等session狀 態複製策略，可是集羣中的狀態恢復也有其缺點，那就是嚴重影響了系統的伸縮性，系統不能經過增長更多的機器來達到良好的水平伸縮，由於集羣節點間 session的 通訊會隨着節點的增多而開銷增大，所以要想作到應用自己的伸縮性，咱們須要保證應用的無狀態性，這樣集羣中的各個節點來講都是相同的，從而是的系統更好的 水平伸縮。

上面說了無狀態的重要性，那麼具體如何實現無狀態呢？此時一個session框架就會發揮做用了。幸運的是公司已經具備了此類框架。公司的 session框架採用的是client cookie實現，主要將狀態 保存到了cookie裏 面，這樣就使得應用節點自己不須要保存任何狀態信息，這樣在系統用戶變多的時候，就能夠經過增長更多的應用節點來達到水平擴展的目的.但 是採用客戶端cookie的 方式來保存狀態也會遇到限制，好比每一個cookie通常不能超過4K的大小，同時不少瀏覽器都限制一個站點最 多保存20個cookie.公司cookie框 架採用的是「多值cookie」， 就是一個組合鍵對應多個cookie的 值，這樣不只能夠防止cookie數 量超過20， 同時還節省了cookie存 儲有效信息的空間，由於默認每一個cookie都會有大約50個字節的元信息來描述cookie。

除了公司目前的session框 架的實現方式之外，其實集中式session管理來完成，說具體點就是多個無狀態的應用節點鏈接一個session 服 務器，session服 務器將session保 存到緩存中，session服 務器後端再配有底層持久性數據源，好比數據庫，文件系統等等。

2、有效使用緩存

作互聯網應用的兄弟應該都清楚，緩存對於一個互聯網應用是多麼的重要，從瀏覽器緩存，反向代理緩存，頁面緩存，局部頁面緩存，對象緩存等等都是緩存應用的場景。

通常來講緩存根據與應用程序的遠近程度不一樣能夠分爲：local cache 和 remote cache。 通常系統中要麼採用local cache，要麼採用remote cache,二者混合使用的話對 於local cache和remote cache的數據一致性處理會變 大比較麻煩.

在 大部分狀況下,我 們所說到的緩存都是讀緩存,緩存還有另一個類型:寫緩存. 對 於一些讀寫比不高，同時對數據安全性需求不高的數據，咱們能夠將其緩存起來從而減小對底層數據庫的訪問,好比 統計商品的訪問次數,統 計API的 調用量等等,可 以採用先寫內存緩存而後延遲持久化到數據庫，這樣能夠大大減小對數據庫的寫壓力。

以店鋪線的系統爲例，在用戶瀏覽店鋪的時候，好比店鋪介紹，店鋪交流區頁面，店鋪服務條款頁面，店鋪試衣間頁面，以及店鋪內搜索界面這些界面更新不 是非 常頻繁，所以適合放到緩存中，這樣能夠大大減低DB的負載。另外寶貝詳情頁面相對也更新比較 少，所以也適合放到緩存中來減低DB負載。

3、應用拆分

首先，在說明應用拆分以前，咱們先來回顧一下一個系統從小變大的過程當中遇到的一些問題，經過這些問題咱們會發現拆分對於構建一個大型系統是如何的重要。

系統剛上線初期，用戶數並很少，全部的邏輯也許都是放在一個系統中的，全部邏輯跑到一個進程或者一個應用當中，這個時候由於比較用戶少，系統訪問量 低，所以 將所有的邏輯都放在一個應用何嘗不可。可是，兄弟們都清楚，好景不長，隨着系統用戶的不斷增長，系統的訪問壓力愈來愈多，同時隨着系統發展，爲了知足用戶 的需求，原有的系統須要增長新的功能進來，系統變得愈來愈複雜的時候，咱們會發現系統變得愈來愈難維護，難擴展，同時系統伸縮性和可用性也會受到影響。那 麼這個時候咱們如何解決這些問題呢？明智的辦法就是拆分（這也算是一種解耦），咱們須要將原來的系統根據必定的標準，好比業務相關性等分爲不一樣的子系統， 不一樣的系統負責不一樣的功能，這樣切分之後，咱們能夠對單獨的子系統進行擴展和維護，從而提升系統的擴展性和可維護性，同時咱們系統的水平伸縮性scale out大大的提高了，由於咱們能夠有針對性的對壓力大的子系統進行水平擴展而不會影響到其它的子系統，而不會像拆分之前，每次系統壓力變大的時候，咱們都 須要對整 個大系統進行伸縮，而這樣的成本是比較大的，另外通過切分，子系統與子系統之間的耦合減低了，當某個子系統暫時不可用的時候，總體系統仍是可用的，從而整 體系統的可用性也大大加強了。

所以一個大型的互聯網應用，確定是要通過拆分，由於只有拆分了，系統的擴展性，維護性,伸縮性，可用性纔會變的更好。可是拆分也給系 統帶來了問題，就是子系統之間如何通訊的問題，而具體的通訊方式有哪些呢？通常有同步通訊和異步通訊，這裏咱們首先來講下同步通訊，下面的主題「消息系 統」會說到異步通訊。既然須要通訊，這個時候一個高性能的遠程調用框架就顯得很是總要啦，所以我們公司也有了本身的HSF框 架。

上面所說的都是拆分的好處，可是拆分之後必然的也會帶來新的問題，除了剛纔說的子系統通訊問題外，最值得關注的問題就是系統之間的依賴關係，由於系 統多了， 系統的依賴關係就會變得複雜，此時就須要更好的去關注拆分標準，好比可否將一些有依賴的系統進行垂直化，使得這些系統的功能儘可能的垂直，這也是目前公司正 在作的系統垂直化，同時必定要注意系統之間的循環依賴，若是出現循環依賴必定要當心，由於這可能致使系統連鎖啓動失敗。

既然明白了拆分的重要性，咱們看看隨着公司的發展，公司自己是如何拆分系統的。

在這個演變的過程當中，咱們所說的拆分就出現V2.2和V3.0之間。在V2.2版 本中，公司幾乎全部的邏輯都放在一個系統中，這樣致使的問題就是系統擴展和修改很是麻煩，而且更加致命的是隨着公司業務量的增 加，若是按照V2.2的 架構已經沒有辦法支撐之後公司的快速發展，所以你們決定對整個系統進行拆分，V3.0版本的系統對整個系統進行了水平和垂直 兩個方向的拆分，水平方向上，按照功能分爲交易，評價，用戶，商品等系統，一樣垂直方向上，劃分爲業務系統，核心業務系統以及以及基礎服務，這樣以來，各 個系統均可以獨立維護和獨立的進行水平伸縮，好比交易系統能夠在不影響其它系統的狀況下獨立的進行水平伸縮以及功能擴展。

從上面能夠看出，一個大型系統要想變得可維 護，可擴展，可伸縮，咱們必須的對它進行拆分，拆分必然也帶來系統之間如何通訊以及系統之間依賴管理等問題，關於通訊方面，公司目前獨立開發了本身的高性 能服務框架HSF， 此框架主要解決了公司目前全部子系統之間的同步和異步通訊（目前HSF主要用於同步場合，FutureTask方 式的調用場景還比較少）。至於系統間的依賴管理，目前公司還作的不夠好，這應該也是咱們之後努力解決的問題。

淘寶網架構師嶽旭強的年度展望

2009年是挑戰和機遇並存的一年，對大部分人來講，已經習慣了金融危機，並努力解決危機。在技術圈子也同樣，被裁人的確定也找到了工做，因此都在踏實作技術。言歸正傳，先念叨唸叨2009年的一些故事，尋個回憶，找個樂子。

數據擴展性探討和總結
金融危機是電子商務的機遇，因此09年是淘寶高速發展的一年。當一個網站從百萬、千萬記錄的數據規模，增加到億、十億、幾十億記錄的數據規模時，是一個量 變到質變的過程，單純的硬件升級已經達到了瓶頸，而須要在總體結構上作文章。09年一年，大部分時間都在數據的擴展性上努力。

對於一個電子商務網站來說，訂單是最核心的數據，也是增加最快的數據。對於數據的擴展性來說，最傳統也是最簡單有效的模式是數據庫的分庫分表。當訂 單和分庫分表相遇，會有什麼火花迸發出來？09年初碰撞了好久，結果產生的火花很小。最大的問題在於數據分割的規則，無規則的水平分割確定會帶來數據合併 的開銷，而按照業務規則拆分，會由於買家和賣家的查詢需求不一樣而致使數據不能分割，惟一可行的火花是把訂單雙份保存，買家賣家各自一份，只是成本比較高， 並且對數據同步的要求很是高。

因而咱們初步決定按照雙份保存的方式拆分訂單，而有一天，仔細查看了訂單訪問的狀況，發現訂單數據庫90%以上的壓力來自於查詢，而查詢中90%以上的壓力來自於非核心業務，僅僅是訂單數據的展示，對一致性和實時性的要求很低。

由於數據量大，形成數據庫壓力大，自然想到的是分散壓力，其辦法就是分庫分表。有些時候咱們想問題不妨直接一點，既然壓力大，能不能減少壓力呢？通 過對訂單訪問狀況的瞭解，發現昂貴的主數據庫，有80%以上的壓力給了不重要的需求，這個就是咱們優化的關鍵，因此訂單最後採用了讀寫分離的方案，高成本 的主數據庫解決事務和重要的查詢業務，80%以上不重要的讀，交給了低成本的數據庫服務器來解決，同時對數據複製的要求也很低，實現無太大難度。

另一個有意思的案例是商品的數據擴容，商品的水平分割很是容易，按照賣家進行拆分便可。有了訂單的先例，首先想到了讀寫分離，由於成本能夠作低。 開始實施後一段時間，又仔細回想了一下商品的總體需求，忽然發現商品其實不須要和訂單同等的要求，必定要採用高成本的主數據庫嗎？ 所有采用低成本的普通服務器來作數據庫是否可行？通過仔細的評估，發現是能夠接受的，而這樣就致使以前已經啓動的商品讀寫分離項目的一部分工做白作了！

故事講完了老是要有點總結，來點虛的先：對於原始需求的清晰瞭解是系統決策的前提，不然彎路確定要走，而對原始需求的瞭解並不容易，中間會有不少幹 擾和阻力，前面的實例看起來很簡單，可是在一個運行了5年的系統上來了解本質，來進行變動，並沒那麼容易。另外，經驗有些時候會成爲系統決策的障礙，這個 很矛盾，因此須要有歸零的心態來思考問題。說到底，迴歸本源。

再來點稍微實際一點的，對於大型分佈式系統的數據訪問，一個統一的數據層是很是必要的，封裝水平、垂直的數據分割，封裝讀寫分離，封裝數據訪問的路 由、複製、合併、搬遷、熱點處理等功能，而且要對應用透明，應用針對性的，能夠在JDBC層面包裝，數據庫針對性的，能夠在數據庫協議層包裝，好比 Amoeba。

關注系統和人的交互
還有一個故事，在數據層的前期版本，爲了作到透明的路由，曾經採用無SQL的方式，全部的數據庫訪問都是寫代碼來作。上線後發現一個很是痛苦的問題，沒法 和SQL對應，排錯很是難。曾經一次DBA發現數據庫上一個查詢耗費太多資源，把優化後的SQL給開發人員改進，開發人員好幾天沒找到具體是哪一個查詢。

另一個在2009年的感觸是業界服務化的實施狀況，不少組織都在實施服務化，系統層面都很成功，通訊、負載均衡、消息系統、服務容器等都有不少成 果，可是實施一段時間之後的效果並非很是好，依賴複雜，變動混亂，效率低下。究其根本，是對人的關注不夠，缺乏的產品化的服務運維，缺乏服務治理。

上面的兩個例子都是對人的關注缺失，技術人員作系統，大部分都更關注技術，而忽視技術的創造者和使用者——人。軟件或服務的可測試性是對測試人員的 關注、可維護性和可管理性是對運維人員的關注，而一個框架的易用性是對全部使用人員的關注。除非能作出本身進化的Skynet（注：Skynet（天網） 出如今《終結者》系列電影中，是一我的類於20世紀後期創造的以計算機爲基礎的人工智能防護系統，最初是研究用於軍事的發展。天網在控制了全部的美軍的武 器裝備後不久，得到自我意識，而且認定人類是它存在的威脅。因而馬上倒戈對抗其創造者，採用大規模殺傷性武器（甚至核暴）來滅絕全人類。），不然仍是要多 關注系統和人的交互。

關注可用性
還有一個感觸是業界對可用性這個基本指標的關注度不夠。幾乎全部的框架都會說本身的擴展性多高，性能多好，而不多會提到監控有多強、排錯有多容易，不多提 到在故障時怎麼作隔離，怎麼作降級；從這個角度看，商用的產品確實作得好不少；關於性能相關的文章搜索一下，不少，各類優化策略，各類優化方法，而可用性 方面，找到的系統性的知識真的不多；但願是我瞭解的很少。

回顧過去，展望將來。2010年，不少能夠作的事情，面向服務系統的隔離和降級、系統可維護性的提升、協程和異步模式在web應用的全面使用……