【正文】 (我覺得最大的好處 )是你可以看到軟件的源碼，你可以研究了解軟件內(nèi)部的工作過程、原理。這對于應(yīng)用設(shè)計、開發(fā)、查錯、優(yōu)化都是非常有幫助的。 淘寶網(wǎng)的開源觀 對于開源軟件的應(yīng)用，有些人可能擔(dān)心質(zhì)量的問題，有些人可能擔(dān)心軟件本身發(fā)展更新的問題，等等。對于質(zhì)量的問題 ，我想現(xiàn)在很多的開源軟件尤其是一些很著名的開源軟件都有很完善的組織，有完善的開發(fā)、測試、發(fā)布流程。在一個新版本完成前，會有多次的測試版本發(fā)布，最后才是正式版。這和商業(yè)軟件是一樣的。并且因為代碼公開，反而更加的容易發(fā)現(xiàn)錯誤，提高質(zhì)量。至于第二個問題，我想跟第一個問題一樣，關(guān)鍵是組織和規(guī)劃而不在是否開源，并且在很多著名的開源軟件背后，會有廠商在進(jìn)行支持。軟件本身的發(fā)展應(yīng)該是不會成為問題的，不太會出現(xiàn)軟件突然停止發(fā)展的情況。 在今后的發(fā)展中，我們還是會一如既往的關(guān)注開源軟件的發(fā)展，也還會根據(jù)需要采用不同的開源軟件 。在選擇一個開源產(chǎn)品的時候，我會考慮以下幾點(diǎn)： 1. 這個軟件目前的功能和它的 RoadMap 2. 軟件本身的架構(gòu) 3. 該軟件開發(fā)的活躍度 4. 該開源軟件是否是遵守該領(lǐng)域內(nèi)的國際規(guī)范的 5. 在同類產(chǎn)品中，要挑選有比較優(yōu)勢的。并且要考慮可能存在的移植代價。這個移植指的是采用了這款開源軟件后現(xiàn)有系統(tǒng)的移植，或者是從這個開源軟件到其他軟件的移植。 對于企業(yè)級系統(tǒng)、互聯(lián)網(wǎng)應(yīng)用來說，采用開源軟件不僅可以降低成本，更重要的是能夠真正了解軟件的內(nèi)部工作機(jī)制。還可以在現(xiàn)在的基礎(chǔ)上進(jìn)行增強(qiáng)和定制，也能夠從開源軟件 第 4 頁 中借鑒 到很多好的設(shè)計和實現(xiàn)。希望國內(nèi)能有更多的企業(yè)在使用開源軟件的同時，也能開源自身的一些軟件，或者能夠成為一些開源軟件的貢獻(xiàn)者。而作為淘寶網(wǎng)，我們也會非常積極的參與到開源的活動中，也會努力為開源的發(fā)展做出我們應(yīng)有的貢獻(xiàn)。 . 高性能可伸縮 . 應(yīng)用無狀態(tài) 一個系統(tǒng)的伸縮性的好壞取決于應(yīng)用的狀態(tài)如何管理。試想一下，假如我們在 session中保存了大量與客戶端的狀態(tài)信息的話，那么當(dāng)保存狀態(tài)信息的 server 宕機(jī)的時候，我們怎么辦 ？ 通常來說，我們都是通過集群來解決這個問題，而通常所說的集群，不僅有負(fù)載均衡，更重要的是要有失效 恢復(fù) failover,比如 tomcat 采用的集群節(jié)點(diǎn)廣播復(fù)制， jboss 采用的配對復(fù)制等 session 狀態(tài)復(fù)制策略，但是集群中的狀態(tài)恢復(fù)也有其缺點(diǎn)，那就是嚴(yán)重影響了系統(tǒng)的伸縮性 ， 系統(tǒng)不能通過增加更多的機(jī)器來達(dá)到良好的水平伸縮，因為集群節(jié)點(diǎn)間 session的通信會隨著節(jié)點(diǎn)的增多而開銷增大，因此要想做到應(yīng)用本身的伸縮性，我們需要保證應(yīng)用的無狀態(tài)性，這樣集群中的各個節(jié)點(diǎn)來說都是相同的，從而是的系統(tǒng)更好的水平伸縮。 上面說了無狀態(tài)的重要性，那么具體如何實現(xiàn)無狀態(tài)呢？此時一個 session 框架就會發(fā)揮作用了。幸運(yùn)的是 公司已經(jīng)具有了此類框架。公司的 session 框架采用的是 client cookie實現(xiàn)，主要將狀態(tài)保存到了 cookie 里面，這樣就使得應(yīng)用節(jié)點(diǎn)本身不需要保存任何狀態(tài)信息 ， 這樣在系統(tǒng)用戶變多的時候，就可以通過增加更多的應(yīng)用節(jié)點(diǎn)來達(dá)到水平擴(kuò)展的目的 。但是采用客戶端 cookie 的方式來保存狀態(tài)也會遇到限制，比如每個 cookie 一般不能超過 4K的大小，同時很多瀏覽器都限制一個站點(diǎn)最多保存 20個 cookie。 公司 cookie 框架采用的是“ 多值 cookie” ，就是一個組合鍵對應(yīng)多個 cookie 的值 ， 這樣不僅可以防止 cookie 數(shù)量超過 20， 同時還節(jié)省了 cookie 存儲有效信息的空間，因為默認(rèn)每個 cookie 都會有大約 50 個字節(jié)的元信息來描述 cookie。 除了公司目前的 session 框架的實現(xiàn)方式以外，其實集中式 session 管理來完成，說具體點(diǎn)就是多個無狀態(tài)的應(yīng)用節(jié)點(diǎn)連接一個 session 服務(wù)器 ， session 服務(wù)器將 session 保存到緩存中， session 服務(wù)器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫，文件系統(tǒng)等等。 第 5 頁 . 有效使用緩存 做互聯(lián)網(wǎng)應(yīng)用的兄弟應(yīng)該都清楚，緩存對于一個互聯(lián)網(wǎng)應(yīng)用是多么的重要，從瀏覽器緩存，反向 代理緩存，頁面緩存，局部頁面緩存，對象緩存等等都是緩存應(yīng)用的場景。 一般來說緩存根據(jù)與應(yīng)用程序的遠(yuǎn)近程度不同可以分為 ： local cache 和 remote cache。 一般系統(tǒng)中要么采用 local cache，要么采用 remote cache， 兩者混合使用的話對于 local cache 和 remote cache 的數(shù)據(jù)一致性處理會變大比較麻煩 。 在大部分情況下 ， 我們所說到的緩存都是讀緩存 ， 緩存還有另外一個類型 ： 寫緩存 。 對于一些讀寫比不高，同時對數(shù)據(jù)安全性需求不高的數(shù)據(jù)，我們可以將其緩存起來從而減少對底層 數(shù)據(jù)庫的訪問 ， 比如統(tǒng)計商品的訪問次數(shù) ， 統(tǒng)計 API 的調(diào)用量等等 ， 可以采用先寫內(nèi)存緩存然后延遲持久化到數(shù)據(jù)庫，這樣可以大大減少對數(shù)據(jù)庫的寫壓力。 以店鋪線的系統(tǒng)為例，在用戶瀏覽店鋪的時候，比如店鋪介紹，店鋪交流區(qū)頁面，店鋪服務(wù)條款頁面，店鋪試衣間頁面，以及店鋪內(nèi)搜索界面這些界面更新不是非常頻繁，因此適合放到緩存中，這樣可以大大減低 DB 的負(fù)載。另外寶貝詳情頁面相對也更新比較少，因此也適合放到緩存中來減低 DB 負(fù)載。 . 應(yīng)用拆分 首先，在說明應(yīng)用拆分之前，我們先來回顧一下一個系統(tǒng)從小變大的過程中遇到的一些問題，通過這些 問題我們會發(fā)現(xiàn)拆分對于構(gòu)建一個大型系統(tǒng)是如何的重要。 系統(tǒng)剛上線初期，用戶數(shù)并不多，所有的邏輯也許都是放在一個系統(tǒng)中的，所有邏輯跑到一個進(jìn)程或者一個應(yīng)用當(dāng)中，這個時候因為比較用戶少，系統(tǒng)訪問量低，因此將全部的邏輯都放在一個應(yīng)用未嘗不可。但是，兄弟們都清楚，好景不長，隨著系統(tǒng)用戶的不斷增加，系統(tǒng)的訪問壓力越來越多，同時隨著系統(tǒng)發(fā)展，為了滿足用戶的需求，原有的系統(tǒng)需要增加新的功能進(jìn)來，系統(tǒng)變得越來越復(fù)雜的時候，我們會發(fā)現(xiàn)系統(tǒng)變得越來越難維護(hù)，難擴(kuò)展，同時系統(tǒng)伸縮性和可用性也會受到影響。那么這個時候我們?nèi)绾谓鉀Q這 些問題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來的系統(tǒng)根據(jù)一定的標(biāo)準(zhǔn)，比如業(yè)務(wù)相關(guān)性等分為不同的子系統(tǒng)，不同的系統(tǒng)負(fù)責(zé)不同的功能，這樣切分以后，我們可以對單獨(dú)的子系統(tǒng)進(jìn)行擴(kuò)展和維護(hù)，從而提高系統(tǒng)的擴(kuò)展性和可維護(hù)性，同時我們系統(tǒng)的水平伸縮性 scale out 大大的提升了，因為我們可以有針對性的對壓力大的子系統(tǒng)進(jìn)行水平擴(kuò)展而不會影響到其它的子系統(tǒng)，而不會像拆分以前，每次系統(tǒng)壓力變大的時候，我們都 需要對整 個大系統(tǒng) 第 6 頁 進(jìn)行伸縮，而這樣的成本是比較大的，另外經(jīng)過切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當(dāng) 某個子系統(tǒng)暫時不可用的時候，整體系統(tǒng)還是可用的，從而整體系統(tǒng)的可用性也大大增強(qiáng)了。 因此一個大型的互聯(lián)網(wǎng)應(yīng)用，肯定是要經(jīng)過拆分，因為只有拆分了，系統(tǒng)的擴(kuò)展性，維護(hù)性 ， 伸縮性，可用性才會變的更好。但是拆分也給系統(tǒng)帶來了問題，就是子系統(tǒng)之間如何通信的問題，而具體的通信方式有哪些呢？一般有同步通信和異步通信，這里我們首先來說下同步通信，下面的主題 “ 消息系統(tǒng) ” 會說到異步通信。既然需要通信，這個時候一個高性能的遠(yuǎn)程調(diào)用框架就顯得非?？傄?，因此咱們公司也有了自己的 HSF 框架。 上面所說的都是拆分的好處，但是拆分以后必 然的也會帶來新的問題，除了剛才說的子系統(tǒng)通信問題外，最值得關(guān)注的問題就是系統(tǒng)之間的依賴關(guān)系，因為系統(tǒng)多了，系統(tǒng)的依賴關(guān)系就會變得復(fù)雜，此時就需要更好的去關(guān)注拆分標(biāo)準(zhǔn)，比如能否將一些有依賴的系統(tǒng)進(jìn)行垂直化，使得這些系統(tǒng)的功能盡量的垂直，這也是目前公司正在做的系統(tǒng)垂直化，同時一定要注意系統(tǒng)之間的循環(huán)依賴，如果出現(xiàn)循環(huán)依賴一定要小心，因為這可能導(dǎo)致系統(tǒng)連鎖啟動失敗。 既然明白了拆分的重要性，我們看看隨著公司的發(fā)展，公司本身是如何拆分系統(tǒng)的。 在這個演變的過程中，我們所說的拆分就出現(xiàn) 和 之間。在 ，公司幾乎所有的邏輯都放在一個系統(tǒng)中，這樣導(dǎo)致的問題就是系統(tǒng)擴(kuò)展和修改非常麻煩，并且更加致命的是隨著公司業(yè)務(wù)量的增加，如果按照 的架構(gòu)已經(jīng)沒有辦法支撐以后公司的快速發(fā)展，因此大家決定對整個系統(tǒng)進(jìn)行拆分 ， 版本的系統(tǒng)對整個系統(tǒng)進(jìn)行了水平和垂直兩個方向的拆分，水平方向上，按照功能分為交易，評價，用戶，商品等系統(tǒng)，同樣垂直 方向上，劃分為業(yè)務(wù)系統(tǒng)，核心業(yè)務(wù)系統(tǒng)以及 基礎(chǔ)服務(wù)，這樣以來，各個系統(tǒng)都可以獨(dú)立維護(hù)和獨(dú)立的進(jìn)行水平伸縮，比如交易系統(tǒng)可以在不影響其它系統(tǒng)的情況下獨(dú)立的進(jìn)行水平伸縮以及功能擴(kuò)展 。 從上面可以看出，一個大型系統(tǒng)要想變得可維護(hù)，可擴(kuò)展，可伸縮，我們必須的對它進(jìn)行拆分，拆分必然也帶來系統(tǒng)之間如何通信以及系統(tǒng)之間依賴管理等問題，關(guān)于通信方面，公司目前獨(dú)立開發(fā)了自己的高性能服務(wù)框架 HSF，此框架主要解決了公司目前所有子系統(tǒng)之間的同步和異步通信（目前 HSF 主要用于同步場合， FutureTask 方式的調(diào)用場景還比較少）。至于系統(tǒng)間的依賴管理，目前公司還做的不夠好，這應(yīng)該也是我們以后努力解決的問題。 第 7 頁 . 數(shù)據(jù)庫拆分 在前面 “ 應(yīng)用拆分 ” 主題中，我們提到了一個大型互聯(lián)網(wǎng)應(yīng)用需要進(jìn)行良好的拆分，而那里我們 僅僅說了 “ 應(yīng)用級別 ” 的拆分，其實我們的互聯(lián)網(wǎng)應(yīng)用除了應(yīng)用級別的拆分以外，還有另外一個很重要的層面就是存儲如何拆分的。因此這個主題主要涉及到如何對存儲系統(tǒng)，通常就是所說的 RDBMS 進(jìn)行拆分。 好了，確定了這個小節(jié)的主題之后，我們回顧一下，一個互聯(lián)網(wǎng)應(yīng)用從小變大的過程中遇到的一些問題，通過遇到的問題來引出我們拆分 RDBMS 的重要性。 系統(tǒng)剛開始的時候，因為系統(tǒng)剛上線，用戶不多，那個時候，所有的數(shù)據(jù)都放在了同一個數(shù)據(jù)庫中，這個時候因為用戶少壓力小，一個數(shù)據(jù)庫完全可以應(yīng)付的了，但是隨著運(yùn)營那些哥們辛苦的吶喊和拼命的 推廣以后，突然有一天發(fā)現(xiàn)， oh,god,用戶數(shù)量突然變多了起來，隨之而來的就是數(shù)據(jù)庫這哥們受不了，它終于在某一天大家都和愜意的時候掛掉啦。此時，咱們搞技術(shù)的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)現(xiàn)原來是數(shù)據(jù)庫讀取壓力太大了，此時咱們都清楚是到了讀寫分離的時候，這個時候我們會配置一個 server 為 master節(jié)點(diǎn)，然后配幾個 salve 節(jié)點(diǎn)，這樣以來通過讀寫分離，使得讀取數(shù)據(jù)的壓力分?jǐn)偟搅瞬煌?salve 節(jié)點(diǎn)上面，系統(tǒng)終于又恢復(fù)了正常，開始正常運(yùn)行了。但是好景還是不長，有一天我們發(fā)現(xiàn) master 這哥們撐 不住了，它負(fù)載老高了，汗流浹背，隨時都有翹掉的風(fēng)險，這個時候就需要咱們垂直分區(qū)啦（也就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同的數(shù)據(jù)庫中，同時還可以針對商品信息的庫采用 master， salve 模式， OK，通過分庫以后，各個按照功能拆分的數(shù)據(jù)庫寫壓力被分擔(dān)到了不同的 server 上面，這樣數(shù)據(jù)庫的壓力終于有恢復(fù)到正常狀態(tài)。但是是不是這樣，我們就可以高枕無憂了呢？ NO,這個 NO，不是我說的，是前輩們通過經(jīng)驗總結(jié)出來的，隨著用戶量的不斷增加，你會發(fā)現(xiàn)系統(tǒng)中的某些表會變的異常龐大，比如好友關(guān)系 表，店鋪的參數(shù)配置表等，這個時候 無論是寫入還是讀取這些表的數(shù)據(jù)，對數(shù)據(jù)庫來說都是一個很耗費(fèi)精力的事情，因此此時就需要我們進(jìn)行 “ 水平分區(qū) ” 了（這就是俗話說的分表，或者說 sharding） 。 上面說了一大堆，無非就是告訴大家一個事實 “ 數(shù)據(jù)庫是系統(tǒng)中最不容易 scale out 的一層 ” ，一個大型的互聯(lián)網(wǎng)應(yīng)用必然會經(jīng)過一個從單一 DB server， 到 Master/salve， 再到垂直分區(qū)（分庫） ， 然后再到水平分區(qū)（分表 ， sharding）的過程，而在這個過程中， Master/salve 以及垂直分區(qū)相對比較容易，對 應(yīng)用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區(qū) join 查詢數(shù)據(jù)，如何平衡各個 shards 的負(fù)載等等，這個時候 第 8 頁 就需要一個通用的 DAL 框架來屏蔽底層數(shù)據(jù)存儲對應(yīng)用邏輯的影響，使得底層數(shù)據(jù)的訪問對應(yīng)用透明化。 拿公司目前的情況來說，公司目前也正在從昂貴的高端存儲（小型機(jī) +ORACLE）切換到 MYSQL， 切換到 MYSQL 以后，勢必會遇到垂直分區(qū)（分庫）以及水平分區(qū)（ Sharding）的問題，因此目前公司根據(jù)自己的業(yè)務(wù)特點(diǎn)也開發(fā)了自己的 TDDL 框架，此框架主要解決了分庫分表對應(yīng)用的透明化以及 異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制。 . 異步通信 在 “ 遠(yuǎn)程調(diào)用框架 ” 的介紹中 ， 我們說了一個大型的系統(tǒng)為了擴(kuò)展性和伸縮性方面的需求 ， 肯定是要進(jìn)行拆分 ， 但是拆分了以后 ， 子系統(tǒng)之間如何通信就成了我們首要的問題 ， 在“ 遠(yuǎn)程調(diào)用框架 ” 小節(jié)中 ， 我們說了同步通信在一個大型分布式系統(tǒng)中的應(yīng)用 ， 那么這一小節(jié)我們就來說說異步通信 。 好了 ， 既然說到了異步通信 ,那么 “ 消息中間件 ” 就要登場了 ,采用異步通信這其實也是關(guān)系到系統(tǒng)的伸縮性 ， 以及最大化的對各個子系統(tǒng)進(jìn)行解耦 。 說到異步通信，我們需要關(guān)注的一點(diǎn)是這里的異步一定是根據(jù)業(yè)務(wù)特點(diǎn)來的，一定是針對業(yè) 務(wù)的異步，通常適合異步的場合是一些松耦合的通信場合，而對于本身業(yè)務(wù)上關(guān)聯(lián)度比較大的業(yè)務(wù)系統(tǒng)之間，我們還是要采用同步通信比較靠譜。 那么下一步我們說說異步能給系統(tǒng)帶