# ButterCMS 體系結構：關鍵任務 API 每月可處理數百萬個請求 > 原文： [http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html](http://highscalability.com/blog/2017/10/16/buttercms-architecture-a-mission-critical-api-serving-millio.html)  *這是 [Jake Lumetta](https://twitter.com/jakelumetta) 的來賓帖子， [ButterCMS [](https://buttercms.com/) 。* [ButterCMS](https://buttercms.com/) 使開發人員可以在幾分鐘內將內容管理系統添加到任何網站。 我們的業務要求我們為 API 提供近 100％的正常運行時間，但是在多次中斷幾乎使我們的業務癱瘓之后，我們開始著迷于消除單點故障。 在這篇文章中，我將討論如何快速使用 [](https://www.fastly.com/)的邊緣云平臺和其他策略，以確保我們保持客戶網站的正常運行 。 ButterCMS 的核心功能是： * 內容編輯器的儀表板 * 一個 [JSON API](https://buttercms.com/docs/api/) ，用于獲取內容 * [SDK，用于將 ButterCMS](https://github.com/buttercms) 集成到本機代碼中 ## ButterCMS 技術堆棧 ButterCMS 是一個單一的 Django 應用程序，負責營銷網站，編輯工具，API 和后臺工具，以提供客戶支持。 Django 應用程序與 Postgres 數據庫一起在 Heroku 上運行。 我們還利用以下第三方服務： * [文件堆棧](https://www.filestack.com/) 用于為其客戶提供圖像編輯功能 * [快速](https://www.fastly.com/) 用于外部 API 緩存和交付 * [Cloudfront](https://aws.amazon.com/cloudfront/) 作為客戶資產的 CDN * 用于 DNS 的 [EasyDNS](https://www.easydns.com/) ## 停機時間是致命的 我們的客戶通常會建立在請求/響應生命周期內向 ButterCMS 發出 API 請求以獲取頁面內容的網站。 這意味著，如果他們對 ButterCMS 的 API 請求失敗，則他們的頁面可能無法呈現。 如果我們的 API 出現故障，那么客戶的網站也會與我們發生故障。 這是我們在早期學習的艱辛課程。 不可靠的服務器托管導致頻繁的間歇性停機和性能下降，使客戶感到沮喪。 糟糕的 DNS 遷移導致 API 停機數小時，從而使數十個客戶的網站癱瘓了近半天，并使大量客戶質疑他們是否可以繼續依賴我們（其中有少數人離開了我們）。 在此事件之后，我們意識到確保接近 100％的正常運行時間是一個存在的問題。 未來發生的重大故障可能導致我們失去來之不易的客戶，并使我們的業務陷入危機。 ## 提供全局，快速，彈性的 API 無法完全避免失敗-您只能盡力減少機會。 例如，通過運行自己的物理服務器來“控制自己的命運”可以保護您的主機提供商免受崩潰的困擾，但是卻使您處于必須處理安全性和可伸縮性的位置，這兩者都可以輕松使您崩潰并 很難恢復。 對于我們的團隊而言，始終保持 API 的正常運行并確保其在全球范圍內提供高性能至關重要。 但是作為一家較小的公司，我們知道我們沒有足夠的資源來提供具有近 100％正常運行時間的全球性，高度可擴展的性能。 因此，我們轉向了這樣做的人： [快速](https://www.fastly.com/) 。 迅速將自己描述為“為全球最受歡迎的企業提供快速，安全和可擴展的數字體驗的邊緣云平臺”。 他們與包括《紐約時報》，BuzzFeed，Pinterest 和 New Relic 等大型客戶合作。 我們將 Fast 放在我們的 API 前面作為緩存層，以便所有 API 請求都通過其 CDN 進行處理。  當我們的一位客戶在 ButterCMS 中更新其網站內容時，我們將使已編輯內容的特定位的 API 密鑰無效。 非緩存的請求命中了我們的服務器，但命中率達到了 94％，因為客戶網站上的內容相對于獲得的訪問者數量很少變化。 這意味著，即使我們的數據庫或服務器遇到間歇性的中斷，我們的 API 仍然可以運行。 我們不希望這樣，但是從理論上講，只要 Fastly 保持正常運行，服務器可能會完全癱瘓幾個小時，而且客戶的網站也會保持正常運行。 Fastly 的全球 CDN 為我們帶來了另一個好處。 我們的許多客戶都有靜態 JavaScript 網站，這些 API 網站的訪問者訪問者是瀏覽器而不是服務器。 通過 Fastly 的 CDN 提供 API 響應，意味著我們的客戶的網站訪問者無論身在何處，都能獲得快速的加載時間。 ## 消除單點故障 在 ButterCMS 成立之初，我們處理了兩次單獨的 DNS 事件，這使我們感到恐懼。 在第一起事件中，我們的 DNS 提供商當時不小心從其系統中“取消”了我們的帳戶，導致斷電花費了將近 6 個小時才能使我們完全恢復。 我們的第二次事件發生在常規 DNS 編輯導致我們的[不同的] DNS 提供程序發生故障時，并且花費了將近半天的時間來解決。 DNS 事件尤其具有破壞性，因為即使在確定并解決問題后，您也必須等待各種 DNS 服務器和 ISP 清除緩存，然后客戶才能看到解決方案（DNS 服務器也傾向于忽略您的 TTL 設置并強加 他們自己的政策）。 我們的經驗使我們非常專注于消除整個體系結構中的任何單點故障。 對于 DNS，我們切換為使用來自不同 DNS 提供商的多個名稱服務器。 DNS 提供程序通常允許并鼓勵您使用 4-6 個冗余名稱服務器（例如 ns1.example.com，ns2.example.com）。 很好：如果一個請求失敗，其他請求仍然可以解決。 但是，由于您所有的名稱服務器都來自同一家公司，因此您非常相信他們將擁有 100％的正常運行時間。 對于我們的應用服務器，我們使用 Heroku 的監控和 [自動縮放](https://blog.heroku.com/heroku-autoscaling) 工具，以確保我們的性能不會因流量高峰（或 如果快速崩潰，我們突然需要將所有請求直接路由到我們的服務器）。 除了使用 Fastly 緩存 API 外，我們還使用 Memcached 在應用程序級別緩存 API。 這為間歇性數據庫或服務器故障提供了額外的緩沖層。 為防止在 Heroku 或 AWS（Heroku 運行于其上）之間發生極少數情況下的總停機，我們在 Google Cloud 上維護了單獨的服務器和數據庫實例，可以將其快速故障轉移。 ## 不可避免的是失敗 不管我們的 API 有多可靠，我們都必須接受 [不可靠的網絡](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) ，并且網絡肯定會發生故障。 我們所有人在連接 Wi-Fi 時都遇到了麻煩，或者突然打了個電話。 從統計上講，中斷，路由問題和其他間歇性故障在總體上可能是異常的，但始終會始終以某個環境本底速率發生。 為克服這種本質上不可靠的環境，我們幫助客戶構建在出現故障時將變得可靠的應用程序。 我們的 SDK 提供的功能，例如 [在 API 請求失敗時自動重試](https://github.com/ButterCMS/buttercms-csharp/pull/2) 或 [支持，可輕松使用故障轉移緩存](https://github.com/ButterCMS/buttercms-ruby#fallback-data-store) ，例如客戶端上的 Redis。 ## 結論 沒有意識到這一點，我們中的許多人正在將單點故障構建到我們的堆棧中。 在 ButterCMS，我們的成功取決于確保客戶的應用程序不會因為我們而出現故障。 為此，我們從后端基礎架構中消除了盡可能多的單點故障，并提供了 SDK，可讓我們的客戶輕松實現其應用程序中的彈性和容錯能力。 ### 關于 ButterCMS 當您聽到“ CMS”或“博客”消息時，您可能會想到 WordPress。 ButterCMS 是一種較新的替代方法，它允許開發團隊使用 ButterCMS API 將 CMS 和博客功能添加到他們自己的本機代碼庫中。 ButterCMS 由 [Jake Lumetta](https://twitter.com/jakelumetta) 和 [Abi Noda](https://twitter.com/abi) 發起，因為他們倆都遇到了尋找功能齊全，靈活且未將您綁定到特定 WordPress 的替代品的挑戰 像 PHP 這樣的編程語言.. 如今，ButterCMS 為全球數百個網站提供支持，每月幫助處理數百萬個請求。 你好杰克， 在本文中，我看到兩個語句。 ->快速用于外部 API 緩存和交付 -> Cloudfront 作為客戶資產的 CDN 是否有特定原因將 Cloud Front 用作客戶資產？ 為什么我們不能快速使用 CDN？