【分享】microsoft.com 幕後。探索世界上最忙碌 Web 網站之一的內幕。


Recommended Posts

microsoft.com 幕後。探索世界上最忙碌 Web 網站之一的內幕。

--------------------------------------------------------------------------------

我們要告訴您我們是如何盡可能發揮軟體的效能,以及我們如何組織硬體, 以讓 "www.microsoft.com"發揮最大效用。以下的簡單統計數字說明了站台的龐大與複雜程度:

流量

每天有 6 千萬個頁面被檢視

每天有 3 億次到訪次數

每天有 410 萬名使用者

每月有 2,500 萬名使用者

每天有超過 6 TB 的成功下載

成長

在 98 年 7 月與 99 年 7 月之間,頁面檢視次數增加了 205%

在這 12 個月中,使用者增加了 142%

內容

32 GB 的內容

417,000 個 HTML 或 ASP 檔案

434,000 個 GIF 或 JPG 影像檔

約 50 GB 的檔案可供下載

24 小時隨時更新內容

硬體

八個內部 Ethernet,每個均可提供 100 千位元組容量

2 條 OC12,為 Internet 提供 1.2 GB 容量

在 Compaq Proliant 5500 及 Dell PowerEdge 6300 上執行, 使用四個 Pentium III 處理器,而每部機器上各有 512 MB 的 RAM

軟體

Microsoft Windows 2000 Advanced Server

Microsoft Internet Information Services (IIS) 5.0

Microsoft Site Server 3.0

Microsoft SQL Server 7

其他 Microsoft 工具及應用程式

功能強大的解決方案

www.microsoft.com 在 1994 年剛開始時只是一個小空間,每天負責處理一百萬的到訪次數。

現在那似乎十分可笑。因為位於華盛頓州 Redmond 的資料中心, 每天接收超過 3 億次的到訪次數。

這個站台如何處理爆炸性的成長,同時又能將硬體需求減到最小?它如何管理全球最大的資料庫之一? 它如何面對分散式發佈環境的挑戰? 它如何成為幾乎是百分之百可用的站台?

根據站台建構人員表示,答案就在於其軟體的威力。 整個工作是在 Microsoft Windows 2000 Advanced Server、IIS 5.0 及 SQL Server 7 上執行。

系統作業管理員 Todd Weeks 說:「我們的站台展現了 Microsoft 的技術。我們時時刻刻都在證明,我們可以百分之百依賴 Microsoft 的技術,來 運作全球最大的網站之一。」

挑戰

www.microsoft.com 不僅是一個具備成千上萬個網頁的龐大站台。 它每天接收的到訪次數不只百萬。而它的成長從來沒有減緩過。 網站建構人員表示,這不過是它面臨的幾個簡單挑戰。

最有趣的挑戰之一,就是 www.microsoft.com 是在分散式發佈環境中運作的。 全球有超過 300 位撰稿及開發人員,分別從 51 個地區提供資訊給這個站台。 這些內容提供者可以全天候在 www.microsoft.com 中更新其站台。 事實上,有 5% 到 6% 的站台是每天更新的。

想像位於 Redmond 的 110 台內容伺服器,它們各要處理將近 420,000 頁的資訊, 才能組成 www.microsoft.com,這樣複雜的發佈環境實在令人畏卻。 最終的結果就是 www.microsoft.com 上的資訊會儘可能保持最新狀態。

由八、九位成員組成的團隊負責按三班制輪班,以確保 www.microsoft.com 總是能 毫不間斷地運作。 Weeks 表示:「我們的目標是讓使用者在 99.8% 的時間中,都能使用這個 站台。」

所以我們是如何達到 99.8% 可用性的高目標呢?(需要 0.2% 的關機時間以進行定期維護。)

從硬體開始

