# 如今 Etsy 的架構是什么樣的？ > 原文： [http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html](http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html)  *這是 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的來賓帖子，基于他對 [Jon Cowie](https://twitter.com/jonlives) ，員工運營部所做的[采訪](https://scaleyourcode.com/interviews/interview/25)（[視頻](https://www.youtube.com/watch?v=3vV4YiqKm1o)） 工程師和 Breaksmith @ Etsy。* 隨著 Etsy 從新平臺過渡到穩定且完善的電子商務引擎，Etsy 成為了一個令人著迷的觀看和研究平臺。 這種轉變需要進行很多文化上的改變，但最終結果卻是驚人的。 如果您還沒看過的話，2012 年上有一篇[帖子概述了他們的成長和轉變。 但是從那以后發生了什么？ 他們還在創新嗎？ 如何制定工程決策，這如何影響他們的工程文化？ 這些是我們與 Etsy 的一名運維工程師，定制廚師的作者 Jon Cowie 在新的播客節目中探討的問題。](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html) ## [](#what-does-etsys-architecture-look-like-nowadays)如今 Etsy 的架構是什么樣的？ 自上一次更新可追溯到 2012 年以來（在前面提到的帖子中），他們的體系結構并沒有真正改變太多。 盡管這聽起來有些無聊，但它概述了一個重要的概念，并為我們提供了對 Etsy 的工程文化的一些見識。 在整篇文章中，我們都會回頭介紹這種文化，但這是它們的總體架構： Etsy 的生產基礎設施全是裸機。 但是，在開發方面，他們可以虛擬化環境。 這為每個開發人員提供了一個代表整個堆棧縮影的虛擬機。 最終，虛擬環境仍在 Etsy 自己的物理硬件上運行。 實際的堆棧本身仍然看起來像這樣： * 的 Linux * 阿帕奇 * 的 MySQL * 的 PHP * 緩存層 * F5 負載平衡器 它們具有許多具有不同作業的不同緩存層。 他們大量使用 memcached 緩存數據庫對象。 Etsy 具有面向第三方開發人員的面向公眾的 API，并且還具有內部 API。 這些 API 有緩存層，因為有些答案不是短暫的。 例如，如果一個答案生存一個小時或更長時間，他們可能會緩存它。 當然，它們也大量緩存圖像和靜態資產。 這里的挑戰是緩存失效。 確保您沒有向用戶提供過時的內容，而是充分利用了緩存以盡可能減少數據庫的負載。 另外，請確保您通過將其緩存到更接近最終用戶的方式，更快地向用戶提供響應。 Etsy 團隊還深深地關心著這件事，這在其工程博客 CodeasCraft.com 上的定期性能報告中可以明顯看出。 盡管總體架構幾乎相同，但這并不意味著 Etsy 工程師和 Ops 團隊一直坐在那里擺弄他們的拇指。 好吧，也許其中一些有，但是我離題了... ## [](#so-what-are-their-ops-challenges-do-they-still-have-to-put-out-fires)那么他們的操作挑戰是什么？ 他們還必須滅火嗎？ 我們只是看到了它們在成熟可靠的技術方面會如何出錯，因此他們不會花費太多時間撲滅火災。 新問題往往來自引入新系統。 我敢肯定，你們中的許多人以前都讀過這篇文章：您介紹了一個新的系統，該系統在紙上可以解決您的所有問題。 除非它對您環境中當前的其他組件具有復雜且“不可能”的反應。 因此，您必須找出導致問題的原因以及解決方法。 老實說，如果您從事這一領域，那么您可能會活在當下。 這些有趣的挑戰使您抓狂，您真的想弄清楚，以便繼續進行下一個挑戰。 除非有時花費的時間太長，然后變得很麻煩。 大多數公司面臨的另一個挑戰是試圖雇用優秀人才。 您在哪里還能找到優秀的人才？ 如果您正在使用新的“熱門功能”，則可能很難找到該人才，而且價格會昂貴得多。 但是，如果您選擇像 PHP 這樣成熟的東西，它并不是那么困難。 仍然很難，但是不像為 Scala 找到人那樣難。 到目前為止，已有許多 PHP 工具出現了十年，而語言也是如此。 許多前沿漏洞已被消除。 這意味著更少的難以發現的怪異錯誤，以及更多的專家可以聘用。 ## [](#does-that-mean-they-never-change-anything-in-their-architecture)這是否意味著他們從不更改架構中的任何內容？ 不，絕對不是。 這意味著他們擁有制定使用新技術的決策的明確流程。 他們實際上使用一種工具來創建“體系結構評論”，支持者在其中輸入支持材料和該思想背后的理論。 然后，一個團隊將提出一個他們認為適合 Etsy 當前環境的概念。 讓我們看一個最近的例子。 他們介紹了 Kafka 用于事件流水線。 為了做到這一點，一個團隊提出了一個用例，說明了為什么要使用 Kafka 以及如何解決 Etsy 的實際問題。 然后，他們進行了體系結構審查，高級工程師和所有相關方聚集在一起討論該提案。 它是一種成熟且成熟的技術嗎？ 它會真正解決問題嗎？這是解決問題的最佳方法嗎？ 組件將如何與我們的系統反應？ 誰來支持這個？ 一旦回答了這些問題，它們便進入實施階段。 在上線之前，它必須經歷另一個稱為“可操作性審查”的過程，該過程將驗證一切是否就緒。 這包括設置適當的監視和警報，為每個待命人員設置適當的程序，等等。 與該實現有關的每個人都必須參與“什么，何時，如何”。 另一個重要的考慮因素是：“我們可以通過在已經擁有的工具上構建它來做到這一點嗎？” 稍后，我們將詳細介紹。 這些是在實施建議的技術之前必須回答的問題。 這種徹底的分析可能需要一些時間，但是對于已建立的電子商務平臺而言，正常運行時間至關重要。 “我們非常重視站點的正常運行時間，可靠性和總體可操作性。” ## [](#customizing)自定義 我們已經看到 Etsy 的文化如何促進穩定。 我們還沒有討論的是它如何鼓勵定制現有工具。 就像我們剛剛看到的那樣，與其實施一個新的工具來解決問題，不如定制一個正在使用的工具，這更有意義。 一個典型的例子是定制 Chef。 喬恩·考伊（Jon Cowie）成為一些有影響力的廚師定制的一部分，例如[刀叉](https://github.com/jonlives/knife-spork)。 這種自定義實際上來自 Etsy 團隊試圖解決的問題。 當多個開發人員同時對同一 Chef Server 和存儲庫進行更改時，更改將被覆蓋。 Jon 負責這個工具，不僅為一個大型開源社區提供了幫助，而且還解決了 Etsy 的一個關鍵且局限性的問題。 這是激發喬恩（Jon）編寫 [Customizing Chef](http://shop.oreilly.com/product/0636920032984.do) 的一部分。 這是他希望自己擁有的書。 這也是 Chef 開源文化的一個很好的例子。 喬恩（Jon）強調說，Chef 并非設計為“一刀切”的解決方案。 它旨在為人們提供一個工具包，使我們能夠解決自己的自動化問題。 Chef 的想法是，用戶是他們自己系統的專家。 雖然它不能告訴您該怎么做，但它為您提供了工具，因此您可以自己做出決定，然后告訴您想要什么。 當然，這并不是說定制沒有自己的問題。 如果自定義某些內容，則必須“擁有它”。 一旦決定開源該工具或自定義工具，它將變得更加復雜。 實際上，Etsy 在決定開放源代碼工具之后就對此產生了疑問。 他們將開放該工具的源代碼，但隨后工程師將在本地下拉版本，為 Etsy 基礎結構對其進行編輯，然后再將其推回主存儲庫。 許多項目只是沒有被更新。 他們是如何解決的？ 通過適當的程序。 就像想要在系統中引入新技術一樣，如果您想在 Etsy 開放項目的源代碼，則需要回答一些有關該項目及其維護方式的問題。 它也很多都承認哪些項目不再需要維護了。 他們最終完成了多個項目，并明確表示不再進行更新。 這樣一來，他們就可以重新組合并專注于內部實際使用的工具。 “因此，我們已經建立的流程更加適合確保我們只開源自己在生產中積極使用的東西。” 因為歸根結底，如果沒有人要維護一種工具，那么它可能不會對整個社區有所幫助。 ## [](#what-about-you)你呢？ 您的過程和思維方式有何不同？ 您從 Etsy 的方法中學到了什么嗎？ 從他們的工程文化和開放源代碼實踐怎么樣？ [關于 HackerNews](https://news.ycombinator.com/item?id=11345723)