編者按：小編也參加過不少技術大會，臺下聽到比較多的一種評論：“大師的分享很贊，不過我們這種體量的公司暫時還用不上……”，針對這種情況，小編挑選了一個發展十年的中型的電商網站 etsy，目前在 alexa 上排名 153，美國排名第 42，和國內很多電商公司流量相當。

etsy 的架構和很多成長型公司的架構非常相似，由於創始團隊沒有網際網路開發經驗，按照傳統軟體開發思維搭建的架構給後期擴充套件帶來了沉重的負擔；另外小編也瞭解到，大一點的網際網路公司基本是按照職能進行分工的，RD，OP，DBA，QA 各司其職，這也是後文要談的康威定律，也就是分工決定架構的思路的隱患。

原型：3 個工程師開發的系統

Etsy 的是手工品交易市場，網站從 2005 年 6 月開始做，由 3 人在一間公寓開發。這和很多初創型應用非常類似。

2007 年：中心化大型資料庫的架構

技術棧：Ubuntu, PostgreSQL, lighttpd, PHP, Python

早期我們對網際網路模式並不是特別熟悉，按照傳統軟體的思路，業務邏輯大多在 PostgreSQL 的儲存過程中實現。前端互動使用 PHP 呼叫儲存過程。使用大型中心化的資料庫，按照業務功能分成不同的資料庫。

當時的架構問題很多，可用性很差，需要定期維護視窗，意味著網站較長時間不可訪問。上線部署往往會導致故障與中斷。

2008 年：錯誤的架構決策：基於分工的架構選型

雖然過去了 2 年，依然是家創業公司，20 – 30 人。

康威定律：人力組織的架構往往決定了設計的層次。

康威定律描述了當時的現狀，團隊的結構：開發，DBA，運維。 開發寫程式碼，DBA 寫儲存過程，運維部署程式碼。 團隊之間由於分工形成了明顯的隔閡。

為了解決架構的可擴充套件性問題，但也是由於受康威定律的思維侷限，團隊建立了一個名為 Sprouter 中介軟體層：儲存過程路由器。這個成為後面架構沉重的包袱。

• Sprouter 是一個 Python 守護程序，處於 Web 伺服器和資料庫之間。前端給它傳參，它呼叫儲存過程並返回結果。從理論上講它可以實現快取和分片的邏輯，但這些功能當時都沒有實現；
• 當時期望 Sprouter 比資料庫更容易擴充套件，因為基於資料庫儲存過程的一個架構很難擴充套件；
• 但折衷的架構很難工作，Sprouter 在 2008 年秋天上線，但在 2009 年就被放棄，因為它幾乎不能工作。

Sprouter 開發完成後依舊存在一大堆問題：

• 每次上線依賴 DBA 的工作，因為資料庫所有的事情由 DBA 負責
• 上線釋出更換亂，因為在 Sprouter 中，快取了儲存過程的識別符號，如果進行了更新，識別符號會失效。因此每次上線釋出都成了一次災難。
• 一些業務資料庫仍然沒有分片，這些資料庫就成了系統的單點故障環節。

2008 年：Etsy 開發文化大轉型

新來了 CTO（後來成為公司的 CEO） 帶來了新的團隊文化。

• 逐漸放棄 PostgreSQL 和儲存過程；
• 使用標準 SQL 開發；
• 讓開發人員接觸生產環境；
• 放棄大版本大包釋出的方法；

2009 年：轉型中的架構：5 大改進

1. 引入 DevOps

• 打破開發和運維之間的隔閡，開發也是運維，運維也能承擔開發工作；
• 打破團隊隔閡：那就是信任、合作、透明以及共同承擔責任；
• 我們是一條船上的人，只有互相幫助才能把東西做得更好。

2. 網站穩定性改進

• 增加及改善監控及圖表。
• 授權開發人員可以訪問及執行生產環境程式碼，以便他們能夠幫助解決問題。 儘管不是所有的開發人員對生產裝置開放 root 許可權。

3. 實現一鍵式持續交付，沒有獨立的 QA

• 實現了持續交付。 任何工程師可以隨時部署整個網站到生產環境，一鍵式部署，非常簡單。
• 用 Chef 來做配置管理。
• 採用小迭代釋出，放棄大包部署。上線如果出現問題，可以很快找出原因並立即修復。
• 上線的程式碼新增測試用例，以驗證部署前的程式碼工作。
• 團隊使用 IRC 隨時交流。
• 沒有獨立的 QA 團隊或流程，質量由開發負責。開發人員負責保證自己程式碼是穩定的，小迭代的開發模式讓開發保證質量更為容易。
• 實現 A / B 測試方案，允許某個功能只開放給管理員或一定的比例使用者，降低了開發人員上線風險。
• 每個開發人員都要求每年有一週來響應線上事務（on call），打破崗位之間隔閡。

4. 開發自己的 ORM，棄用 Sprouter

使用 ORM（物件關係對映）來代替 Sprouter。ORM 也是自己開發的。ORM 也實現一些快取。前端 PHP 程式碼直接通過 ORM 來訪問資料庫。使用 ORM 將一些業務邏輯操作更多轉移到前端程式碼，Web 伺服器更容易擴充套件。