www.microsoft.com 背後的實體架構倒是沒有那麼驚人。 35 台伺服器主控一般的 Web 內容;45 台伺服器負責 SQL;12 台負責站台搜尋作業; 16 台為下載要求提供服務,另外有 30 台位於分散的資料中心;還有 3 台主宰 FTP 內容。 還有其他國外伺服器,用來處理國際的載入量。

伺服器的執行通常很順暢。它們最多可以處理 6,000 個同時使用者,平均每個作業系統可以輕鬆地 處理 1,000 到 1,500 名使用者。處理器的使用率大約介於 40% 到 50%。

硬體組織的方法,可提供一般使用者所需的速度及可靠性。 備用的集線器、路由器及切換器,可確保站台在機器發生問題時仍可繼續運作。Weeks 表示:「有許多台伺服器分布在多個 LAN 上,讓我們在硬體方面 完全不會產生問題。」

此外,許多 SQL 伺服器都有熱機備用。Weeks 說:「我們有很多隨時可派上用場的硬體,以防萬一。」即使這些 SQL 伺服器被當作備用品, 它們仍然會被充份利用。每天都會將運作中的 SQL 伺服器複製一次到備用伺服器上, 然後備用伺服器就會視需要來組織及分送資訊。這表示使用中的伺服器整天都可以提供服務。

Weeks 說:「這樣就能大幅減少負荷。分送處理需要伺服器提供極多處理器資源, 並且會減緩每秒鐘處理的要求數。」

為了提供速度和可存取性,使用了八個 Ethernet,替資料中心的伺服器提供每秒 600 千位元組的容量。 使用兩條 OC12 線路,將 www.microsoft.com 連接到 Internet 中樞,每條均可 提供每秒 1,200 千位元組 (或 150 MB) 的容量。

換句話說,這樣的容量可以將儲存在 3 GB 硬碟上的所有資訊 (約為標準 PC 的 大小),在大概 20 秒內完全傳送到 Internet 上。

那麼,Microsoft 為何不購買更多伺服器來處理站台爆炸性的成長呢?

答案很簡單。站台效能的主要改進,並不只是利用硬體來解決問題。 本篇報導中的幕後英雄,就是軟體。

現在談談軟體

www.microsoft.com 是一個龐大的站台。它必須在可靠的硬體上執行可靠的軟體, 才能執行無誤。但它也需要規畫、巧思及開創性的策略。

我們將告訴您如何使我們的軟體發揮最大效用。

一片片的拼圖

所有伺服器都是在 Windows 2000 Advanced Server 上執行。IIS 5.0 則提供 Web 內容。 此外,搜尋伺服器 (每分鐘接收 150 個要求) 也是執行 Microsoft Site Server 3.0。 在尖峰時間,每次可處理超過 500 個請求,且平均支援 400 個連線的資料庫 伺服器,也是執行 SQL Server。

「軟體像一片片的拼圖一樣」,站台的資料庫系統管理員 Robb Mitchell 如是說。 「它們完美地結合,創造出幾乎無懈可擊的環境。」

軟體能夠充份發揮效用的一個原因,就是所有應用程式建立的目的,都是為了彼此互動。 Mitchell 說:「使用 Windows NT、Windows 2000、IIS 及 SQL 來製作網頁,是非常容易的事。 幾乎可說是渾然天成。」

例如,如果您使用 Windows NT 或 Windows 2000 及資料庫, SQL 就能利用其網頁工具及精靈,協助您將它們全部整合在一起。 設定不同的應用程式使其搭配運作,也變得簡單無比。

假設您使用 Microsoft FrontPage 這套網頁產生工具,且想插入資料儲存格。FrontPage 提供許多精靈來協助您設定網頁,讓它 和 SQL 以及您現有的資料庫產生互動。 答對了 -- 您已經擁有可供網站使用的資料庫。

另一個範例是「開放式資料庫連線 (ODBC)」,也就是在應用程式之間傳輸資料的 虛擬管道。 ODBC 是架構在 Windows 上,而且會自動設定以使用其他應用程式。 Mitchell 表示:「你不需要安裝它,也不必煩惱它,甚至完全不必設定 ODBC。」

