ButterCMS架构：完成数百万次调用的关键任务API

原文：ButterCMS Architecture: A Mission-Critical API Serving Millions Of Requests Per Month

（http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html） 作者：Jake Lumetta 译者：夜风轻扬

还在为网站中断而烦恼么？还在为可能存在的单点故障而终日提心吊胆么？ButterCMS也许给你带来新的选择，请见下文：

ButterCMS 允许开发者在几分钟内将内容管理系统添加到任何网站。我们的业务要求我们的API能够100%处于正常工作状态，但在经历了多次几乎使业务陷入瘫痪的中断之后，我们开始关注于消除单点故障。在这篇文章中，我将讨论如何使用Fastly先进云平台和其他策略，以确保我们客户网站能够正常运行。

在其核心，ButterCMS提供:

• 一个内容编辑者的仪表盘
• 一个用于获取内容的JSON API
• 将ButterCMS集成到本地代码中的SDK

ButterCMS 技术栈

ButterCMS是一个单一的Django应用，其负责营销网站、编辑工具、API和为客户提供支持的后台工具。Django应用在配备一个Postgres数据库的Heroku上运行。

我们还利用以下的第三方服务：

• Filestack 为客户提供图像编辑；
• Fastly 用于外部 API缓存和交付；
• Cloudfront 作为客户资产的CDN；
• 用于DNS的EasyDNS。

停机时间是致命的

客户的web站点在发送request/response过程中，会产生对ButterCMS的API调用来获取页面内容。对ButterCMS的API请求失败，他们的页面可能不会呈现。如果API宕机了，我们客户的网站就会和我们一起停机。

这是我们在早期学到的严重一课。不可靠的服务器托管导致频繁的间歇性中断和性能下降，这会使客户很失望。一次搞砸的DNS迁移导致了几个小时的API宕机，而这又使几十个客户的网站停机几乎半日，并让大量的客户对是否还能依赖我们产生疑问（少数的客户已经离我们而去）。

在这次事故以后，我们明白，确保客户近乎100%的运行率是个现实问题。未来某个重大的中断可能会让我们失去客户并使我们的事业陷入危机。

提交一个全球的，快速的，有弹性的API

完全避免故障是不可能的-只能尽最大努力减少发生的机会。 例如，通过运行自己的物理服务器来“控制自己的命运”，虽然可以保护你不受主机提供商停机的影响，但是要不得不处理安全性和伸缩性问题，这两者可以轻易造成停机，并且难以恢复。

对于我们的团队来说，始终保持API可用并确保它在全球范围内的高性能是至关重要的。但作为一个小公司，并不具有足够的资源来提供高可扩展性能并保持近乎100%可用的API。所以我们使用了可以满足需求的Fastly。

我们将Fastly置于API的前端，作为一个缓存层以确保所有的API请求都通过它们的CDN来提供服务。

当客户更新网站内容时，所编辑的特定内容块API键失效。无缓冲请求发送到服务器，但是由于客户网站的内容更新，相对于它们访问者的数量的并不频繁，仍然有94%的击中率。这意味着即使数据库或服务器经历了间歇性的中断，我们的API仍然可用。我们不希望这样，但理论上，服务器可以完全关闭几个小时，而客户的网站会像Fastly一样长时间保持在线。 Fastly的全球CDN提供了另一个好处。许多客户都有静态的JavaScript站点，其API请求是来自访问者的浏览器而不是他们的服务器。通过Fastly的CDN来提供API响应，这意味着客户网站的访客，无论在何处都可以获得快速的加载次数。

消除单点故障

在ButterCMS的早期，处理两个独立的DNS事件令人身心疲惫。在第一个事件中，由于DNS服务商把我们账户意外“删除”，而导致一个中断事件，该事件经过了近6个小时才完全恢复。第二个事件是一次常规的DNS编辑，引起（不同）DNS提供商发生了故障，这个问题花费了近1天时间才解决。DNS事件特别有破坏性，因为即使发现并修复了问题，还需要等待不同DNS服务器和ISP去清除他们的缓存，直到系统能正常访问（DNS服务器忽视你的TTL设置，只使用他们自己的策略）。

经验告诉我们在整个架构中注意消除任何一个单点故障。

对于DNS服务器，使用来自不同DNS提供商的不同域名服务器。DNS提供商常常允许并鼓励使用4-6台冗余域名服务器（如ns1.example.com, ns2.example.com）。这很好：如果一台宕机了，其他主机依然能够提供服务。但是，如果域名服务器来自于同一家公司，就只能祈祷他们保持100%的可靠。

对于应用服务器，则使用Heroku的监视和自动扩展工具，来确保流量性能不会从峰值上降低（如果 Fastly停机了，需要将所有的请求都直接路由到服务器）。除了通过 Fastly缓存API,也使用Memcached在应用层缓存API。这为防止数据库或者服务器中断提供了一个额外缓存。

通过在谷歌云上运行一个服务器和数据库实例作为快速失效备援，来防止极小可能出现的Heroku或者AWS（Heroku运行其上）中断。

故障难以避免

无论API是多么的可靠，也不得不面临网络不可靠的现实，故障是难以避免的。可能都遇到过连接WI-FI，或者是电话掉线的问题。总的来说，中断、路由问题和其他断续故障在统计学意义上是不常见的，但是，仍然有可能在一定的环境背景下发生。

为了消除这种固有的不可靠环境，需要帮助客户开发在失效情况下的容错应用。SDK可以提供一些特性，诸如在API请求失效时自动重试，或者为用户提供类似Redis的故障迁移缓存。

结论

在无意识中，很多人把单点故障引入到堆栈中。ButterCMS的成功，在于确保客户应用不会停机。要实现这一目标，既要尽可能多消除来自基础设施的单点故障，还要提供SDK帮助客户在应用中实现弹性和容错。