|
|
經(jīng)歷了最近幾個月易訊網(wǎng)新版本的緊張開發(fā)及上線調(diào)試之后，總算能夠暫時靜下心來考慮網(wǎng)站的下一步計(jì)劃及如何通過網(wǎng)絡(luò)來如何吸引用戶。
本來很早就想與朋友們一起分享下自己在開發(fā)易訊網(wǎng)過程中對網(wǎng)站架構(gòu)和設(shè)計(jì)和經(jīng)驗(yàn)和看法，但那時因?yàn)樯弦话姹驹S多東西還欠缺考慮只好做罷。現(xiàn)在，終于有時間能夠分享下自己的經(jīng)驗(yàn)并大家交流和探討。
什么是易訊網(wǎng)（econfeed.com)？如果您知道國外的DIGG網(wǎng)站，那么您也就知道了什么是易訊網(wǎng)。它是分享互聯(lián)網(wǎng)資訊內(nèi)容的社交網(wǎng)站。創(chuàng)建易訊網(wǎng)的靈感就源自于DIGG網(wǎng)站，而我那時也想自己開發(fā)個社區(qū)型的網(wǎng)站以積累和了解網(wǎng)站架構(gòu)方面的經(jīng)驗(yàn)。
平臺
ASP.NET(.NET framework 3.5)
Sql Server 2005
Windows Service
.NET Task Service － 作業(yè)計(jì)劃服務(wù)
TaskFarmer － 分布式的任務(wù)系統(tǒng)服務(wù)
Lucene.NET
Memcached
Arachnode.NET － .NET下的搜索引擎，基于Lucene搜索
下面這張圖能夠描述易訊網(wǎng)內(nèi)部如何運(yùn)作。
如何創(chuàng)建一個好的架構(gòu)一直是一件讓人頭疼差事，因?yàn)槟仨氁紤]許多因素，包括性能，可擴(kuò)展性，穩(wěn)定性等以及如何從這中間取一個平衡點(diǎn)。
網(wǎng)站邏輯架構(gòu)
易訊網(wǎng)的 網(wǎng)站邏輯架構(gòu)依照了CS（Community Service）的架構(gòu)，特別是采用模塊（插件），皮膚的方式。我一直是CS架構(gòu)的擁護(hù)者，從最早的ASPNETForums到現(xiàn)在的Community Service。易訊網(wǎng)最初版本是采用CS的數(shù)據(jù)庫，雖然它的數(shù)據(jù)庫設(shè)計(jì)為應(yīng)用程序提供了很大的擴(kuò)展性，但也犧牲了性能為代價，以至后來性能成為問題，不 得不放棄完全按自己網(wǎng)站的需求來設(shè)計(jì)。
下面這張是網(wǎng)站的配置和設(shè)計(jì)邏輯圖。
網(wǎng)站的性能優(yōu)化
網(wǎng)站的性能的優(yōu)化主要有針對的從幾個大的方面進(jìn)行優(yōu)化。
一篇很有幫助的文章：10個ASP.NET性能和可擴(kuò)展性的秘密
2. 壓縮頁面文件大小
壓縮文件的大小是減少帶寬的使用以及用戶的瀏覽體驗(yàn)。
1.主要使用HttpModule的方式壓縮頁面文件大小。
2.針對不需要回發(fā)的頁面移除了Form表單標(biāo)簽和ViewState。
3. 改善了控件自動生產(chǎn)的ID。如果您是個有心人，您會發(fā)現(xiàn)在登錄頁控件呈現(xiàn)的ID名稱是“S1_S1_S1_S5_S2_S1_S1_S2”，而原本應(yīng)該呈 現(xiàn)的內(nèi)容大概是："Ctr1_Ctrl1_SiteMaster_MainContainer_Ctrl1_TxtLogin“（當(dāng)然，真正呈現(xiàn)的要比這 個長，這里只是做個假設(shè)，它應(yīng)該是總共帶8個控件編號，這也是我為什么不喜歡ASP.NET的一個原因）。如果您也想壓縮控件ID，您可以參考這篇文章：改善控件的自動生成的ID
3. 壓縮CSS,JS,Image
圖像壓縮的方式您只有一種選擇，使用圖像工具。笑。
我使用YUI Compressor來壓縮CSS,JS。因?yàn)槲矣X得它在準(zhǔn)確率和壓縮率在所有一些壓縮工具中是最好的一個。
4. 緩存
合理的使用瀏覽器緩存和應(yīng)用程序緩存是關(guān)鍵。針對用戶頭像，新聞的略縮圖使用瀏覽器緩存。關(guān)于圖像及略縮圖，關(guān)于采用略縮圖的原則將會在后面提到。
網(wǎng)站的緩存使用
采用緩 存主要還是為了減輕數(shù)據(jù)庫IO的壓力以及提高網(wǎng)站的性能。可以說，緩存的使用在易訊網(wǎng)中無所無在。易訊網(wǎng)采用是分布式緩存與本地緩存以及線程緩存相結(jié)合的 策略。像配置的基本采用本地文件依賴緩存。但是一些更頻繁使用的數(shù)據(jù)采用的分布式緩存>>本地緩存方式。
易訊網(wǎng)采用的是 Memcached做為分布式的緩存服務(wù)。網(wǎng)站的大部分緩存都是采用分布式緩存的方式緩存數(shù)據(jù)。根據(jù)需求，我將數(shù)據(jù)緩存分成二類，一類是基本不會更新數(shù) 據(jù)，像新聞內(nèi)容，一類是時時可能會變化的數(shù)據(jù)，像新聞統(tǒng)計(jì)。因此，對新聞的緩存將獨(dú)立分成二份，一份是基本信息的緩存，一份是統(tǒng)計(jì)的緩存。假設(shè)現(xiàn)在您為某 個資訊提交新的評論或者投票的時候，那么，統(tǒng)計(jì)的緩存會將馬上變化。為了壓縮緩存數(shù)據(jù)的大小提交傳輸速度，易訊網(wǎng)采用了自定義序列化的方式，它將 比.NET默認(rèn)自定義序列化能夠減少2/3大小（沒有詳細(xì)測試過）并具有更高的序列化性能。當(dāng)然，它犧牲靈活性，意味著如果我更改緩存數(shù)據(jù)的實(shí)體類，必須 重啟緩存服務(wù)，否則，將會觸發(fā)異常。部分內(nèi)容采用了控件緩存的方式。
數(shù)據(jù)庫
到目前為止，除了對數(shù)據(jù)庫查詢優(yōu)化之外，并沒有對數(shù)據(jù)庫進(jìn)行過多的優(yōu)化。用了聚焦索引和非聚焦索引是關(guān)鍵。數(shù)據(jù)庫優(yōu)化是長期的過程。
略縮圖
上面有提到過圖像的略縮圖處理。易訊網(wǎng)對略縮圖的原則就是：
on-the-fly image resizing with Disk-caching
也說是說，動態(tài)生成圖像略縮圖并進(jìn)行硬盤緩存。為什么采用這原則呢？當(dāng)初采用哪種原則
是 有很考慮，當(dāng)然現(xiàn)在只考慮下面幾點(diǎn)， 一考慮到略縮圖的大小可能會隨以后網(wǎng)站的設(shè)計(jì)改變而改變，二是生成略縮圖之后在將來很長很長的時間內(nèi)不會變化。使用HttpModule模塊的方式代替 HttpHandler生成略縮圖。因?yàn)镠ttpHandler擴(kuò)展性上遠(yuǎn)遠(yuǎn)沒有HttpModule靈活。
TaskFarmer
創(chuàng) 建這個組件的靈感源自Gearman以及Digg網(wǎng)站架構(gòu)介紹。它是一個分布式任務(wù)執(zhí)行服務(wù)，您可以在本地服務(wù)器上執(zhí)行的任何分配給B服務(wù)器并等待返回B 返回值。目前主要是郵件發(fā)送和資訊的內(nèi)容抓取采用這種方式。現(xiàn)在TaskFarmer只是一個簡單的組件，自己依照Memcached協(xié)議開發(fā)的服務(wù)端， 這樣一來，我原本使用的Memcached的客戶端組件只需要簡單修改就可以馬上使用，目前TaskFarmer并不會返回處理的值，但對易訊網(wǎng)目前來說 已經(jīng)足夠了。除了那個等待處理的頁面無法精確判斷是否抓取內(nèi)容處理成功之外，其它還是非常理想。呵。
Lucene.NET
Lucene 早期是應(yīng)用在易訊網(wǎng)的網(wǎng)絡(luò)蛛蜘(后面我會提到這個系統(tǒng)）上面。采用了MMSEG中文分詞，目前主要應(yīng)用在相關(guān)資訊搜索方面。現(xiàn)在正考慮將易訊網(wǎng)上面的用戶 好友日志或者DIGG的日志移到Lucene上查詢。Lucene索引分成二部分，一部分是：WorkingIndex或ActivityIndex，前 者用于索引易訊網(wǎng)新的內(nèi)容，當(dāng)全部索引全部完成之后自動添加到ActivityIndex中，這樣保證當(dāng)working index的索引庫異常也不會影響正常環(huán)境下的索引庫。Lucene何時開始索引是基于Task Schedule服務(wù)的配置。
在這里提一個非常有意義的.NET下的搜索引擎項(xiàng)目：ArachNode.NET。 當(dāng)時它一出來就開始注意到了，現(xiàn)在也已經(jīng)非常成熟。易訊網(wǎng)也經(jīng)歷了一段時間搜索方面開發(fā)，早期創(chuàng)建易訊網(wǎng)的時候，是想結(jié)合搜索引擎的技術(shù)結(jié)合用戶DIGG 的方法提高用戶網(wǎng)上閱讀的體驗(yàn)。但是因?yàn)锳rachnode.NET太過完美及復(fù)雜，另外就是特別吃內(nèi)存，不得不放棄。另外一原因在于服務(wù)器根本就沒有太 多的硬盤空間來存放WEB網(wǎng)頁數(shù)據(jù)。如果您對Arachnode.NET感興趣，可以關(guān)注我的BLOG，下次會詳細(xì)介紹，目前正打算移植它的核心代碼根據(jù) 自己的需求創(chuàng)建一個小型靈活的搜索引擎。
現(xiàn)在網(wǎng)上流行AJAX技術(shù)，易訊網(wǎng)并沒有大量的使用AJAX，特別是那種一打開頁面就顯示 Loading效果的技術(shù)。一是出于SEO考慮，二是沒有覺得有特別適合那種非要AJAX才可的地方。 合適的使用AJAX確實(shí)能為用戶提高更好的體驗(yàn)，我自己更傾向于大部的js加上部分的ajax的方式來達(dá)到用戶的體驗(yàn)。
在新版本開發(fā)之 初，原來有意想為易訊網(wǎng)采用異步多線程任務(wù)的方式提高IO的密集處理。網(wǎng)上也看到一些比較優(yōu)秀的文章和成熟的組件， 但是自己一因?yàn)椴惶私猓遣涣?xí)慣ASP.NET自帶的那種異步注冊方式，另外一點(diǎn)自己的要求比較特殊，就是它的多線程不應(yīng)該使用ASP.NET默認(rèn)線 程池中的線程。也許以后有機(jī)會還是會考慮異步的方式，特別是顯示資訊的詳細(xì)頁的時候。
整個易訊網(wǎng)前后經(jīng)歷了差不多近一年時間，目前的新版本花了近三個多月時間，當(dāng)然這幾個月也是收獲最大的幾個月，自己也為易訊網(wǎng)完成了幾個自己的組件，包括上面提到的TaskFarmer,MMSEG.NET以及新聞內(nèi)容的提取，這些，也算是易訊網(wǎng)自己擁有自己的特色吧。
如果您想更好的理解易訊網(wǎng)，建議您可以訪問易訊網(wǎng)親自體驗(yàn)下。您可以通過http://www.econfeed.com訪問。
原創(chuàng)文章，轉(zhuǎn)載請注明出處和鏈接。謝謝配合。
it知識庫：淺談易訊網(wǎng)架構(gòu)，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