Mitchell 解釋道:「所有的元件都整合得很好 -- 只要說『進行 SQL 呼叫』,平台 就會讓它發生。」

Windows、SQL 及 IIS 的樂趣

在許多方面,Mitchell 都算是 www.microsoft.com 的先鋒。 他的小組負責全世界 170 個資料庫的線上運作,目前上線的資料空間就有 8 TB。每台 SQL 伺服器每秒處理大約 200 筆交易。

Mitchell 必須要依賴軟體;不能有出錯的情形。他說:「我們隨時都有大約 100 台 Web 伺服器在使用 SQL 伺服器。它們必須能全天候運作。」

為了處理這樣的負荷,IIS 伺服器 (實際的 Web 伺服器) 使用一種稱為「連線集區」的 技術,來維持穩定性及效率。 IIS 伺服器會到每一部 SQL 伺服器上取得連線並維持連線,這種解決方案可減少 伺服器的資源使用量。Mitchell 表示,所謂的「連線後中斷」的連線,也就是在交易結束時斷線的 連線,會造成伺服器較大的負荷。

Weeks 表示 IIS 的優點之一就是它很容易安裝。其基本設定就能執行小型作業或全球最大的 Web 網站。他說:「它不需要調校。 它能完全滿足各種客戶的各種需求。」

IIS 也能讓系統管理員在「程序外」執行應用程式。這表示,如果您設計了一個有時可能導致違規錯誤及失敗的物件,IIS 就可以隔離 應用程式以讓它繼續執行,而不影響站台的其餘部份。

www.microsoft.com 擁有 40,000 多個 ASP 頁面,且包含許多 SQL 內容 - 後者事實上是 2 億個使用中的資料列。「這表示站台可以更大、更好,更有活力。 但技術元件有時難以維護,因為它們開發不當。」研究與開發部門經理 Todd Wanke 這麼認為。

www.microsoft.com 發揮順暢效能的最大障礙,也是站台管理員在研究事件記錄與 效能監督程式時最注重的因素,就是個別網頁的內容。

Weeks 說:「在高到訪率的站台上,如果有撰寫不當的網頁,就可能會產生負面影響。它可能會阻礙站台的可用性。這就是為什麼在推出之前,我們一定要先測試內容。」

例如,如果有一個獨立 ASP 網頁每秒鐘收到 20 次要求,而它每秒只能傳遞 10 次, 那麼即使有最快的硬體,但額外的要求很快就會讓系統無法負荷。

Weeks 表示:「效能不佳的內容會影響站台的效率,即使將伺服器數量加倍也幫不上忙。所有內容都必須迅速執行,不能有任何潛在的風險。」

所以,站台管理員如何處理問題與進行維護呢?

Mitchell 認為,SQL 最棒的一點就是管理員可以在伺服器上線時,執行所有必要的維護。管理員不必停止伺服器就能管理資料傾印及進行一致性檢查;也就是檢視資料庫 確定沒有損毀,而如果有的話就在線上進行修理。

MSData 是一個龐大的 70 GB 資料庫,它能處理公司所有的線上註冊,正是最好的範例。 任何來到 www.microsoft.com 的人,如果接受 cookies 就會 使用 MSData,然後才能前往別處。 Mitchell 表示:「SQL Server 讓我們能在資料庫運作時更新資料庫架構。」

您也可以自訂 SQL 以符合需求。應用程式包含預先定義的資料類型 (如文字、日期及時間),但是您也可以 建立自己的項目,例如某些影像檔。利用 SQL,您就能自訂預設值及規則。假設您想建立具有地址欄位的表單。如果使用者在「郵遞區號」欄位中鍵入 98052,您就能自訂資料庫,讓它自動在城市及州欄位中 填入華盛頓州 Redmond。

但是,到底為什麼要使用 SQL 呢?為什麼不繼續使用確定可用的 HTML 及 ASP?

