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