淺談易訊網架構

經曆了最近幾個月易訊網新版本的緊張開發及上線調試之後，總算能夠暫時靜下心來考慮網站的下一步計劃及如何通過網絡來如何吸引使用者。

本來很早就想與朋友們一起分享下自己在開發易訊網過程中對網站架構和設計和經驗和看法，但那時因為上一版本許多東西還欠缺考慮隻好做罷。現在，終于有時間能夠分享下自己的經驗并大家交流和探讨。

什麼是易訊網（econfeed.com)？如果您知道國外的DIGG網站，那麼您也就知道了什麼是易訊網。它是分享網際網路資訊内容的社交網站。建立易訊網的靈感就源自于DIGG網站，而我那時也想自己開發個社群型的網站以積累和了解網站架構方面的經驗。

平台

ASP.NET(.net framework 3.5)

Sql Server 2005

Windows Service

.Net Task Service － 作業計劃服務

TaskFarmer － 分布式的任務系統服務

Lucene.Net

Memcached

Arachnode.net － .NET下的搜尋引擎，基于Lucene搜尋

下面這張圖能夠描述易訊網内部如何運作。

易訊網架構

如何建立一個好的架構一直是一件讓人頭疼差事，因為您必須要考慮許多因素，包括性能，可擴充性，穩定性等以及如何從這中間取一個平衡點。

網站邏輯架構

易訊網的 網站邏輯架構依照了CS（Community Service）的架構，特别是采用子產品（插件），皮膚的方式。我一直是CS架構的擁護者，從最早的AspnetForums到現在的Community Service。易訊網最初版本是采用CS的資料庫，雖然它的資料庫設計為應用程式提供了很大的擴充性，但也犧牲了性能為代價，以至後來性能成為問題，不 得不放棄完全按自己網站的需求來設計。

下面這張是網站的配置和設計邏輯圖。

易訊網站邏輯架構

網站的性能優化

網站的性能的優化主要有針對的從幾個大的方面進行優化。

1.  ASP.NET

一篇很有幫助的文章：10個ASP.NET性能和可擴充性的秘密

2. 壓縮頁面檔案大小

壓縮檔案的大小是減少帶寬的使用以及使用者的浏覽體驗。

1.主要使用HttpModule的方式壓縮頁面檔案大小。

2.針對不需要回發的頁面移除了Form表單标簽和ViewState。

3. 改善了控件自動生産的ID。如果您是個有心人，您會發現在登入頁控件呈現的ID名稱是“S1_S1_S1_S5_S2_S1_S1_S2”，而原本應該呈 現的内容大概是："Ctr1_Ctrl1_SiteMaster_MainContainer_Ctrl1_TxtLogin“（當然，真正呈現的要比這 個長，這裡隻是做個假設，它應該是總共帶8個控件編号，這也是我為什麼不喜歡ASP.NET的一個原因）。如果您也想壓縮控件ID，您可以參考這篇文章：改善控件的自動生成的ID

3. 壓縮CSS,JS,Image

圖像壓縮的方式您隻有一種選擇，使用圖像工具。笑。

我使用YUI Compressor來壓縮CSS,JS。因為我覺得它在準确率和壓縮率在所有一些壓縮工具中是最好的一個。

4. 緩存

合理的使用浏覽器緩存和應用程式緩存是關鍵。針對使用者頭像，新聞的略縮圖使用浏覽器緩存。關于圖像及略縮圖，關于采用略縮圖的原則将會在後面提到。

網站的緩存使用

采用緩 存主要還是為了減輕資料庫IO的壓力以及提高網站的性能。可以說，緩存的使用在易訊網中無所無在。易訊網采用是分布式緩存與本地緩存以及線程緩存相結合的 政策。像配置的基本采用本地檔案依賴緩存。但是一些更頻繁使用的資料采用的分布式緩存>>本地緩存方式。

易訊網采用的是 Memcached做為分布式的緩存服務。網站的大部分緩存都是采用分布式緩存的方式緩存資料。根據需求，我将資料緩存分成二類，一類是基本不會更新數 據，像新聞内容，一類是時時可能會變化的資料，像新聞統計。是以，對新聞的緩存将獨立分成二份，一份是基本資訊的緩存，一份是統計的緩存。假設現在您為某 個資訊送出新的評論或者投票的時候，那麼，統計的緩存會将馬上變化。為了壓縮緩存資料的大小送出傳輸速度，易訊網采用了自定義序列化的方式，它将 比.NET預設自定義序列化能夠減少2/3大小（沒有詳細測試過）并具有更高的序列化性能。當然，它犧牲靈活性，意味着如果我更改緩存資料的實體類，必須 重新開機緩存服務，否則，将會觸發異常。部分内容采用了控件緩存的方式。