Mitchell 說:「某些事情只有在資料庫引擎中才有意義。你可以在 HTML 或 ASP 中輸入許多這類資料,但是它太龐大,需要太多的時間與空間。SQL 的回覆時間更短 - 我是指毫秒。」

Mitchell 是這麼形容的:「使用 Windows 2000 及 SQL 來建置網站,是必然的趨勢。 我們已經證明它非常穩定,而且足以應付大量的工作。我們每天可以處理 1 億 9 千萬到訪次數 - 而且 還在成長中 - 這真是太了不起了。」

開創性的策略

現在,您有了軟體,也有了硬體。該如何讓它們發揮最大的效用?

我們發現這個平台具備極佳的擴充性及彈性,可以輕易修改以符合所需。以下是我們在 www.microsoft.com 想出來的幾個有 創意的策略。

單一 IP 解決方案

伺服器錯誤對使用者來說是很不好的經驗,足以讓網站管理員大皺眉頭。 www.microsoft.com 站台建構人員盡量讓使用者在存取 www.microsoft.com 時不會受到阻礙。

其中一個巧思就是單一 IP 解決方案。通常, Internet 上的每台伺服器都有其獨一無二的 IP 位址。以往使用者想造訪 www.microsoft.com 時,他們的瀏覽器可能會指定其中一部 www.microsoft.com 伺服器的唯一 IP 位址。萬一那台伺服器正好當機,那就太糟了。即使所有其他的 www.microsoft.com 伺服器都在執行中,這位特定使用者仍然會收到可怕的伺服器錯誤。

「單一 IP」解決方案可以改變這一切。每個使用中的 IP 位址都可以代表整個站台。 要求進入時會傳送到運作中的伺服器,而略過任何可能已經當機的伺服器。 Wanke 表示,這個程序包括一個稱為 HTTPmon 的 Microsoft 應用程式,它會衡量不同伺服器 的可用性及狀態。

結果:為外部客戶提供百分之百的可用性。

叢集內容

www.microsoft.com 也利用一種叫做「叢集」的策略,來維持站台的可用性。藉由將大部份站台內容分散到不同的機器,或是以邏輯方式賦予不同的 伺服器名稱,網站建構人員就能確保使用者能夠存取想要的網站。

這樣的話,如果伺服器失效,其餘叢集也能承受這些載量。 不會因此拖累站台其餘的部份。

Weeks 說:「我們的客戶在 Internet 上不會看到任何伺服器失敗。」

IIS 的好處之一,就是能夠在個別伺服器上調整執行次數 (伺服器發生「逾時」以及將 使用者移到另一個伺服器之前的時間)。叢集採用了這項優點,將具有短暫逾時值的靜態 HTML 頁面及使用 大量應用程式頁面的站台分開,後者需要更長的時間來執行,而且有較長的逾時值。

站台的總經理 Tim Sinclair 表示:「靜態環境可以擺在第一順位。 www.microsoft.com 的位址就像是網站的撥號音,任何進入這個站台的人 都一定會先到這個網頁。」

大量使用應用程式的重要服務 (如註冊、支援、事件及優惠),則可以叢集在其本身的 個別伺服器上。Sinclair 表示,由於那些站台都提供了客戶信賴的服務 (而且應用程式會大量使用資料庫),所以 我們選擇將這些應用程式叢集到不同的伺服器群組,以便更精確地控制效能。

站台建構人員也會按照產品系列來叢集某些 www.microsoft.com 內容。Windows、Office 及 BackOffice都位於 www.microsoft.com 的子領域上。

Sinclair 表示:「隨著 Microsoft 產品不斷推出,就支援性和功能改進而言,我們的網站在許多方面都成為產品的延伸。」他也提到未來產品的特點,使用者將來只要按一下按鍵,就能取得線上產品 支援及下載產品加強功能。

