在QCon紐約2016大會上，Etsy軟件工程師Stefanie Schirmer介紹了其公司如何成功轉換到API優先的架構，實現了多設備支持，解決了服務器端性能問題，被開發團隊迅速采用。

\\

Etsy工程團隊已經名聲在外，他們設計的架構針對變更進行了優化，方便了持續試驗，讓他們可以每天部署50次。因此，你可能會覺得意外，幾年前，他們還在研究解決嚴重的性能問題。

\\

他們的目標是1000毫秒以下，因此，他們需要降低每個客戶端請求的服務器處理時間。遺憾的是，單線程的PHP世界輕易不允許并發API調用，只能緩慢地順序執行。Schirmer及其同事需要解決如何實現并發，否則，他們就會冒著永久性性能問題的風險。更為復雜的是，他們并不清楚，性能退化的根本原因是后臺問題，還是客戶端請求的性質。

\\

遺憾的是，開發團隊不能只是致力于提高性能。除了要支持和升級Etsy.com網站外，移動應用的新特性需要從平臺上增加可擴展性。這兩個問題的解決方案需要API團隊采用一種新的設計哲學，同時要保證它們是開發團隊所熟悉且易于為他們所使用的API。

\\

Etsy使用“元端點（meta-endpoints）”創建了一個兩層的API，而不是依賴于一個有一組扁平端點的API。和Netflix及eBay的ql.io的模式類似，Etsy的每個元端點都聚合了多個其他的端點。這讓服務器端可以將底層的通用資源組合成設備或視圖特有的資源。

\\

整個技術棧構成了一棵多層的樹，如下圖Schirmer的幻燈片所示。面向客戶的“訂制（bespoke）”主頁被裁剪成了特定的視圖。它使用了一個并行元端點層，后者反過來又調用了原子組件端點。只有最底層的組件（它們不是元端點）能夠和數據庫交互。

\\

\\

元端點層降低了組合網站和移動應用訂制視圖的復雜性。不過，多個元端點單線程處理無法滿足性能需求。Etsy工程師利用cURL發起并行HTTP調用，甚至是修改libcurl以滿足需求。自定義的監控工具在請求通過框架扇出時將其調用層次可視化，讓開發人員可以定位故障點。

\\

他們還創建了其他的內部工具，用于簡化新API的應用。Etsy首先自動化了API客戶端（它知道每個端點的具體參數）生成，然后又配上了文檔，簡化了開發人員的學習曲線。團隊沒有采用一種通用的培訓方法，而是參加實驗小組、代碼實驗室、午餐和學習研討班，以及與有經驗的開發人員結對。

\\

Schirmer認為，她講述的故事是一個關于架構變革的案例，可以移植到其他系統。與API輔助工具和服務相關的工作有助于平臺團隊將新API“賣給”開發人員。為此，Schirmer及其同事一直保持著與開發團隊的溝通，以確保框架在不斷演化的過程中可以照顧到所有人的利益。

\\

查看英文原文：How and Why Etsy Moved to an API-First Architecture

總結

以上是生活随笔為你收集整理的Etsy如何及为什么迁移到API优先的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。