高流量網站的推薦結構

我正在改寫一個大網站，需要非常堅實的架構，這裏是我的幾個問題，並請原諒我混合蘋果和橘子，也可能獼猴桃:)我做了大量的研究和結果完全混淆了。高流量網站的推薦結構

主要問題：你會採取哪種方法建立一個預計將以各種方式增長的大型網站？

單一入口點，在數據庫中的網頁數據，通過GET變量，數據庫條目（？的pageid =什麼）
單一入口點，在單獨的文件頁面的數據，相關拉昇包含的基於GET變量（？pageid =什麼將包括whatever.php）
MVC（好，夥計們，我都是爲了它，但除了檢查所有教程和框架外，不能理解概念，他們是否存儲「視圖「在數據庫中？從例子中可以看出，如果你有1000頁相同類型的頁面，它們可以被1個模型所塑造，但是我仍然需要1000個「視圖」文件？）
PAC - 這聽起來更合乎邏輯，但沒有找到太多資源 - 如果這是一個好的方法，你能推薦任何書籍或鏈接？
DAL/DAO/DDD - 通過在發佈問題之前認真閱讀堆棧溢出，我瞭解了這些條款。不知道是否屬於這個名單
坐下來創建自己的架構（容易做的，如果沒有人開導我在這裏:)沒有提到
東西...

謝謝。

2010-11-30 CodeVirtuoso

我是MVC設計模式的忠實粉絲，這裏是一個教程，我認爲它將闡明你的一些問題。 http://php-html.net/tutorials/model-view-controller-in-php/ – serialk 2010-11-30 17:27:47

如果您打算製作您自己的架構，請給我一個電話= D在對Drupal感到失望之後，我一直在考慮用更多的力量做一些事情。如果有人有Drupal粉絲，請隨時與我聯繫。我會很樂意分享我的不好的經歷。如果您想親自找出問題，請嘗試爲具有可變列的表創建內容類型。 – stevendesu 2010-11-30 17:42:54

您在這裏提到的所有這些與處理高流量無關。你可以選擇你想要的任何東西，但有些要點只是跛腳。另外請記住，在這裏說「MVC」這個詞的人中，有99％的人沒有絲毫的想法。 – 2010-11-30 19:05:36

網站的可擴展性/可用性（低流量高流量）最好由您提到的任何項目解決。特別是第1點和第2點;將頁面定義存儲在數據庫中是一個絕對的禁止。 MVC和其他類似模式更多用於代碼清晰度和維護，而不是可擴展性。

缺失信息的一個重要部分是你期望什麼樣的併發點擊次數/秒？有時，沒有建立高流量網站的人對實際構成「可擴展性惡夢」的命中率感到驚訝。

有關於如何設計可擴展的架構書，所以一個SO職位將無法專題公正，但一些非常頂級的概念，沒有特定的順序，分別是：

可伸縮性最好先處理基於硬件的解決方案。帶有一系列SSD磁盤的強大服務器可以走得很遠。
使靜態變爲靜態。儘可能地從網絡服務器，而不是數據庫服務。例如，網站上的很多頁面都會從數據存儲庫中動態生成數據列表，這些數據庫很少或根本沒有真正改變。
不經常更改的緩存輸出，並調整緩存刷新。
將動態頁面構建爲無狀態或異步。研究CQRS和Event Sourcing以獲得有利/有利於縮放的模式。
調整您的查詢。數據庫通常是一個很大的瓶頸，因爲它是一個共享資源。很多網絡應用程序構建者使用ORM來創建較差的查詢。
調整您的數據庫引擎。備份，複製，清理，日誌記錄，所有這些都需要引擎的一點點資源。調整它可以導致更快的數據庫，從橫向擴展中購買時間。
減少來自客戶端的HTTP請求數量。每個HTTP連接都有開銷。檢查您的頁面，看看是否可以增加每個請求中的有效負載，以減少個別請求的總數。

