《成長型電商架構啟示:世界排名153的etsy十年走過的彎路》要點：
本文介紹了成長型電商架構啟示:世界排名153的etsy十年走過的彎路，希望對您有用。如果有疑問，可以聯系我們。

編者按：小編也參加過不少技術大會,臺下聽到比較多的一種評論：“大師的分享很贊,不過我們這種體量的公司暫時還用不上……”,針對這種情況,小編挑選了一個發展十年的中型的電商網站 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」微信公眾號

 

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4508.html