淘寶的架構

淘寶的架構

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

1、水平擴展已經不滿足需求了，還需要水平加垂直擴展 
2、開放API，讓店家可以把外部網站資源集成到淘寶，不必直接在淘寶開店

淘寶首席架構師是原來JBoss的Ben Wang，現在正在招募技術高手加盟，從事這項很有挑戰性的工作：設計下一代開放性、支撐數十億訪問量的在線電子商務網站 

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

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

對于規模稍大的網站來說，其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. 在同類產品中，要挑選有比較優勢的。并且要考慮可能存在的移植代價。這個移植指的是采用了這款開源軟件后現有系統的移植，或者是從這個開源軟件到其他軟件的移植。
對于企業級系統、互聯網應用來說，采用開源軟件不僅可以降低成本，更重要的是能夠真正了解軟件的內部工作機制。還可以在現在的基礎上進行增強和定制，也能 夠從開源軟件中借鑒到很多好的設計和實現。希望國內能有更多的企業在使用開源軟件的同時，也能開源自身的一些軟件，或者能夠成為一些開源軟件的貢獻者。而 作為淘寶網，我們也會非常積極的參與到開源的活動中，也會努力為開源的發展做出我們應有的貢獻。

淘寶網高性能可伸縮架構技術探秘

今天我們繼續大型網站探秘，一起來探秘淘寶網的架構技術。作為國內最大的B2C網站，淘寶網的網站架構一直承載著數據量告訴增長壓力，要保證良好的負載和流程的使用體驗，一個可伸縮性的高性能網站架構必不可少。

一、應用無狀態

一個系統的伸縮性的好壞取決于應用的狀態如何管理。試想一下，假如我們在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服務器后端再配有底層持久性數據源，比如數據庫，文件系統等等。

二、有效使用緩存

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

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

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

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

三、應用拆分

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

系統剛上線初期，用戶數并不多，所有的邏輯也許都是放在一個系統中的，所有邏輯跑到一個進程或者一個應用當中，這個時候因為比較用戶少，系統訪問量低，因此將全部的邏輯都放在一個應用未嘗不可。但是，兄弟們都清楚，好景不長，隨著系統用戶的不斷增加，系統的訪問壓力越來越多，同時隨著系統發展，為了滿足用戶的需求，原有的系統需要增加新的功能進來，系統變得越來越復雜的時候，我們會發現系統變得越來越難維護，難擴展，同時系統伸縮性和可用性也會受到影響。那么這個時候我們如何解決這些問題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來的系統根據一定的標準，比如業務相關性等分為不同的子系統，不同的系統負責不同的功能，這樣切分以后，我們可以對單獨的子系統進行擴展和維護，從而提高系統的擴展性和可維護性，同時我們系統的水平伸縮性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世紀后期創造的以計算機為基礎的人工智能防御系統，最初是研究用于軍事的發展。天網在控制了所有的美軍的武器裝備后不久，獲得自我意識，并且認定人類是它存在的威脅。于是立刻倒戈對抗其創造者，采用大規模殺傷性武器（甚至核暴）來滅絕全人類。），否則還是要多關注系統和人的交互。

關注可用性

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