此時，您已經優化了一臺服務器上的行爲，並且必須「擴展」。現在事情變得非常複雜。各種類型的負載均衡場景（分片，DNS驅動，啞巴平衡等），將讀取的數據與不同數據庫上的寫入數據分離，轉至Google Apps等虛擬化解決方案，將靜態內容分流至大型CDN服務，像Erlang或Scala語言，並行化你的應用程序，等等...

來源

2010-11-30 21:29:50 alphadogg

我是MVC的粉絲，因爲我發現當一切都有地方並且很好和劃分時，擴展團隊更容易。這需要一些習慣，但最簡單的方法來處理它是潛入英寸

這說絕對檢查您的本地圖書館，看看他們是否有O'Reilley縮放書：http://oreilly.com/catalog/9780596102357這是一個好的地方開始。

來源

2010-11-30 17:43:14 Kelly

如果你正在創建一個「大」網站，並沒有完全掌握MVC或Web框架，那麼CMS可能是一個更好的路線，因爲你可以根據需要使用插件來擴展它。有了這條路線，您可以更多地關注內容和頁面結構，而不是平臺。只要你選擇合適的CMS。

來源

2010-11-30 17:49:51 vilepickle

我會建議創建一個模擬應用程序與一些在野外的網絡mvc框架，並選擇一個，你的發展是足夠光滑的。如果您想掌握mvc的概念並準備好將新功能輕鬆添加到您的網絡，建立堅實的基礎代碼是非常重要的。

來源

2010-11-30 18:55:42

單一入口點，在數據庫頁面的數據，通過GET變量與數據庫條目（？的pageid =什麼）

維護潛在的噩夢關聯拉。如果你有2-3人以上的團隊，也可以發展。您需要創建一套嚴格的規則供所有人堅持使用 - 如果使用MVC，花費更多。這同樣適用於2

MVC（好吧，夥計們，我爲這一切，但無法把握的概念，除了檢查所有的教程和框架在那裏，他們是否存儲「視圖」中數據庫？在我看來，從實例，如果你有1000頁相同樣的，他們可以通過1個模型，的形狀，但我仍然需要有1000 「意見」的文件？）

它取決於有多少頁面佈局。大多數MVC框架允許您使用結構化視圖（即主頁面視圖，子視圖）。將視圖看作網頁的HTML模板。你需要多少個模板和子模板，就是你需要多少個視圖。我相信大多數網站最多可以擺脫50個主視圖和100個子視圖 - 但這些網站非常大。看看我運行的一些網站，它總共更像50個視圖。

DAL/DAO/DDD - 我通過堆棧溢出發佈問題之前，勤奮閱讀了解這些條款。不知道它是否屬於此列表

確實如此。如果您需要元視圖或元模型，DDD非常棒。假設所有的模型在結構上都非常相似，但僅在所使用的數據庫表中有所不同，並且您的視圖幾乎將1：1映射到模型。在那種情況下，這是DDD的好時機。一個很好的例子就是一些ERP軟件，你不需要爲所有的數據庫表單獨設計，你可以使用一些統一的方法來完成所有的CRUD操作。在這種情況下，您可能會逃避一個模型和一些視圖 - 所有視圖都是在運行時使用元模型動態生成的，該模型將數據庫列，類型和規則映射到編程語言的邏輯。但是，請注意，構建高質量的DDD引擎需要一些時間和精力，以便您的應用程序看起來不像被破解的MS Access程序。

坐下來創建自己的架構（有可能做的，如果沒有人開導我在這裏:)

如果你正在構建一個面向公衆的網站，你最有可能去與MVC做得很好。一個非常好的起點是查看CodeIgniter視頻教程。它幫助我理解MVC的真正含義，以及如何使用它比我閱讀的任何HOWTO或手冊更好的方式。他們只需要29分鐘乾脆：

http://codeigniter.com/tutorials/

享受。

來源

2010-11-30 21:28:29

高流量網站的推薦結構

回答

相關問題