在QCon紐約2016大會(huì)上，Etsy軟件工程師Stefanie Schirmer介紹了其公司如何成功轉(zhuǎn)換到API優(yōu)先的架構(gòu)，實(shí)現(xiàn)了多設(shè)備支持，解決了服務(wù)器端性能問(wèn)題，被開(kāi)發(fā)團(tuán)隊(duì)迅速采用。

Etsy工程團(tuán)隊(duì)已經(jīng)名聲在外，他們?cè)O(shè)計(jì)的架構(gòu)針對(duì)變更進(jìn)行了優(yōu)化，方便了持續(xù)試驗(yàn)，讓他們可以每天部署50次。因此，你可能會(huì)覺(jué)得意外，幾年前，他們還在研究解決嚴(yán)重的性能問(wèn)題。

他們的目標(biāo)是1000毫秒以下，因此，他們需要降低每個(gè)客戶端請(qǐng)求的服務(wù)器處理時(shí)間。遺憾的是，單線程的PHP世界輕易不允許并發(fā)API調(diào)用，只能緩慢地順序執(zhí)行。Schirmer及其同事需要解決如何實(shí)現(xiàn)并發(fā)，否則，他們就會(huì)冒著永久性性能問(wèn)題的風(fēng)險(xiǎn)。更為復(fù)雜的是，他們并不清楚，性能退化的根本原因是后臺(tái)問(wèn)題，還是客戶端請(qǐng)求的性質(zhì)。

遺憾的是，開(kāi)發(fā)團(tuán)隊(duì)不能只是致力于提高性能。除了要支持和升級(jí)Etsy.com網(wǎng)站外，移動(dòng)應(yīng)用的新特性需要從平臺(tái)上增加可擴(kuò)展性。這兩個(gè)問(wèn)題的解決方案需要API團(tuán)隊(duì)采用一種新的設(shè)計(jì)哲學(xué)，同時(shí)要保證它們是開(kāi)發(fā)團(tuán)隊(duì)所熟悉且易于為他們所使用的API。

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

整個(gè)技術(shù)棧構(gòu)成了一棵多層的樹(shù)，如下圖Schirmer的幻燈片所示。面向客戶的“訂制（bespoke）”主頁(yè)被裁剪成了特定的視圖。它使用了一個(gè)并行元端點(diǎn)層，后者反過(guò)來(lái)又調(diào)用了原子組件端點(diǎn)。只有最底層的組件（它們不是元端點(diǎn)）能夠和數(shù)據(jù)庫(kù)交互。

元端點(diǎn)層降低了組合網(wǎng)站和移動(dòng)應(yīng)用訂制視圖的復(fù)雜性。不過(guò)，多個(gè)元端點(diǎn)單線程處理無(wú)法滿足性能需求。Etsy工程師利用cURL發(fā)起并行HTTP調(diào)用，甚至是修改libcurl以滿足需求。自定義的監(jiān)控工具在請(qǐng)求通過(guò)框架扇出時(shí)將其調(diào)用層次可視化，讓開(kāi)發(fā)人員可以定位故障點(diǎn)。

他們還創(chuàng)建了其他的內(nèi)部工具，用于簡(jiǎn)化新API的應(yīng)用。Etsy首先自動(dòng)化了API客戶端（它知道每個(gè)端點(diǎn)的具體參數(shù)）生成，然后又配上了文檔，簡(jiǎn)化了開(kāi)發(fā)人員的學(xué)習(xí)曲線。團(tuán)隊(duì)沒(méi)有采用一種通用的培訓(xùn)方法，而是參加實(shí)驗(yàn)小組、代碼實(shí)驗(yàn)室、午餐和學(xué)習(xí)研討班，以及與有經(jīng)驗(yàn)的開(kāi)發(fā)人員結(jié)對(duì)。

Schirmer認(rèn)為，她講述的故事是一個(gè)關(guān)于架構(gòu)變革的案例，可以移植到其他系統(tǒng)。與API輔助工具和服務(wù)相關(guān)的工作有助于平臺(tái)團(tuán)隊(duì)將新API“賣(mài)給”開(kāi)發(fā)人員。為此，Schirmer及其同事一直保持著與開(kāi)發(fā)團(tuán)隊(duì)的溝通，以確保框架在不斷演化的過(guò)程中可以照顧到所有人的利益。

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