未來呢?站台建構人員打算設計一組伺服器,來處理不同的客戶群。例如,MSDN 與 SiteBuilder (鎖定對象皆為開發人員) 將會分成不同的叢集。

測試過程

www.microsoft.com 提供了很多機會來修改 Microsoft Internet 產品的效能。我們認為,如果我們的產品能禁得起全球第三大網站龐大的流量和技術需求, 就應該能滿足任何地方的需要。而改良產品最好的方法,就是在全世界最忙碌的資訊高速公路上測試 它們。

新產品會在 microsoft.com 實驗室環境中經歷一段標準測試期的完整測試, 然後移到我們的 Intranet 上,最後再移到 www.microsoft.com 次要伺服器上進行測試。

由於不太可能模擬站台的龐大流量,站台上的某些次要內容其實會在線上面臨最嚴苛的 負載測試。

測試及監督站台

www.microsoft.com 管理員會小心地測試站台,看看它是否能有效傳遞資訊。測試工作可分為三種功能性任務:ASP 測試及程式碼複閱、現行基礎架構 測試,以及新技術的測試及施行。

ASP 測試及程式碼複閱可讓我們在發行上線之前,查看在站台上執行的所有可執行檔 程式碼。 www.microsoft.com 程式開發小組也利用 Visual Basic, 建置一個稱為 PubWiz 的內部工具,來檢查連結參照及程式設計樣式。 在分散式發佈環境中,有超過 350 個人員會將內容發佈到 www.microsoft.com, 這時 PubWiz 就是保證品質的重要工具。

現行基礎架構測試主要著重於改善 www.microsoft.com 站台目前的效能。測試人員在具備多部用戶端的測試實驗室中,利用網站複本以模擬伺服器的負載。模擬作業所用的工具稱為 WebCat,而您可以在 Windows NT 4.0 Resource Kit 中取得這套工具。

我們以兩種方法來監督 www.microsoft.com 的效能。

我們在全球各地監督與 Internet 的連接性,以幫助我們找出 Internet 的瓶頸。我們同時也監督資料中心內個別叢集中的每一台伺服器。我們很想知道,將伺服器連線到 Internet 的網路是否負擔過重。

www.microsoft.com 展望

在這條綿延不絕的道路上,我們究竟走了多遠?Internet 會如何挑戰我們的硬體、軟體及獨創性?

這條虛擬道路從來沒有時速限制。至少,在站台全力衝刺時還能讓它保持完整,對我們來說是很有趣的 成長經驗。

但我們得到多方面的協助。

我們很幸運能有許多及時推出的產品,讓我們能按部就班地逐漸成長。

而且光是聽取各家的意見,就讓我們獲益匪淺。我們重視客戶的意見,並且儘可能反應到新的方向。

我們希望這篇文章能幫助您更有效管理網站,無論它是大型企業網站或個人網站。藉由呈現我們的站台架構,我們希望能證明 Microsoft Internet 產品的 適用性,以及它們承受壓力的程度。

鏈接文章
分享到其他網站
  • 1 month later...

在 Compaq Proliant 5500 及 Dell PowerEdge 6300 上執行, 使用四個 Pentium III 處理器,而每部機器上各有 512 MB 的 RAM

這樣的服務器配置是否太軟暸點?∼∼.......使用XEON或安騰處理器和1G以上內存的服務器不是更好么?∼∼

另外操作繫統我想是否已經昇級為windows server2003 data center?IIS為6.0∼

而且SQLserver的2005版也即將麵世暸哦∼∼∼∼

鏈接文章
分享到其他網站
  • 1 month later...
最初由 vv730516 發表

如果硬體設備都相同的情況下,

Linux+MySql不知道有沒有這樣的功力?

效能一定好很多@@

深藍目前就深受WIN伺服器所苦orz

效能低落

但ASP必須 (幾乎)在IIS上跑

而某種程度來說 PHP是完全無法與ASP競爭

鏈接文章
分享到其他網站

請登入後來留意見

在登入之後,您才能留意見



立即登入