# 策略：在 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（显然，生成更好的代码）