【正文】 評估，發(fā)現(xiàn)是可以接受的，而這樣就導致之前已經(jīng)啟動的商品讀寫分離項目的一部分工作白做了！ 故事講完了總是要有點總結(jié)，來點虛的先：對于原始需求的清晰了解是系統(tǒng)決策的前提，否則彎路肯定要走，而對原始需求的了解并不容易，中間會有很多干擾和阻力，前面的實例看 起來很簡單，但是在一個運行了 5 年的系統(tǒng)上來了解本質(zhì)，來進行變更，并沒那么容易。 因為數(shù)據(jù)量大，造成數(shù)據(jù)庫壓力大，天然想到的是分散壓力，其辦法就是分庫分表。對于數(shù)據(jù)的擴展性來講，最傳統(tǒng)也是最簡單有效的模式是數(shù)據(jù)庫的 分庫分表。 . 數(shù)據(jù)擴展性探討和總結(jié) 金融危機是電子商務的機遇，所以 09 年是淘寶高速發(fā)展的一年。因此一個監(jiān)控系統(tǒng)就變得必不可少了。我們都知道根據(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ù)，比如 keyvalue 形式的數(shù)據(jù)存儲，并且這些產(chǎn)品有個很好的優(yōu)點就是水平伸縮性。 下面我們就以公司的業(yè)務來看看異步在公司的具體應用。 好了 ， 既然說到了異步通信 ,那么 “ 消息中間件 ” 就要登場了 ,采用異步通信這其實也是關(guān)系到系統(tǒng)的伸縮性 ， 以及最大化的對各個子系統(tǒng)進行解耦 。但是是不是這樣，我們就可以高枕無憂了呢？ NO,這個 NO，不是我說的，是前輩們通過經(jīng)驗總結(jié)出來的，隨著用戶量的不斷增加，你會發(fā)現(xiàn)系統(tǒng)中的某些表會變的異常龐大，比如好友關(guān)系 表，店鋪的參數(shù)配置表等，這個時候 無論是寫入還是讀取這些表的數(shù)據(jù)，對數(shù)據(jù)庫來說都是一個很耗費精力的事情，因此此時就需要我們進行 “ 水平分區(qū) ” 了（這就是俗話說的分表，或者說 sharding） 。 好了，確定了這個小節(jié)的主題之后，我們回顧一下，一個互聯(lián)網(wǎng)應用從小變大的過程中遇到的一些問題，通過遇到的問題來引出我們拆分 RDBMS 的重要性。 從上面可以看出，一個大型系統(tǒng)要想變得可維護，可擴展，可伸縮，我們必須的對它進行拆分，拆分必然也帶來系統(tǒng)之間如何通信以及系統(tǒng)之間依賴管理等問題，關(guān)于通信方面，公司目前獨立開發(fā)了自己的高性能服務框架 HSF，此框架主要解決了公司目前所有子系統(tǒng)之間的同步和異步通信（目前 HSF 主要用于同步場合， FutureTask 方式的調(diào)用場景還比較少）。 上面所說的都是拆分的好處，但是拆分以后必 然的也會帶來新的問題，除了剛才說的子系統(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)連鎖啟動失敗。那么這個時候我們?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) 第 6 頁 進行伸縮，而這樣的成本是比較大的，另外經(jīng)過切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當 某個子系統(tǒng)暫時不可用的時候，整體系統(tǒng)還是可用的，從而整體系統(tǒng)的可用性也大大增強了。另外寶貝詳情頁面相對也更新比較少，因此也適合放到緩存中來減低 DB 負載。 一般系統(tǒng)中要么采用 local cache，要么采用 remote cache， 兩者混合使用的話對于 local cache 和 remote cache 的數(shù)據(jù)一致性處理會變大比較麻煩 。 公司 cookie 框架采用的是“ 多值 cookie” ，就是一個組合鍵對應多個 cookie 的值 ， 這樣不僅可以防止 cookie 數(shù)量超過 20， 同時還節(jié)省了 cookie 存儲有效信息的空間，因為默認每個 cookie 都會有大約 50 個字節(jié)的元信息來描述 cookie。 上面說了無狀態(tài)的重要性，那么具體如何實現(xiàn)無狀態(tài)呢？此時一個 session 框架就會發(fā)揮作用了。希望國內(nèi)能有更多的企業(yè)在使用開源軟件的同時，也能開源自身的一些軟件，或者能夠成為一些開源軟件的貢獻者。并且要考慮可能存在的移植代價。至于第二個問題，我想跟第一個問題一樣，關(guān)鍵是組織和規(guī)劃而不在是否開源，并且在很多著名的開源軟件背后，會有廠商在進行支持。對于質(zhì)量的問題 ，我想現(xiàn)在很多的開源軟件尤其是一些很著名的開源軟件都有很完善的組織，有完善的開發(fā)、測試、發(fā)布流程。 假設你有 1000 臺應用服務器，如果你每臺服務器上采用的不是 JBoss AS 或者其他開源的軟件，而是使用商業(yè)的 Oracle BEA 的 Weblogic 或者 IBM 的 WebSphere，那么為這 1000 臺機器的應用購買 License 的費用是非常高的。這個框架能夠解決一些其他 Web框架不能解決的、在淘寶的應用中又會出現(xiàn)并需要解決的問題?？赡苡信笥严雴枺鳛橐粋€如此大規(guī)模的網(wǎng)站，淘寶網(wǎng)的 Web 展現(xiàn)層采用的是什么框架，是怎么實現(xiàn)的呢？曾經(jīng)也有 第 3 頁 到淘寶的應聘者問過我這個問題，他問我說是不是用的 struts。在淘寶網(wǎng)，這些系統(tǒng)都是自主開發(fā)的，沒有采用目前商業(yè)的或者開源的產(chǎn)品。而 MySQL 是一款非常 優(yōu)秀的開源數(shù)據(jù)庫管理軟件，非常適合用多臺 PC Server 組成多點的存儲節(jié)點陣列 (這里我所指的不是 MySQL自身提供的集群功能 )，每單位的數(shù)據(jù)存儲成本也非常的低廉。在淘寶網(wǎng)的應用中，采用了兩種關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。雖然功能上沒有 Apache 強大，但是在不少場景下，性能是非常出色、強于 Apache 的。幾年前， Apache 幾乎是 Linux 系統(tǒng)上開源 Web Server 的唯一選擇。也給現(xiàn)在的開發(fā)人員提供了更多的選擇。 第 2 頁 在幾年前，如果采用 Java 技術(shù) 構(gòu)建互聯(lián)網(wǎng)應用或者企業(yè)級應用，在開源軟件中的選擇一般也就是 Apache 組織的 Tomcat、 JBoss 的 JBoss AS 和 Resin。還有一些是 C/C++構(gòu)建的應用或者是 Java構(gòu)建的 Standalone 的應用。那么在選擇的時候有一個因素就是企業(yè)的技術(shù)人員對于哪種系統(tǒng)更加的熟悉，這個熟悉一方面是系統(tǒng)管理方面，另外一方面是對于內(nèi)核的熟悉，對內(nèi)核的熟悉對于性能調(diào)優(yōu)和對 操作系統(tǒng)進行定制剪裁會有很大的幫助。 Linux 操作系統(tǒng)從 1991 年第一次正式被公布到現(xiàn)在已經(jīng)走過了十七個年頭，在 PC Server 上有廣泛的應用。 操作系統(tǒng) 我們首先就從應用服務器的操作系統(tǒng)說起。下面介紹一下淘寶網(wǎng)中應用的開源軟件。那么對于淘寶網(wǎng)這樣大規(guī)模的一個網(wǎng)站，整個網(wǎng)站都采用了什么樣的技術(shù)、產(chǎn)品和架構(gòu)，是否采用了開源的軟件或者是完全采用的商業(yè)軟件。那么下面，我就從應用服務器操作系統(tǒng)、應用服務器軟件、 Web Server、數(shù)據(jù)庫、開 發(fā)框架等幾個方面來介紹一下淘寶網(wǎng)中開源軟件的應用。在淘寶網(wǎng)，我們的應用服務器上采用的是 Linux 操作系統(tǒng)?？梢哉f，現(xiàn)在 Linux 和 FreeBSD 這兩個系統(tǒng)難分伯仲，很難說哪個一定比另外一個要優(yōu)秀很多、能夠全面的超越對手，應該是各有所長。淘寶網(wǎng)有很多業(yè)務系統(tǒng)應用是基于 JEE 規(guī)范的系統(tǒng)。 JBoss AS是 RedHat的一個開源的支持 JEE規(guī)范的應用服務器。到了現(xiàn)在，除了 JBoss AS 外， Apache 的 Geronimo，Sun 的 Glassfish 也都是很優(yōu)秀的 JEE 應用服務器。 在應用服務器前端，我們采用了 Web Server 做了一次轉(zhuǎn)發(fā)，我們選擇的 Web 服務器是大名鼎鼎的 Apache。 Lighty 是一個非常輕量級、占用內(nèi)存資源也比較少的 Web Server。 數(shù)據(jù)庫 說完了我們采用的操作系統(tǒng)、應用服務器、 WebServer 后，下面就來談談我們的數(shù)據(jù)庫。有很強大的功能和安全性，可以處理相對海量的數(shù)據(jù)。 一個互聯(lián)網(wǎng)應用，除了服務器的操作系統(tǒng)， Web Server 軟件，應用服務器軟件，數(shù)據(jù)庫軟件外，我們還會涉及到一些其他的系統(tǒng)，比如一些中間件系統(tǒng)、文件存儲系統(tǒng)、搜索、分布式框架、緩存系統(tǒng)等等。 前面談的都是系統(tǒng)級的產(chǎn)品，下面我們說說開發(fā)框架的使用。淘寶網(wǎng)的Web 展現(xiàn)層的框架用的是集團內(nèi)部自主開發(fā)的一套 Web 框架。 采用開源軟件構(gòu)建系統(tǒng)，我想有兩個很大的好處： 一個是降低成本。 淘寶網(wǎng)的開源觀 對于開源軟件的應用，有些人可能擔心質(zhì)量的問題，有些人可能擔心軟件本身發(fā)展更新的問題，等等。并且因為代碼公開，反而更加的容易發(fā)現(xiàn)錯誤，提高質(zhì)量。在選擇一個開源產(chǎn)品的時候，我會考慮以下幾點： 1. 這個軟件目前的功能和它的 RoadMap 2. 軟件本身的架構(gòu) 3. 該軟件開發(fā)的活躍度 4. 該開源軟件是否是遵守該領(lǐng)域內(nèi)的國際規(guī)范的 5. 在同類產(chǎn)品中，要挑選有比較優(yōu)勢的。還可以在現(xiàn)在的基礎(chǔ)上進行增強和定制，也能夠從開源軟件 第 4 頁 中借鑒 到很多好的設計和實現(xiàn)。試想一下，假如我們在 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)更好的水平伸縮。但是采用客戶端 cookie 的方式來保存狀態(tài)也會遇到限制，比如每個 cookie 一般不能超過 4K的大小，同時很多瀏覽器都限制一個站點最多保存 20個 cookie。 一般來說緩存根據(jù)與應用程序的遠近程度不同可以分為 ： local cache 和 remote cache。 以店鋪線的系統(tǒng)為例，在用戶瀏覽店鋪的時候，比如店鋪介紹，店鋪交流區(qū)頁面，店鋪服務條款頁面，店鋪試衣間頁面，以及店鋪內(nèi)搜索界面這些界面更新不是非常頻繁，因此適合放到緩存中，這樣可以大大減低 DB 的負載。但是，兄弟們都清楚，好景不長，隨著系統(tǒng)用戶的不斷增加，系統(tǒng)的訪問壓力越來越多，同時隨著系統(tǒng)發(fā)展，為了滿足用戶的需求，原有的系統(tǒng)需要增加新的功能進來，系統(tǒng)變得越來越復雜的時候，我們會發(fā)現(xiàn)系統(tǒng)變得越來越難維護，難擴展，同時系統(tǒng)伸縮性和可用性也會受到影響。既然需要通信，這個時候一個高性能的遠程調(diào)用框架就顯得非常總要啦，因此咱們公司也有了自己的 HSF 框架。在 ，公司幾乎所有的邏輯都放在一個系統(tǒng)中，這樣導致的問題就是系統(tǒng)擴展和修改非常麻煩，并且更加致命的是隨著公司業(yè)務量的增加，如果按照 的架構(gòu)已經(jīng)沒有辦法支撐以后公司的快速發(fā)展，因此大家決定對整個系統(tǒng)進行拆分 ， 版本的系統(tǒng)對整個系統(tǒng)進行了水平和垂直兩個方向的拆分，水平方向上，按照功能分為交易，評價，用戶，商品等系統(tǒng)，同樣垂直 方向上，劃分為業(yè)務系統(tǒng)，核心業(yè)務系統(tǒng)以及 基礎(chǔ)服務，這樣以來，各個系統(tǒng)都可以獨立維護和獨立的進行水平伸縮，比如交易系統(tǒng)可以在不影響其它系統(tǒng)的情況下獨立的進行水平伸縮以及功能擴展 。因此這個主題主要涉及到如何對存儲系統(tǒng)，通常就是所說的 RDBMS 進行拆分。但是好景還是不長，有一天我們發(fā)現(xiàn) master 這哥們撐 不住了，它負載老高了，汗流浹背，隨時都有翹掉的風險，這個時候就需要咱們垂直分區(qū)啦（也就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同的數(shù)據(jù)庫中，同時還可以針對商品信息的庫采用 master， salve 模式， OK，通過分庫以后，各個按照功能拆分的數(shù)據(jù)庫寫壓力被分擔到了不同的 server 上面，這樣數(shù)據(jù)庫的壓力終于有恢復到正常狀態(tài)。 . 異步通信 在 “ 遠程調(diào)用框架 ” 的介紹中 ， 我們說了一個大型的系統(tǒng)為了擴展性和伸縮性方面的需求 ， 肯定是要進行拆分 ， 但是拆分了以后 ， 子系統(tǒng)之間如何通信就成了我們首要的問題 ， 在“ 遠程調(diào)用框架 ” 小節(jié)中 ， 我們說了同步通信在一個大型分布式系統(tǒng)中的應用 ， 那么這一小節(jié)我們就來說說異步通信 。首先我們想想，假如系統(tǒng)有 A和 B兩個子系統(tǒng)構(gòu)成，假如 A 和 B是同步通信的話，那么要想使得系統(tǒng)整體伸縮性提高必須同時對 A和 B 進行伸縮，這就影響了對整個系統(tǒng)進行 scal