5. 資料庫的分片擴充套件性改造：從 PostgreSQL 到 MySQL

由於公司新加入不少來自 Flickr 的工程師，所以逐漸引入來自 Flickr 的資料庫分片方案 。

使用 MySQL 作為簡單的資料儲存伺服器，這種架構已經在 Flickr 久經考驗。資料庫可以根據需要無限擴充套件。另外通過 MySQL 雙主複製（master – master）來消除單點隱患。

2011 年春：Sprouter 下線

終於在 2011 年春天，Sprouter 從程式碼庫中刪除。

2011 年之後新的架構

• CentOS, MySQL, Apache, PHP.
• 逐步淘汰 PostreSQL。 遷移是通過一個個功能基礎上的實現。
• 放棄 Python，使用 PHP 及 MySQL

2012 – 2016 年的 Etsy 架構

Etsy 一直以來都是一個看起來很有趣的平臺，也有很多值得研究的地方，它從一個新型平臺轉型成一個穩定而值得認可的電子商務引擎。這種改變需要很多文化上的轉變，但是其結果是引人注目的。

2012 年之後架構又發生了什麼？他們還在創新嗎？工程決策是如何決定的，而這又以怎樣的方式影響了工程師文化？這一節我們要來問一問 Jon Cowie，他是 Etsy 的高階運維工程師，還是《定製 Chef》( Customizing Chef )一書的作者。

從 2012 年的升級之後就沒有發生太大的改變。有些人可能會覺得無聊，但是這種情況卻勾勒出了一個重要的概念，並且讓我們獲得了一些關於 Etsy 工程師文化的深入觀察。我們在整篇文章中都會重新提到這種文化，但是接下來我們先說說他們的總體架構。

Etsy 的生產環境是採用物理機，但是開發時，他們採用虛擬化環境。這種方式讓所有開發者擁有一臺包含整個棧的微縮版本的虛擬機器。真實的棧看起來仍然是這樣：

• Linux
• Apache
• MySQL
• PHP
• Caching layers
• F5 負載均衡

他們有幾個用於完成不同任務的不同快取記憶體層。他們為了高速緩 存資料庫物件，使用 memcached 的場景很多。

Etsy 有提供給第三方開發者的面向公眾的 API，但是他們也有內部 API。他們有為這些 API 準備的快取層，因為有些資料如果持續幾個小時或幾天都被人訪問，就需要快取。當然，快取的圖片和靜態資產也很多。

這裡的挑戰在於快取失效。一邊要確保你沒有把過期的髒資料提供給使用者，一邊卻還要儘量利用快取來減少你的資料庫負載。同時還要通過把響應快取到離終端使用者足夠近的地方，從而確保你對使用者提供了足夠快的響應。這是另一件 Etsy 團隊深度關切的事，從他 們的工程部落格 CodeasCraft.com 上的日常效能報告就能很明顯地看出。

雖然整體架構變化不大，但是這並不意味著 Etsy 的工程師和運維 團隊在這麼長的時間內都坐在那裡無所事事。沒準有些人確實是這樣，哈哈跑題了……

運維上的挑戰是什麼？他們是否仍然需要去滅火？

我們剛剛看到他們有多麼信賴成熟和被驗證過的技術，所以他們不需要花很多時間救火。新的問題通常都是通過引入新系統產生的。 我相信很多讀者都有過這樣的經歷：你引入了一個論文中提到的新系統，這個系統會解決你的所有問題。除了它會對你現在環境中的其他元件產生一個複雜而且“不可能”的反應。所以你就必須弄明白原因是什麼，以及解決問題的方法。

說實話，如果你身處這樣的場景，那麼這可能是一個千載難逢的機 會。這些讓你抓耳撓腮的有趣挑戰讓你特別想把問題弄明白，然後才能去迎接下一次挑戰。除非這個問題佔據的時間太長，它就成了一個討厭鬼。

為什麼選型用 PHP？

另外一個很多公司都需要面對的挑戰就是：想要僱傭偉大的牛人。 你在哪才能找到偉大的牛人？如果你正在使用最新最熱的技術，可能你很難發現這些牛人，而且價格也會更加昂貴。如果你使用的技術十分成熟，比如 PHP，那麼這件事就至少沒有那麼困難。當然仍然不簡單，但是相對來說比尋找一個 Scala 方面的牛人要容易一些。

很多 PHP 工具都存在了十年之久，這門語言本身也是歷史悠遠。 很多最前沿的問題都已經被解決了。這就意味著難以解答的奇怪問題少之又少，而你又有更多的專家可以找。

這是否意味著他們從來沒有對架構做過任何改變？

絕對不是。經過歷史上的教訓，目前對於架構選型及新技術使用有一個定義清晰的決策過程。

第一個就是“架構評審”，在這裡支持者可以把支援材料和提議背後的理論說出來，然後團隊就會想出一個他們認為可以適應 Etsy 現在環境的概念。

