# Etsy Saga：從筒倉到開心到一個月的瀏覽量達到數十億 > 原文： [http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html)  我們很少聽到有關流行網站在其形成時期所獲得的顛簸和擦傷的故事。 [Etsy 的高級軟件工程師 Ross Snyder](http://ross-snyder.com/) 通過在 [Surge 2011](http://omniti.com/surge/) ：[擴展 Etsy：什么地方出錯了，什么地方正確了](http://www.youtube.com/watch?v=eenrfm50mXw)。 羅斯詳細而誠實地描述了 Etsy 從 2005 年的原始創業公司到 2007 年為成功而苦苦掙扎的創業公司，再到 2011 年成為普通的手工，超級縮放，ops 驅動的機器。 從這個富有啟發性的變革故事中可以學到很多東西： ## 起源故事 * [Etsy](http://www.etsy.com/) 是手工制品的市場。 他們與買賣雙方建立聯系，類似于 eBay，他們不處理商品。 * 開始時間：2005 年 6 月， [3 個人住在一個??公寓里](http://www.seomoz.org/web2.0/interview/etsy/2006)。 * 如今：250 名員工，每月瀏覽量達數十億。 總共 6 年。 ## 2007 年–當時的架構 * Ubuntu，PostgreSQL，lighttpd，PHP，Python * PostgreSQL 存儲過程中全部包含業務邏輯。 一次非常常見的體系結構。 * 前端使用包裝在 PHP 中的存儲過程調用與數據庫進行了交互。 * 大型中央數據庫，具有按功能進行分區。 分區給他們買了一些時間。 * 網站正常運行時間不是很好，這需要為電子商務網站付費。 * 定期維護窗口意味著該站點將定期關閉。 * 大爆炸軟件部署通常會導致中斷。 ## 2008-失敗的 Sprouter 實驗 * 現階段仍是一家初創企業，最高人數為 20-30 人。 * 康威定律：當團隊生產產品時，產品最終類似于生產產品的團隊。 * 團隊看起來像：開發人員，DBA，運營人員。 開發人員編寫代碼，DBA 編寫存儲的 proc，Ops 部署的代碼。 一個筒倉組織，團隊之間有很多墻。 * 為了解決其可伸縮性問題，他們創建了中間件層，稱為 Sprouter-存儲過程路由器。 * Sprouter 是位于 Web 服務器和數據庫之間的 Python 守護程序。 給它一些參數，它調用存儲過程，并返回結果。 從理論上講，它可以進行一些緩存和分片，但是這些功能并未實現。 * 希望 Sprouter 比數據庫更容易擴展，因為圍繞存儲過程構建的體系結構幾乎是不可能的。 * 已于 08 年秋季準備就緒。自 09 年起棄用，此方法無效。 * Sprouter 仍然是一個筒倉架構，類似于他們擁有的團隊。 * 由于 DBA 忙于所有數據庫工作，這給開發人員帶來了很多麻煩，這與時間表的依賴關系很大。 請記住，只有 DBA 才能進行數據庫工作。 * 已棄用 Ops 仍必須處理依賴項。 事實證明，Sprouter 依賴于 Python 的早期版本，這意味著他們無法升級 Python。 因此，有很多運營開銷。 * 由于 Sprouter 緩存了存儲過程標識符（在升級期間無效），因此 Made 的部署情況更糟。 部署幾乎每次都中斷。 * 沒有分片，數據庫仍然是單點故障。 ## 2008 年-大文化轉變 * [Chad Dickerson](http://blog.chaddickerson.com/) 被聘為首席技術官，后來成為首席執行官。 他帶來了新的文化，以前的文化不再存在于 Etsy。 * 刪除舊文化也被刪除： * 致力于 PostgreSQL 和存儲過程。 * 擔心開發人員使用 SQL 編碼。 * 通常，開發人員都不會接觸該產品。 * 不頻繁和大型部署是將代碼移入生產環境的想法。 * 美國國立衛生研究院的一般態度。 ## 2009 年春季-前進的方式：第 1 部分 * DevOps 救援 * DevOps 是同時也是工程師和 Ops 的 Ops 人員。 * 筒倉變壞了。 * 信任，合作，透明和共同承擔責任變得良好。 * 我們在一起。 讓我們互相幫助，共同完成任務。 * 穩定網站： * **安裝/改進指標并監視**。 * 盡可能垂直升級數據庫。 還是不夠，但是買了一些呼吸的空間。 * 使開發人員生產**訪問正在運行的代碼**，以便他們可以幫助解決問題。 開發了一個名為 [StatsD](https://github.com/etsy/statsd) 的工具。 雖然并非所有開發人員都扎根于生產機器。 ## 持續部署-前進的方向：第 2 部分 * 添加了**連續部署**。 Etsy 中的任何工程師都可以隨時將整個站點部署到生產中。 每天發生 25 次，因為它很容易。 這是**一鍵部署**。 * 開發了一個名為 [Deployinator](https://github.com/etsy/deployinator) 的工具。 **Chef** 用于配置管理。 * 最大的收獲是，**小更改集**一直在淘汰，而不是大規模部署。 如果出現問題，他們可以迅速找出問題所在并加以解決。 * 添加了對代碼運行的測試，以在部署之前驗證代碼是否正常運行。 * 小組**始終在 **IRC** 上與彼此**進行交談。 * **質量檢查由開發人員**執行。 在此過程中，沒有單獨的質量檢查小組或階段。 開發人員負責確保代碼可靠。 較小的變更集使此操作變得容易。 * 在持續不斷的部署過程中，數據庫架構更改是異常的。 他們每周有一天，即**模式更改日**。 功能標志用于打開和關閉功能，因此它們可以翻轉標志，并且架構在適當的位置可以打開標志。 * A / B 測試方案允許僅為管理員打開功能或將其發布給一定比例的用戶。 他們創建一個**功能標記**，提交一堆代碼，然后打開該標記，以便只有開發人員才能看到它。 * 每年的一周內，每個開發人員都在尋求**支持。 他們將在假期前后加倍。 Ops 有自己的輪換方式，因此開發人員和 Ops 總是隨時待命。** ## 2009 年春季-Sprouter 之死-前進的方向：第 3 部分 * 使用**對象關系映射器**繞過 Sprouter。 他們寫了自己的。 * 現在（再次），前端 PHP 代碼通過 ORM 直接與數據庫對話。 * 使用 ORM 將一些工作轉移到了易于擴展的 Web 服務器上。 * ORM 進行一些前端緩存。 * ORM 是一個臭名昭著的瓶頸，但還沒有解決這個問題，但他們意識到了這一潛力。 ## 分片的到來-前進的方向：第 4 部分 * 在 Sprouter 被中和后，數據庫仍然是單點故障。 * 由于 **Flickr** 的很多人都去了 Etsy，因此他們采用了 Flickr 的[分片方案。](http://highscalability.com/flickr-architecture) * 基于 **MySQL** 作為簡單的數據存儲。 **經過 Flickr 的戰斗測試**。 * 將數據庫**沿水平方向**縮放到無窮遠甚至更大。 * **主-主**復制用于刪除 SPOF。 ## 2011 年春季-關閉 Sprouter * Sprouter 使用停止所有策略釋放。 當人們在基礎架構上工作時，功能開發幾乎停止了，大型部署在您的面前爆炸了。 * 為了證明文化是如何發生變化的，有幾個人在一邊進行 Sprouter 的替換，然后他們**逐漸逐步使用**。 即使他們愿意，他們也不能只專注于 Sprouter。 * 終于在 2011 年春季，從代碼庫中刪除了 Sprouter。 ## 2011-現在的 Etsy 體系結構 * CentOS，MySQL，Apache，PHP。 * **逐步淘汰 PostreSQL** 。 仍然沒有完成。 遷移基于每個功能。 * **Python 不見了**。 他們需要讓人們參與進來，以便在 PHP 和 MySQL 上實現標準化。 ## 獲得的經驗教訓 * **開放和信任**比封閉和恐懼好得多。 * 如果您聰明地執行**，則可能是錯誤的**。 如果您打算擴展規模，請不要冒險使用未經測試的前端到數據庫交互方法。 Etsy 是一個電子商務網站，他們沒有向月球發射火箭。 他們在做什么并沒有那么大的爭議，但這也不是那么普遍。 * 在您離開后很長時間，今天做出的架構決策將產生重大影響。 * 沒有漏洞那么深，以至于可靠的縮放策略無法將您排除在外。 * 沒有前進的道路。 沒有計劃。 在文化轉變開始后的幾年中，這種情況逐漸發生。 盡管 Etsy 并未完全履行其 NIH 承諾，但由于他們自己構建了大多數內容，因此有關團隊結構如何決定軟件結構的文化/團隊觀察是一個深刻的問題。 [如上，](http://en.wikipedia.org/wiki/Hermeticism)以下，古人舉行了會議。 在實踐中如此清晰地看到它是很了不起的。 有趣的是，我們在網絡開發團隊中看到的全面變革-敏捷，叛亂，小組，獨立行動，松散協調，目標驅動-與[第四代戰爭](http://en.wikipedia.org/wiki/Fourth_generation_warfare)的戰斗策略和戰術平行 。 我們看到集中化讓位于分布式核心。 似乎復雜的不斷變化的景觀觸發了并行的演變。 ## 相關文章 * [Etsy 博客](http://codeascraft.etsy.com/) * [Flickr 架構](http://highscalability.com/flickr-architecture) * [優化開發人員的幸福感](http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happiness/) * [推送：Facebook，Flickr，Etsy](http://codeascraft.etsy.com/2011/06/01/pushing-facebook-flickr-etsy/) * [不斷變化的戰爭面孔：進入第四代](http://globalguerrillas.typepad.com/lind/the-changing-face-of-war-into-the-fourth-generation.html) 我很好奇要了解有關為什么分片 PostgreSQL 在 2011 年不如分片 MySQL 來證明引入第二個數據庫系統的理由的更多詳細信息嗎？ 我不知道 PostgreSQL 是否有問題，因為 Flickr 系統是建立在 MySQL 之上的，因此這顯然是實現其方案的選擇。 Etsy 工程團隊還有一個博客，標題為“ Code as Craft”。 = > http://codeascraft.etsy.com 你好 我想知道 postgres 是否不適用于可擴展性高的網站。 謝謝 tan 有趣的是有人從 python 轉向 php。