資料庫

到目前為止，除了對資料庫查詢優化之外，并沒有對資料庫進行過多的優化。用了聚焦索引和非聚焦索引是關鍵。資料庫優化是長期的過程。

略縮圖

上面有提到過圖像的略縮圖處理。易訊網對略縮圖的原則就是：

on-the-fly image resizing with Disk-caching

也說是說，動态生成圖像略縮圖并進行硬碟緩存。為什麼采用這原則呢？當初采用哪種原則

是 有很考慮，當然現在隻考慮下面幾點， 一考慮到略縮圖的大小可能會随以後網站的設計改變而改變，二是生成略縮圖之後在将來很長很長的時間内不會變化。使用HttpModule子產品的方式代替 HttpHandler生成略縮圖。因為HttpHandler擴充性上遠遠沒有HttpModule靈活。

TaskFarmer

創 建這個元件的靈感源自Gearman以及Digg網站架構介紹。它是一個分布式任務執行服務，您可以在本地伺服器上執行的任何配置設定給B伺服器并等待傳回B 傳回值。目前主要是郵件發送和資訊的内容抓取采用這種方式。現在TaskFarmer隻是一個簡單的元件，自己依照Memcached協定開發的服務端， 這樣一來，我原本使用的Memcached的用戶端元件隻需要簡單修改就可以馬上使用，目前TaskFarmer并不會傳回處理的值，但對易訊網目前來說 已經足夠了。除了那個等待處理的頁面無法精确判斷是否抓取内容處理成功之外，其它還是非常理想。呵。

Lucene.net

Lucene 早期是應用在易訊網的網絡蛛蜘(後面我會提到這個系統）上面。采用了MMSEG中文分詞，目前主要應用在相關資訊搜尋方面。現在正考慮将易訊網上面的使用者 好友日志或者DIGG的日志移到Lucene上查詢。Lucene索引分成二部分，一部分是：WorkingIndex或ActivityIndex，前 者用于索引易訊網新的内容，當全部索引全部完成之後自動添加到ActivityIndex中，這樣保證當working index的索引庫異常也不會影響正常環境下的索引庫。Lucene何時開始索引是基于Task Schedule服務的配置。

在這裡提一個非常有意義的.net下的搜尋引擎項目：ArachNode.Net。 當時它一出來就開始注意到了，現在也已經非常成熟。易訊網也經曆了一段時間搜尋方面開發，早期建立易訊網的時候，是想結合搜尋引擎的技術結合使用者DIGG 的方法提高使用者網上閱讀的體驗。但是因為Arachnode.net太過完美及複雜，另外就是特别吃記憶體，不得不放棄。另外一原因在于伺服器根本就沒有太 多的硬碟空間來存放WEB網頁資料。如果您對Arachnode.net感興趣，可以關注我的BLOG，下次會詳細介紹，目前正打算移植它的核心代碼根據 自己的需求建立一個小型靈活的搜尋引擎。

現在網上流行AJAX技術，易訊網并沒有大量的使用AJAX，特别是那種一打開頁面就顯示 Loading效果的技術。一是出于SEO考慮，二是沒有覺得有特别适合那種非要AJAX才可的地方。 合适的使用AJAX确實能為使用者提高更好的體驗，我自己更傾向于大部的js加上部分的ajax的方式來達到使用者的體驗。

在新版本開發之 初，原來有意想為易訊網采用異步多線程任務的方式提高IO的密集處理。網上也看到一些比較優秀的文章和成熟的元件， 但是自己一因為不太了解，二是不習慣ASP.NET自帶的那種異步注冊方式，另外一點自己的要求比較特殊，就是它的多線程不應該使用Asp.net預設線 程池中的線程。也許以後有機會還是會考慮異步的方式，特别是顯示資訊的詳細頁的時候。

整個易訊網前後經曆了差不多近一年時間，目前的新版本花了近三個多月時間，當然這幾個月也是收獲最大的幾個月，自己也為易訊網完成了幾個自己的元件，包括上面提到的TaskFarmer,MMSEG.NET以及新聞内容的提取，這些，也算是易訊網自己擁有自己的特色吧。

本文位址http://www.chengxuyuans.com/software_design/12.html