我們一起來看一下最近的一個例子。他們引入了 Kafka 來完成事件流操作。為此，團隊想出了為什麼要使用 Kafka 的用例，以及 Kafka 將如何解決 Etsy 上的真實問題。然後他們設立了一個架構評審，讓高階工程師和所有相關方聚在一起討論這個提議。

• 這是一種足夠成熟而且被驗證過的技術嗎？
• 它會真正解決問題嗎？它是解決問題的最佳方式嗎？
• 這個元件和我們的元件在一起會有什麼樣的反應？
• 誰來支援這件事？

一旦這些問題得到了回答，那就可以進入架構實現階段。

在上線之前，還需要經歷另外一個被稱為“上線操作評審”的流程，該流程會驗證是否萬事俱備。包括設立合適的監控和報警機制，以及為所有待命人員設定合適的規程等等。所有和這個實現相關的人員必須有 “做什麼（What），何時做（When），如何做（How）”的計劃。

另外一個重要的考慮就是“我們是否可以通過在已有的工具上進行改進來做這件事？”接下來我們將會詳細地講到這一點。

這類問題就是他們在實施一個技術提議前必須回答的問題。這種全面的分析可能需要時間，但是對於一個穩定的電子商務平臺來說，正常可用時間就是黃金。

“我們非常看重我們網站的正常可用執行時間、可靠性、以及總體可操作性。”

定製化與開源

我們已經看到 Etsy 的文化是如何鼓勵維持系統穩定性。但是我們沒有討論的這種文化是如何鼓勵大家如何定製現有的工具。

正如剛剛看到，與其通過實施新的工具來解決問題，定製一個已經在使用的工具是更合理的做法。一個重要的例子就是定製 Chef。Jon Cowie 曾經參與了一些非常具有影響力的 Chef 定製，比如 Knife-spork。這個定製事實上來自 Etsy 團隊試圖解決的一個問題。當好幾個開發者同時向同一個 Chef 伺服器和倉庫貢獻變更之後，變更就被重寫了。Jon 主導了這個工具的改進，他不僅幫助了開源社群，同時還解決了 Etsy 重要的限制性問題。

這也是激發 Jon 寫作《定製 Chef》(Customizing Chef）一部分原因。他早就希望能完成這樣一本書。

這也是 Chef 開源文化的一個好的例證。Jon 強調，Chef 的設計目的不是成為一個“一體適用”的解決方案。Chef 想要給人們提供一種能讓自己解決自動化問題的工具。Chef 認為使用者都是自己系統的專家，它無法告訴你該做什麼，但是它給你提供工具，所以你可以自己做決定然後告訴它你想做什麼。

當然，這不是說一切場合都追求定製，如果你定製了一段程式碼，你必須完全“擁有它”。一旦你決定開源這個工具，情況會變得更加複雜。事實上 Etsy 在決定開源工具之後馬上就遇到了類似問題，他們要開源工具，開源之後往往工程師們會在本地使用一個版本，針對 Etsy 基礎設施的需要編輯這個版本，然後永遠都不再向主倉庫回推，類似這樣很多專案都不會再被更新。

一個內部專案如何判斷是否適合開源？

他們是如何解決這個問題的？通過通過一個簡單流程。如果一個人想要在 Etsy 開源一個專案，他需要回答幾個關於這個專案的問題，包括明確該專案的維護方式。

流程幫助你確認哪些專案不會再被維護了，他們最終會仔細檢查各種各樣的專案，然後明確哪些專案不會再被更新了。這種做法讓工程師們得以重組，並聚焦在他們真正在內部使用的工具上。

“我們設定這些流程的目的主要就是為了確保我們只開源我們自己在生產過程中活躍使用的技術。”

畢竟到了最後，如果沒有人維護一個工具，這個工具對社群大概也起不到什麼幫助。（小編：非常贊同，把公司已經不用的專案開源意義不大）

etsy 架構演進啟示錄

• 開放和信任比封閉和害怕要好得多。
• 如果你正在做的事情聰明的它可能是錯的 。 如果你想擴充套件不採取未經檢驗的前端資料庫的互動方式的機會。 Etsy的是一個電子商務網站，他們不傳送火箭到月球。 他們在做什麼不是超級爭議，但它要麼是並不常見。
• 每一個做出的架構決策，都將產生長久的深遠的影響，即使在架構師離開公司之後的很長一段時間。
• 未來的路通常不是策劃出來的，但是它會隨著團隊的文化逐漸成型。

通過 Etsy 團隊重構及轉型的觀察，逐漸培養起敏捷、小團隊、獨立行動、鬆散的協作、目標驅動。中心化的文化讓步於分散式的核心。

訪談內容作者：Christophe Limpalair

ScaleYourCode 主持人，ScaleYourCode 是一檔致力於為專業開發者和公司傳遞專業知識的 Podcast 節目。本文根據其對 Jon Cowie 的採訪改編，Jon Cowie 是 Etsy 的高階運維工程師。

本文訪談內容翻譯李盼

原文出處——高可用架構「ArchNotes」微信公眾號