# 策略：在 S3 或 GitHub 上運行可擴展，可用且廉價的靜態站點 > 原文： [http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html](http://highscalability.com/blog/2011/8/22/strategy-run-a-scalable-available-and-cheap-static-site-on-s.html) 我曾經從事過的最好的項目之一是創建一個幾乎完全靜態的大規模網站發布系統。 一支由非常有才華的創意團隊組成的龐大團隊進行了藝術創作，作者撰寫了內容，設計師生成了模板。 所有資產均由數據庫控制。 然后，在應用了許多不同的過濾器之后，所有內容都被提取到了一個靜態站點，該站點通過 ftp 上傳到了數十個 Web 服務器。 效果很好。 可靠，快速，便宜且簡單。 更新有些麻煩，因為它需要將大量文件推送到許多服務器，這需要時間，但要有一個可靠的系統。 A，這個優雅的系統被替換為一個新的基于動態數據庫的動態系統。 內容是使用動態語言生成的前端從數據庫中提取的。 借助 Amazon 的沃納·沃格斯（Werner Vogels）的最新系列文章，記載了他利用 S3 的網頁服務能力將他的 [All Things Distributed](http://www.allthingsdistributed.com/) 博客轉換為靜態站點的經驗，我很高興 問：我們又回到靜態網站了嗎？ 提出這個問題很高興，因為在許多方面，完全靜態的站點是內容繁重站點的圣杯。 靜態站點是其中文件（html，圖像，聲音，電影等）位于文件系統中的站點，并且 Web 服務器直接將 URL 轉換為文件，然后直接從文件系統讀取文件并將其吐出到 瀏覽器通過 HTTP 請求。 **在此路徑中，**不會出錯。 沒有太多的錯誤是一種美德。 這意味著您無需擔心任何事情。 它將正常工作。 而且它會隨著時間的推移繼續工作，產生一些誤點，并為繁重的站點提供服務，而靜態站點則要困難得多。 這是 Werner 使網站靜態的方式： * S3-存儲文件并為網站提供服務，創建沒有服務器的網站。 S3 不是您唯一的選擇，但對他而言顯然是一個選擇。 我們還將討論更多有關使用 Github 和 Google App Engine 的信息。 * [Disqus](http://disqus.com/) -以獲得評論。 * 必應-[網站搜索](http://www.orangetreeweb.com/articles/installing-bing-site-search.html)。 Google 希望網站搜索功能每年收費 100 美元。 我記得 Google 免費的時候... * [DropBox](http://www.google.com/url?sa=t&source=web&cd=1&ved=0CCcQFjAA&url=http%3A%2F%2Fwww.dropbox.com%2F&ei=CfBRTvHINLDUiALTrdiHAQ&usg=AFQjCNGLRmWLy_c8ebbz09BgsukcLpmnwQ&sig2=m9cVWrbTNKXcHuxN6HRXoQ) -用于將網站文件同步到他所在的任何計算機上，以便可以在本地對其進行編輯。 然后，在文件上運行靜態站點生成器。 然后將文件復制到 S3，這使它們可以使用 S3 在 Internet 上使用。 * [Jekyll](http://jekyllrb.com/) -靜態網站生成器。 用 Ruby 編寫，并使用 [YAML](http://yaml.org/) 進行元數據管理，并使用 [Liquid 模板引擎](http://www.liquidmarkup.org/)處理內容。 * [s3cmd](http://s3tools.org/s3tools) -將文件推送到 S3。 * [http://wwwizer.com](http://wwwizer.com) -免費服務，可滿足 S3 要求您的網站在域名中包含 www 的要求。 該服務會將一個裸域名重定向到 www.domain，因此一切正常。 [Joseph Barillari](http://jbarillari.blogspot.com/2011/02/why-you-cant-run-your-website-from.html) 對此問題進行了很好的討論。 描述他的旅程的文章包括： [AWS 的新功能：從 Amazon S3](http://www.allthingsdistributed.com/2011/02/website_amazon_s3.html) 運行您的網站，[最后免費-在 Amazon S3](http://www.allthingsdistributed.com/2011/02/weblog_in_amazon_s3.html) 中運行的完全自我維持的博客，以及[否 服務器必需-Jekyll & Amazon S3](http://www.allthingsdistributed.com/2011/08/Jekyll-amazon-s3.html) 。 對我來說，使用 DropBox 是一個聰明的地方。 DropBox 可以使文件跟隨您，因此您可以在任何計算機上對其進行編輯。 這也是該方法的缺點。 您需要具有完整工具集的本地計算機，這很麻煩。 具有諷刺意味的是，這就是為什么我更喜歡基于云的方法。 我想從任何支持 Web 的設備（例如 iPhone 或 iPad）上運行博客，我不想弄亂程序。 靜態站點是**可伸縮**站點。 Web 服務器或 OS 可以輕松地將受歡迎的頁面緩存在內存中，并像肯塔基州德比的薄荷糖一樣為它們提供服務。 如果單個服務器不堪重負，則可以輕松地從 CDN 中為靜態站點提供服務，也可以將其復制到負載平衡的配置中。 因此，靜態站點是**快速**。 如果您在下面使用分布式文件系統，那么甚至可以避免磁盤緩慢成為熱點的問題。 您可以使用**最喜歡的文本編輯器**編輯內容。 Nice 和**簡單**。 文件系統傾向于**可靠**。 使用 S3 更可靠，**也便宜。 如果出現故障，您可以使用一個簡單的命令重新發布或還原您的站點。 數據庫往往會增加內存容量，填滿表，查詢速度慢以及其他許多煩人的故障模式。 在靜態站點中可以跳過的所有操作。 超越簡單文件服務的 Web 服務器也可以發揮作用。** 靜態站點的問題在于它們是靜態的。 一旦互聯網完全靜止，當然還有眨眼標記和動畫 gif。 然后，CGI 改變了這一切，此后網絡從未停滯不前。 因此，我們要做的是將**所有**動態位外包給服務，并使內容保持靜態。 評論可以由 Disqus 之類的服務處理。 搜索可以由 Bing 處理。 廣告投放已經是一項服務。 就像按鈕一樣，都是無用的 javascript 代碼。 并且，將**安全性**的擔憂（黑客，SQL 注入等）最小化。 這是混搭文化。 而且大多數情況下都有效。 當我不得不將 HighScalability 移出共享托管時，我認真考慮了這種方法。 缺點： * .htaccess 不能做很多事情。 如果您有很多安全檢查和 URL 映射魔術，那么您無法使用 S3 做到這一點。 * 沒有 PHP 或任何其他語言使用 Web 服務器調用的語言引起的動態性。 您當然可以完全自由地創建服務并將其混入您的站點。 Google App Engine 仍然是此類迷你服務層的絕佳平臺。 對我來說最大的缺點是： * **不是多用戶**。 這種限制影響了網站的各個方面。 我希望多個人能夠向 HighScalability 添加內容。 我想給用戶特殊的特權。 我想分配角色。 我想控制某些用戶可以看到的內容。 SquareSpace 與其他內容管理系統一樣具有此功能。 靜態站點生成器生成的站點不具備這些功能。 * **加入**。 這些工具可讓用戶與您的網站互動，因此希望他們能堅持更長的時間。 諸如歷史上最熱門的帖子，文章的閱讀次數，最新的帖子列表，標簽云等功能。 使用靜態生成器更難做到這些。 * **獲利者**。 這些功能可以幫助您賺錢。 它們通常包括參與者，但可以包括諸如電子郵件列表注冊，相關內容推薦，白皮書匹配，注冊咨詢服務，贊助商文本鏈接等功能。 難以在靜態系統上實現。 一個顯而易見的解決方案是擁有一個通用的 CMS 元數據服務，所有混搭服務都可以使用該服務，但是這種服務可能不會實現。 對于構建靜態網站，S3 并非唯一的游戲。 Github 也可以用來托管靜態網站。 可以通過簡單的 git push 生成和更新博客。 這樣可以將所需的已安裝程序集減少到更易于管理的級別。 現在您甚至不需要 git。 您可以使用文件的網絡界面直接編輯文件。 它的工作方式是 Github 每次將更改推送到存儲庫時都會自動構建您的網站。 此處有更多詳細信息： [GitHub Pages](http://pages.github.com/) ，[發布帶有 GitHub Pages 和 Jekyll](http://blog.envylabs.com/2009/08/publishing-a-blog-with-github-pages-and-jekyll/) 和 [Github 作為 CDN](http://code.lancepollard.com/posts/github-as-a-cdn/) 的博客。 Google App Engine 還是靜態網站的替代方案。 更多詳細信息，請訪問： [DryDrop，使用 GAE 和 Github](http://openalexandria.com/2010/08/drydrop-manage-static-web-site-with-gae-and-github/) 管理靜態網站。 現在有些推動將博客移至**社交網絡**網站，例如 Google+。 優點是您擁有一個內置的機制來吸引更多的讀者，強大的討論功能，增加參與的可能性，無需花費，設備可用性出色且無需維護。 對于不需要獲利的博客，這是一個很好的選擇。 盡管我確實擔心當您想跳到下一個流行的社交網絡時發生的情況，而所有舊內容僅僅是灰塵。 包起來： * 如果您的博客嚴格講內容，那么靜態網站方法是可伸縮，快速，廉價，靈活和可靠的。 我們現在擁有豐富的工具集，可以使靜態網站成為現實。 * 如果您的博客不在網上，那么請把時間花在社交網絡（包括 StackExchage，Quora 等）上而不是博客上。 * 如果要提高用戶參與度或通過其他方式創造性地通過博客獲利，則 CMS 是更好的選擇。 * 如果您想在博客上擁有多個用戶和內容創建者，那么 CMS 是一個更好的選擇。 因此，有關創建靜態網站的更多鏈接： * [由 Jean-Michel Lacroix 在 CloudFront](http://jmlacroix.com/archives/cloudfront-hosting.html) 上托管靜態網站 * [在 Jean-Michel Lacroix 上在 CloudFront](http://jmlacroix.com/archives/cloudfront-publishing.html) 上發布靜態網站 * [ponyHost-已死的簡單 s3 網站](http://ponyho.st/) * [Hyde](http://ringce.com/hyde) -Hyde 是由 Python 支持的靜態網站生成器& Django * [Nanoc](http://nanoc.stoneship.org/) -是一種 Ruby 網絡發布系統，可在您的本地計算機上運行，??并將以 Markdown，Textile，Haml 等格式編寫的文檔編譯到由簡單 HTML 文件組成的靜態網站中，隨時可以上傳到任何網站 網絡服務器。 * [博客工具](http://joshua.schachter.org/2009/12/blogging-tools.html)，作者：joshua schachter * [仙人掌](https://github.com/koenbok/Cactus)-靜態網站生成器。 * [jekyll vs. hyde-兩個靜態網站生成器的比較](http://www.reddit.com/r/programming/comments/hcxvc/jekyll_vs_hyde_a_comparison_of_two_static_site/) * [jekyll-s3]( https://github.com/versapay/jekyll-s3) -將您的 Jekyll 博客推送到 Amazon S3！ 嗨，托德，很高興寫出來。 我絕對同意你提到的缺點。 對我來說，這確實是一種鍛煉，它使我可以做無服務器工作。 并了解我們可以在 AWS 方面做得更好。 具有靜態插件生成器 Jekyll 或 Cactus 的功能完備的多用戶 CMS 和 Wordpress 等豐富的插件生態系統僅領先幾年。 但是自從我上一篇文章發表以來，人們一直在向我發送其他靜態生成器的參考，并且工具的發展也多種多樣。 毫無疑問，Jekyll 確實是“像黑客一樣博客”，因此具有您所期望的所有粗糙邊緣。 例如，一個擁有很多帖子（例如您的帖子）的網站將需要進行認真的組織以使其在 Jekyll 中易于管理。 我確實喜歡這種設置的分散性。 我可以從任何地方寫信并更新網站。 鑒于我是唯一的作家，所以自然缺乏并發:-)但是能夠在您可能沒有本地安裝 jekyll 的地方寫文章也是我當然也想做的事情。 我喜歡 Ted Kulp 在[《自動化 Jekyll 構建](http://tedkulp.com/2011/05/22/automating-jekyll-builds/)》中所做的工作，他基本上在服務器上有一個進程在監視保管箱文件夾。 當他在其中發布帖子時，網站將重新生成并推送到 S3。 它仍然需要在某個地方的服務器，但是我很確定我可以將其外包給 Heroku，而不必自己運行某些東西。 我只是很開心地看到我可以把它推多遠... 這就是我對您的文章 Werner 所喜歡的，顯然，您可以從整體上解決問題。 一起騎很有趣！ 我做了一點測試，瀏覽了瀏覽器歷史記錄的最后一周，并嘗試進行反向工程，以通過靜態生成器（比 Werner 的更高級的生成器，可以用我的想象力）來提供多少內容，一旦獲得 過去搜索引擎的搜索結果，并排除了我的個人網站（電子郵件，Twitter，Facebook 等），基本上所有頁面都可以設置（我編造了這個詞，需要簡短說明）。 在規模化或系統簡化的對話中，幾乎從未提及過標準化。 一旦對網站進行了注冊，則在提供服務的方式上就根本不同：將 PHP-mysql 堆棧提供的頁面與 S3 存儲桶或 Akamai 邊緣服務器提供的頁面進行比較，大約等于 1。 系統資源方面的差異為 10K FOLD（如今，可以通過單核完成 c10K）。 身份認證可以應用于很多網頁（不僅是博客），但是 AFAIK 并沒有很好的食譜（任何人都知道嗎？），并且它似乎并不是大多數開發人員常用的工具（或者也許是 只是不夠性感而無法獲得大量媒體報道）。 就我個人而言，我非常樂于將任何和所有功能（出于某種原因）推到盡可能遠地遠離后端（即數據庫）和盡可能遠地進入前端（即瀏覽器）的位置，這是擴展和尊重數據的關鍵 本地化，因此感謝你們倆提醒人們使用此技術：多動腦筋意味著多用戶 CMS 靜態生成器就近了，所以我可以更快地得到我的網頁：）。 Bing 網站搜索小部件已于 2011 年 2 月撤消。 http://www.bing.com/community/site_blogs/b/webmaster/archive/2011/04/19/bing-com-siteowner-shut-down-options-for-search-results.aspx 關于允許用戶向 HighScalability 添加/編輯內容的方式：如果將靜態站點文件保存在{git，hg，bzr}存儲庫中，則可以允許用戶克隆本地存儲庫，進行更改然后推送 它們返回給您，您可以在此處查看并推送到 S3。 這樣做甚至可能會為您的 Dropbox 節省一些空間，因為您可以在 Dropbox 上保留一個裸{git，hg，bzr}倉庫，然后將其推送并拉到本地計算機上。 我對很多代碼都這樣做，而且即使我沒有互聯網連接（因此無法推送到 github），我也很喜歡，我可以做一個`git push dropbox master`并知道下一次我 連接后，我的存儲庫將備份到我的 Dropbox。 關于@Jonathon Prior 的聲明，我前不久在 HN 上看到了這一點：http://jeffkreeftmeijer.com/2011/introducing-tapir-simple-search-for-static-sites/ 保羅，那是硬核，但很有趣。 我的第一個念頭是那種方法會使人嚇跑，但也許不會。 我沒有得到我想要的貢獻，也許 git 方法會更有吸引力？ 喬納森，謝謝你。 當我可以在 Bing 的網站上找到搜索時，我以為是我。 ir 看起來很有趣。 在我看來，最好的方法仍然是在需要時靜態使用 AJAX。 IOW，以靜態方式提供 html / css / javascript 文件，然后讓 javascript 為您創建“動態”頁面。 由于客戶端計算機正在執行 GUI 處理工作，而不是服務器，因此這有助于擴展。 當然，仍然需要“動態” REST 端點等。這種分離對于輕松開發基于同一數據源的多個用戶界面也非常有用。 我猜這完全符合您提到的“混搭”文化。 :) 這是一篇很棒的文章，強調了主要提供靜態內容的優勢。 現實情況是，大多數站點只能以最少的動態內容獲得成功，而且很多站點實際上還是靜態的。 使用 Bricolage 在 www.groupcomplete.com 上發布我們的網站已經取得了巨大的成功。 Bricolage 并不是新手或花哨的東西，但是在將內容與模板分離，將最終結果內容推送到我們的服務器方面做得非常出色，確實消除了擔心動態 CMS 是否崩潰或遭受最新安全漏洞的麻煩。 。 “ ... Web 服務器或 OS 可以輕松地將流行的頁面緩存在內存中，并像肯塔基州德比的薄荷糖一樣為它們提供服務...” 那接近文學。 做得好。 有趣的是，大型企業維護的大多數公司網站都依賴這種方法，而大多數企業級 CMS 實際上是“離線”的。 在 IT 運營和安全性方面，這種方法有很多好處。 但是，主要原因是這些 CMS 具有早期 Web 時代的傳統，而動態網站是異國情調的。 這樣事情就轉了一圈了。 您是否可以在某個地方使用私人 CMS 來編輯和維護頁面文本（必須通過 Jekyll 或所需的任何生成器來維護授予的 CSS）-這樣，如果您在 CMS 中編輯了頁面，則可以通過以下方式輕松地更新靜態網站： 只是從數據庫中實時再生？ 這可能允許 wordpress 安裝在您的桌面安裝上變為私有-然后將 static 推送到 S3。 兩全其美-在 CMS 中易于使用的編輯-快速的網站服務以及消除了互聯網使用的數據庫調用？ 準系統 CMS 是生成 CMS 的靜態文件。 內置緩存足以滿足大多數用途，但是如果您將 nginx 之類的服務器放在前面，并使用一些特殊規則查找緩存文件，則只需提供直接生成的緩存內容，從而完全繞過 PHP。 這樣，除了硬件可以提供靜態內容的速度有多快之外，您顯然對系統性能沒有任何限制。 它尚未完全可以用作博客，但將 Barebones CMS 變成一個似乎并不困難。 高可擴展性！ 同類中最好的。 進入靜態站點-博客引擎 MovableType 支持靜態發布-http://www.movabletype.org/documentation/administrator/publishing/static-and-dynamic-publishing.html 用于高流量博客。 如果我們通過 javascript 處理動態內容，則靜態發布會非常有用。 謝謝 甚至以慢而著稱的 CMS 都會吃掉幾乎所有可能的早餐負載，除非您在體系結構上不滿意，例如，將 Apache KeepAlive 保留下來。 我想看一個像 jekyll 這樣的博客生成器，但是像 frontpage 這樣的 gui（顯然，生成更好的代碼）