本文作者陳睿|mike,優知學院創始人，曾先後在淘寶、百度、攜程帶領技術、產品等團隊。
優知學院，是首家互聯網技術&產品學習社區，提供系統的技術&產品晉升學習課程，也定期提供深度互聯網產品觀察&互聯網最新技術動向。
“
前一篇“淘寶發展歷程最具決定性的一次技術架構演變”，詳細描述了淘寶技術架構最重要的第三、四階段演變。
由於大家的熱情相當高漲，所以特意補充了本篇文章(淘寶技術架構早期第一、二階段)，從而可以完整的查看到整個淘寶技術架構演變過程。
淘寶技術發展歷程
前一篇“淘寶發展歷程最具決定性的一次技術架構演變”，詳細描述了淘寶技術架構最重要的第三、四階段演變。
補充本篇重點談第一、二階段，從而可以完整的查看整個淘寶的技術架構演變歷程。
淘寶架構演變第一步
1.誕生場景
2003 年 4 月 7 日，馬雲，在杭州，成立了一個神祕的組織，叫來十位員工，要他們簽了一份協議，並要求他們立刻離開阿里巴巴，去做一個神祕的項目。需求也很明確，上線一個可拍賣的電商網站。需求的時間也很明確，一個月。
滿足需求的第一要素,那就是分析評估。評估完發現根本不可能1個月開發一個拍賣網站。於是另闢出路，是否可以買一個開源的系統，在上面修改。最後就買了個老美的PhpAuction，一個月後正常上線。
最早的淘寶效果圖如下：
2.基本架構
最開始就是無比經典的LAMP經典架構(linux+apache+mysql+php)，再牛逼的網站不也是這樣一步步起步的麼。
3.從物理部署角度
也就是非常簡單，web機器+數據庫服務器搞定。
4.從軟件架構的角度
小而快的簡單架構，也就是無需編譯，發佈快速，PHP能完成從頁面渲染到數據訪問所有的事情，而且用到的技術都是開源的，並且免費。在那個年代類似的產物，還有大量asp網站。比如，同時期開發架構遺留下來的有京東、新蛋、攜程、易迅等互聯網企業，後面花了大量的時間重構，把asp網站改版為.net，最後還得花更大的經歷和代價改版為java版本。
3.優點
最大的優點：快速滿足業務需求。
這個時候沒有過多考慮技術是否牛逼、沒有過多考慮性能是否海量、沒有考慮穩定性如何，主要的考慮就是：快！
當時淘寶的第一個版本的系統裡面已經包含了商品發佈、管理、搜索、商品詳情、出價購買、評價投訴、我的淘寶這些功能。
4.瓶頸
在短時期在淘寶市場和運營部門的強大推動下，到了2003 年底就吸引了大量的註冊用戶，最高每日 31 萬PV，到2003年年底成交額接近4000 萬。
瓶頸來了，逐漸你發現系統的壓力越來越高，響應速度越來越慢，而這個時候比較明顯的是數據庫和應用互相影響，應用出問題了，數據庫也很容易出現問題，而數據庫出問題的時候，應用也容易出問題。
例如，第一個問題來了，出現在數據庫上。當時採用的是MySQL第 4 版的，用的是默認的存儲引擎 MyISAM，這種類型讀數據的時候會把表鎖住（我們知道 Oracle 在寫數據的時候會有行鎖，讀數據的時候是沒有的），尤其是主庫往從庫上面寫數據的時候，會對主庫產生大量的讀操作，使得主庫性能急劇下降。
當時最大的瓶頸還是來自於數據庫，發現是訪問數據庫的操作太多，導致數據連接競爭激烈，所以響應變慢，但數據庫連 接又不能開太多，否則數據庫機器壓力會很高。
備註：當時淘寶的情況， PHP 語言來說它是放在 Apache 上的，每一個請求都會對數據庫產生一個連接。php的連接池只能從第三方擴展裡實現連接池。
總之問題非常清楚了，數據庫的訪問壓力過大，有什麼對應的方法減少數據庫端的開銷變得及其重要。
於是開始了架構的第二步演變。
淘寶架構演變第二步
1.遺留問題
訪問數據庫的操作太多，導致數據連接競爭激烈，所以響應變慢，但數據庫連接又不能開太多，否則數據庫機器壓力會很大。
採用mysql MyISAM，讀數據的時候會發生鎖表的情況。
php的代理連接池雷區太多，經常掛！
訪問量越來越大，各種壓力接踵而至，應用端、數據段等等。
2.架構方案
解決數據庫端瓶頸
採用oracle替換mysql，解決高併發讀數據等系列問題，也引入了數據庫連接池，以及讀寫分離等。
採用了Oracle 的 RAC(Real Application Clusters),做了集群管理，以及讀寫分離Master/Slave等。
下圖是oracle ace的結構：
最後，為了配合Oracle，php也徹底被替換為java。替換為java其實還有一個很重要的原因：配合數據庫連接池的使用，畢竟php的代理連接池坑太多。當然，java的開源體系也是非常重要的考慮。
3.應用端解決方案
第一個，往集群方向發展，從硬件的角度可以橫向擴展應用服務器。對應的就會涉及到應用端的負載均衡，類似的方案非常多LVS等。
為了減少對數據庫端的訪問壓力，把訪問轉移到緩存上，也就涉及到了分佈式緩存,eg:memcached等開源架構。最早淘寶採用的分佈式緩存就是memcached,後來開始定製化，改進了部分內容，演變成了現在這個Tari版本。
也是為了減少數據庫端的壓力，把小文件存儲轉換到便宜的硬件上，也就有了分佈式存儲，後來的TFS。
最終你會發現，都是為了緩解數據庫端的壓力。
4.第二階段架構大致如圖：
應用服務器採用了jboss服務器，之前用的是weblogic。
框架採用了webx（自己研發的web框架），spring，ibatis,antx。
antx重點說下，webx和antx都是阿里最早的架構師(十八羅漢)寶寶設計的。你可以理解為現在的maven，當時這麼早就可以設計出這麼牛叉的東西。只不過沒有開源出來，否則完全可以很早就替換現在的maven。
怎麼擴展？基本就是硬件水平擴展，應用端和數據庫端加機器擴展。
5.挑戰來了
第一個：代碼工程臃腫到了極致，嚴重影響了開發速度和發佈。
上百人維護一個代碼百萬行的核心工程denali。多個業務系統中的超過1/3的核心代碼重複編寫。 你可想而知，這有多臃腫。一群人在上面拉分支，發佈上線，然後在合併分支。線上出問題了，還得回滾，再合併，特別是開發、SCM等痛苦死了！
備註：我自己就親身經歷過兩次，從denali裡面拆了兩個業務系統，從一個百萬行代碼抽取出一個打包後就十幾M的文件。拆分一次，你絕對不想再去拆分第二次，我拆了兩次：(
第二個：數據庫端的壓力又到瓶頸了。
原因很簡單，訪問比之前大了無數倍了，還是扛不住啊。 數據庫端的壓力一直是重中之重，小型機也扛不住了。
當時的淘寶的典型症狀，就是數據庫服務器的CPU佔用超過90%，說明開的數據庫連接也達到了極限，數據庫機隨時崩潰。
關於這一條，很多沒有經歷過雪崩的，也許你死都不知道怎麼死的。雪崩效應，90%都是來源於數據庫端的壓力。數據庫端的壓力會轉移到應用端，最後互相死循環。最重要的就是要管住數據庫端的壓力，並且把應用端的壓力與數據庫端做切割。切割有多種方法，最好的方法就是物理隔離！
很顯然，即將面臨的挑戰和瓶頸來了：
數據庫的瓶頸快到極限了，數據庫端需要做垂直拆分了，按照業務線。
應用端的代碼結構也需要做垂直拆分了，按照業務垂直拆分代碼。
接口需要清理依賴關係，是否需要單獨部署？需要一個支撐高併發的通訊框架？
中間件需要形成自己的矩陣了，分佈式緩存、分佈式存儲、SQL路由等等。
為此，想從根本上解決以上問題，是否需要探索出自己的一套SOA之路？
帶著這些問題，可以查看前一篇“淘寶發展歷程最具決定性的一次技術架構演變”，詳細描述了淘寶怎麼來解決以上問題。
關注優知學院後，可以完整查看到淘寶架構的第三、四階段：“淘寶發展歷程最具決定性的一次技術架構演變”。
相關推薦
