在qcon紐約2016大會上，etsy軟體工程師stefanie schirmer介紹了其公司如何成功轉換到api優先的架構，實現了多裝置支援，解決了伺服器端效能問題，被開發團隊迅速採用。
\u0026#xd;\n\u0026#xd;\n
etsy工程團隊已經名聲在外，他們設計的架構針對變更進行了優化，方便了持續試驗，讓他們可以每天部署50次。因此，你可能會覺得意外，幾年前，他們還在研究解決嚴重的效能問題。
\u0026#xd;\n\u0026#xd;\n
他們的目標是1000毫秒以下，因此，他們需要降低每個客戶端請求的伺服器處理時間。遺憾的是，單執行緒的php世界輕易不允許併發api呼叫，只能緩慢地順序執行。schirmer及其同事需要解決如何實現併發，否則，他們就會冒著永久性效能問題的風險。更為複雜的是，他們並不清楚，效能退化的根本原因是後台問題，還是客戶端請求的性質。
\u0026#xd;\n\u0026#xd;\n
遺憾的是，開發團隊不能只是致力於提高效能。除了要支援和公升級etsy.com**外，移動應用的新特性需要從平台上增加可擴充套件性。這兩個問題的解決方案需要api團隊採用一種新的設計哲學，同時要保證它們是開發團隊所熟悉且易於為他們所使用的api。
\u0026#xd;\n\u0026#xd;\n
etsy使用「元端點（meta-endpoints）」建立了乙個兩層的api，而不是依賴於乙個有一組扁平端點的api。和netflix及ebay的ql.io的模式類似，etsy的每個元端點都聚合了多個其他的端點。這讓伺服器端可以將底層的通用資源組合成裝置或檢視特有的資源。
\u0026#xd;\n\u0026#xd;\n
整個技術棧構成了一棵多層的樹，如下圖schirmer的幻燈片所示。面向客戶的「訂製（bespoke）」主頁被裁剪成了特定的檢視。它使用了乙個並行元端點層，後者反過來又呼叫了原子元件端點。只有最底層的元件（它們不是元端點）能夠和資料庫互動。
\u0026#xd;\n\u0026#xd;\n
\u0026#xd;\n\u0026#xd;\n
元端點層降低了組合**和移動應用訂製檢視的複雜性。不過，多個元端點單執行緒處理無法滿足效能需求。etsy工程師利用curl發起並行http呼叫，甚至是修改libcurl以滿足需求。自定義的監控工具在請求通過框架扇出時將其呼叫層次視覺化，讓開發人員可以定位故障點。
\u0026#xd;\n\u0026#xd;\n
他們還建立了其他的內部工具，用於簡化新api的應用。etsy首先自動化了api客戶端（它知道每個端點的具體引數）生成，然後又配上了文件，簡化了開發人員的學習曲線。團隊沒有採用一種通用的培訓方法，而是參加實驗小組、**實驗室、午餐和學習研討班，以及與有經驗的開發人員結對。
\u0026#xd;\n\u0026#xd;\n
schirmer認為，她講述的故事是乙個關於架構變革的案例，可以移植到其他系統。與api輔助工具和服務相關的工作有助於平台團隊將新api「賣給」開發人員。為此，schirmer及其同事一直保持著與開發團隊的溝通，以確保框架在不斷演化的過程中可以照顧到所有人的利益。
\u0026#xd;\n\u0026#xd;\n
檢視英文原文：how and why etsy moved to an api-first architecture
Etsy如何及為什麼遷移到API優先的架構
在qcon紐約2016大會上，etsy軟體工程師stefanie schirmer介紹了其公司如何成功轉換到api優先的架構，實現了多裝置支援，解決了伺服器端效能問題，被開發團隊迅速採用。etsy工程團隊已經名聲在外，他們設計的架構針對變更進行了優化，方便了持續試驗，讓他們可以每天部署50次。因此，...
Etsy如何及為什麼遷移到API優先的架構
在qcon紐約2016大會上，etsy軟體工程師stefanie schirmer介紹了其公司如何成功轉換到api優先的架構，實現了多裝置支援，解決了伺服器端效能問題，被開發團隊迅速採用。etsy工程團隊已經名聲在外，他們設計的架構針對變更進行了優化，方便了持續試驗，讓他們可以每天部署50次。因此，...
Etsy如何及為什麼遷移到API優先的架構
在qcon紐約2016大會上，etsy軟體工程師stefanie schirmer介紹了其公司如何成功轉換到api優先的架構，實現了多裝置支援，解決了伺服器端效能問題，被開發團隊迅速採用。etsy工程團隊已經名聲在外，他們設計的架構針對變更進行了優化，方便了持續試驗，讓他們可以每天部署50次。因此，...