【51CTO.com快譯】如今，各大企業(yè)都紛紛以消費(fèi)者為導(dǎo)向，以為客戶提供價(jià)值為首要任務(wù)。為了需要找到那些更有效率、工作更便利的方法，我們需要通過反復(fù)試驗(yàn)來構(gòu)建并試用系統(tǒng)的各項(xiàng)功能，以確保它們確實(shí)能夠?yàn)榭蛻魩砹司薮蟮膬r(jià)值。近年來“微服務(wù)”的出現(xiàn)，恰恰方便了企業(yè)對于原有服務(wù)架構(gòu)的分解和按需組合。

由于微服務(wù)能夠使得傳統(tǒng)的具有高度依賴性的整體資源，被分解成為更小的獨(dú)立單元，因此我們能夠更快、更輕松地向系統(tǒng)中引入新的功能，而且最小化對于系統(tǒng)其他區(qū)域的影響。

在微服務(wù)中，API作為關(guān)鍵要素，可以極大地提高業(yè)務(wù)的敏捷性和效率。它往往位于客戶和微服務(wù)之間，將兩者連接在一起，以創(chuàng)建令人滿意的用戶體驗(yàn)。在本文中，我們將深入探討如何交付一款成功的API。

一、顛覆傳統(tǒng)的API交付模式

如果貴企業(yè)從事過消費(fèi)類API的交付過程，您一定熟悉以下的交付模型。

傳統(tǒng)API工作流程

在該模型中，我們首先使用某個(gè)門戶（portal）來設(shè)計(jì)、實(shí)現(xiàn)和記錄自己的API。接著，通過發(fā)布的方式，將其部署到我們的網(wǎng)關(guān)和開發(fā)人員的門戶上，以供應(yīng)用開發(fā)人員發(fā)現(xiàn)和使用。雖然此模型為我們提供了良好的服務(wù)流程，但是如今它已成為我們在為客戶提供價(jià)值的過程中，主要的敏捷性瓶頸之一。

為了提高微服務(wù)流程的自動(dòng)化效率，以及在發(fā)生故障時(shí)的“回滾”能力，我們需要改進(jìn)開發(fā)和部署的流程，將自上而下的方法，替換為如下圖所示的自下而上的方式：

自下向上的API開發(fā)方法

與部署代碼類似，我們的API也需要進(jìn)行持續(xù)集成和持續(xù)部署。

• 我們可以授權(quán)開發(fā)人員去構(gòu)建、部署和測試API，并在滿意的基礎(chǔ)上，將其部署到門戶和生產(chǎn)環(huán)境的網(wǎng)關(guān)中。
• 我們需要使用SCM（Github）對API的代碼進(jìn)行版本控制和管理。
• 我們需要使用Jenkins、Travis CI等自動(dòng)化構(gòu)建工具，來將API自動(dòng)部署到各自的環(huán)境中。
• 我們需要為開發(fā)人員配齊所需的適當(dāng)工具，以方便在API上啟用CI/CD，并對其進(jìn)行類似應(yīng)用程序源代碼式的管理。

二、API治理

當(dāng)然，采用自下而上的API交付模型也需要適當(dāng)?shù)剡M(jìn)行治理。研發(fā)團(tuán)隊(duì)有責(zé)任確保其發(fā)布的API能夠遵循正確的標(biāo)準(zhǔn)，優(yōu)秀的實(shí)踐，以及恰當(dāng)?shù)谋Ｗo(hù)。

API工作流程

如上圖所示，API需要通過良好“控制平面（Control Plane）”來支持生命周期的管理。在被發(fā)布到門戶之前，以及通過CI/CD被交付到上層環(huán)境之前，API需要得到充分的審核。我們通過可配置的工作流，將API的設(shè)計(jì)以及驗(yàn)證等優(yōu)秀實(shí)踐，應(yīng)用到相關(guān)的安全性架構(gòu)之上。

三、可組合性

API的可組合性

API不再僅僅是微服務(wù)的簡單HTTP接口。現(xiàn)代企業(yè)架構(gòu)由許多不同類型的微服務(wù)所組成。您可以讓團(tuán)隊(duì)開發(fā)出作為無服務(wù)器功能（例如AWS Lambda）的各種微服務(wù)，并發(fā)布到gRPC，WebSockets上。

同時(shí)，應(yīng)用程序需要通過統(tǒng)一界面來訪問這些服務(wù)。該界面包括應(yīng)當(dāng)具有單一的身份驗(yàn)證服務(wù)、訪問服務(wù)的授權(quán)、單一的SDK、以及統(tǒng)一的文檔等。這些都是由API層提供給應(yīng)用程序的?？梢姡珹PI并不是一組服務(wù)的簡單代理。它具有能夠處理集成異構(gòu)微服務(wù)細(xì)微差別的能力，并通過“暴露”的統(tǒng)一接口，以供應(yīng)用程序使用這些細(xì)微差異化的單元。

四、API安全

許多組織會(huì)將其業(yè)務(wù)功能作為公共的API發(fā)布出去。這自然會(huì)使得API成為攻擊者嘗試竊取敏感信息，進(jìn)而對組織造成危害的狩獵場。因此，我們需要對API的安全性問題保持高度的警惕，并設(shè)為高優(yōu)先的事項(xiàng)。

通常情況下，企業(yè)會(huì)從基于OAuth2.0的身份驗(yàn)證和授權(quán)方式入手。如下圖所示，我們還應(yīng)當(dāng)考慮到如下三個(gè)方面的API安全性：

• 防止惡意內(nèi)容和DoS攻擊。
• 身份驗(yàn)證和授權(quán)。
• 通過不斷識別與異常模式的學(xué)習(xí)，來保證安全性。

API安全性工作流

惡意內(nèi)容和DoS攻擊

為了攻擊API，黑客可以完全控制其發(fā)送的惡意請求。這些請求消息既可能是注入攻擊（如：SQL注入）的消息，又可能是畸形消息（導(dǎo)致大量耗盡服務(wù)器的資源），還可能是包含XML炸彈（https://www.soapui.org/security-testing/security-scans/xml-bomb.html）的消息等。

所謂DoS攻擊是指：惡意軟件客戶端會(huì)發(fā)出大量的API請求，導(dǎo)致服務(wù)器沒有足夠的資源去為真正的用戶請求提供服務(wù)。為了防范此類針對API的攻擊，我們可以使用Web應(yīng)用防火墻（WAF）或API網(wǎng)關(guān)，來檢查消息的內(nèi)容，并根據(jù)預(yù)定義的規(guī)則與模式予以驗(yàn)證。同時(shí)，它們還能夠限制客戶端請求的速率，以防止客戶端在較短的時(shí)間內(nèi)發(fā)送大量的消息。而對于安全網(wǎng)關(guān)而言，我們也需要通過持續(xù)監(jiān)控，發(fā)現(xiàn)新的漏洞，并及時(shí)為其打上補(bǔ)丁。

盡管從技術(shù)上來說，API網(wǎng)關(guān)和Web應(yīng)用防火墻都可以防范此類攻擊，但是Web應(yīng)用防火墻會(huì)更適合些。其原因在于：Web應(yīng)用防火墻更專注于此類安全域，而API網(wǎng)關(guān)則通常負(fù)責(zé)系統(tǒng)中的多項(xiàng)功能性任務(wù)。

身份驗(yàn)證和授權(quán)

在身份和訪問控制方面，我們往往會(huì)基于有效的憑證，來授予請求對于API資源的訪問權(quán)限。此類憑證包括：OAuth2.0訪問令牌、API密鑰、基本身份驗(yàn)證的標(biāo)頭、客戶端證書等內(nèi)容信息。例如，任何具有有效用戶名和密碼的用戶，都應(yīng)當(dāng)被允許在某個(gè)電商網(wǎng)站上瀏覽產(chǎn)品的詳細(xì)信息。但是，只有那些具有管理員權(quán)限的用戶才被允許更新產(chǎn)品的詳細(xì)信息。當(dāng)然，訪問控制也不僅限于基于角色的檢查，有時(shí)一些系統(tǒng)還會(huì)根據(jù)日期和時(shí)間（如：僅允許在工作日的8點(diǎn)到17點(diǎn)之間訪問），或基于請求的配額等方面進(jìn)行訪問控制。

上文提到的API網(wǎng)關(guān)，可專門負(fù)責(zé)此類身份驗(yàn)證與授權(quán)檢查。它們將各種系統(tǒng)安全需求抽象成標(biāo)準(zhǔn)的規(guī)范和協(xié)議，并允許客戶端應(yīng)用通過該機(jī)制（例如OAuth2.0）與之交互。

另外，下游或后端API有時(shí)候也需要了解訪問API用戶的詳細(xì)信息，以便執(zhí)行其固有的邏輯。因此，有些API網(wǎng)關(guān)還會(huì)負(fù)責(zé)將用戶的上下文，轉(zhuǎn)發(fā)到下游或后端API上。

為識別模式和檢測異常而持續(xù)學(xué)習(xí)

光有防火墻和簡單的身份驗(yàn)證，是不足以檢測API密鑰或訪問令牌等憑據(jù)入侵的。前文提到了OAuth2.0，其訪問令牌的時(shí)間跨度相對較短，即使被黑客入侵，也只能在令牌過期之前有效。那么為了防止令牌在這么短的時(shí)間內(nèi)被被盜，我們需要通過MFA（多因素身份驗(yàn)證）來進(jìn)一步執(zhí)行身份驗(yàn)證。

值得一提的是，API網(wǎng)關(guān)本身并不能保護(hù)系統(tǒng)免受異常攻擊，它只是在橫跨不同網(wǎng)絡(luò)的群集之間避免共享用戶的狀態(tài)和訪問記錄。因此，API網(wǎng)關(guān)需要與某些機(jī)器學(xué)習(xí)和數(shù)據(jù)模式分析類型的方案一起使用。這些方案將能夠跟蹤用戶的訪問歷史記錄和模式，并在出現(xiàn)問題時(shí)向API網(wǎng)關(guān)發(fā)出警報(bào)，以便網(wǎng)關(guān)采取適當(dāng)?shù)拇胧?/p>

五、可擴(kuò)展性

API的擴(kuò)展

如今，許多組織正在將他們的基礎(chǔ)架構(gòu)遷至云端，以按需付費(fèi)的方式在第三方IaaS提供商（如：AWS、Google、以及Azure等）上運(yùn)行全部或部分IT服務(wù)。云原生架構(gòu)的一項(xiàng)關(guān)鍵特征是能夠提供自動(dòng)擴(kuò)展的服務(wù)。那么我們的API及其網(wǎng)關(guān)也要具有此類特征。在此方面，我們需要考慮到如下三點(diǎn)：

• 啟動(dòng)的延遲。
• 對其他系統(tǒng)的依賴性。
• 狀態(tài)的復(fù)制。

通常，進(jìn)程啟動(dòng)的速度越快，就越容易擴(kuò)展。例如：某個(gè)進(jìn)程需要30秒或更長時(shí)間才能啟動(dòng)，那么它就至少需要在30秒之前開始擴(kuò)展，以便系統(tǒng)能夠及時(shí)啟動(dòng)并運(yùn)行該進(jìn)程。也就是說，如果某個(gè)進(jìn)程啟動(dòng)需要的時(shí)間越長，您越需要提前擴(kuò)展該進(jìn)程。

有時(shí)候，某個(gè)進(jìn)程無法自行擴(kuò)容，此時(shí)您的API及其網(wǎng)關(guān)就需要依賴于其他輔助類進(jìn)程來實(shí)現(xiàn)?？梢姡腁PI及其網(wǎng)關(guān)越獨(dú)立，就越容易實(shí)現(xiàn)系統(tǒng)的擴(kuò)展。另外，如果您的API及其網(wǎng)關(guān)需要維持內(nèi)部、外部狀態(tài)的一致性，那么在擴(kuò)展API時(shí)則需要考慮如何復(fù)制系統(tǒng)的狀態(tài)。與常規(guī)有狀態(tài)系統(tǒng)相比，獨(dú)立且無狀態(tài)的API更易于自動(dòng)擴(kuò)展。

六、可用性

如今系統(tǒng)的可用性變得越來越重要了。雖然云服務(wù)為我們的整體業(yè)務(wù)提升了魯棒性，但是我們?nèi)匀恍枰紤]如何為API構(gòu)建和配備具有一定的彈性系統(tǒng)，其中包括：

• 當(dāng)系統(tǒng)出現(xiàn)故障時(shí)，我們能夠快速地恢復(fù)系統(tǒng)。
• 數(shù)據(jù)中心、整體區(qū)域、以及IaaS服務(wù)的高可用性。

通常而言，我們很容易通過備份的形式滿足單個(gè)系統(tǒng)中的每個(gè)服務(wù)器、進(jìn)程、文件系統(tǒng)、以及數(shù)據(jù)庫的高可用性。但是，我們該如何應(yīng)對整個(gè)數(shù)據(jù)中心或區(qū)域的故障呢？我們通常需要在多個(gè)數(shù)據(jù)中心的位置上同時(shí)部署自己的API。而為了減少API構(gòu)建、部署和維護(hù)的開銷，我們往往需要通過盡可能多的自動(dòng)化，來輕松有效地實(shí)現(xiàn)跨多個(gè)可用區(qū)域的數(shù)據(jù)復(fù)制。

由于系統(tǒng)存在的依賴性越多，其故障恢復(fù)的難度就越大，因此許多系統(tǒng)都采用了具有自動(dòng)修復(fù)能力的原生云端容器平臺（如：Kubernetes），以降低故障恢復(fù)的難度。不過，云服務(wù)提供商本身的可用性最近也受到質(zhì)疑。設(shè)想一些：如果某個(gè)IaaS提供商的特定服務(wù)發(fā)生了全球范圍內(nèi)的中斷，我們是否能夠切換到其他IaaS處呢？例如，是否可以通過協(xié)作，我們將運(yùn)行在AWS RDS某個(gè)區(qū)域的中斷業(yè)務(wù)切換到Azure的備份上？

如今，已經(jīng)有企業(yè)成功地在不同地區(qū)的IaaS提供商之間部署了自己的API。他們在不同的IasS上構(gòu)建了分布式的可擴(kuò)展系統(tǒng)，并通過分擔(dān)整體系統(tǒng)負(fù)載的方式，實(shí)現(xiàn)了按需擴(kuò)展與付費(fèi)。

七、維護(hù)

我們可以從如下三個(gè)方面及時(shí)獲悉API有效性與性能:

• 運(yùn)營監(jiān)控
• 故障診斷
• 業(yè)務(wù)監(jiān)控

運(yùn)營監(jiān)控

運(yùn)營監(jiān)控對于API的正常運(yùn)行，以及業(yè)務(wù)平穩(wěn)開展都是至關(guān)重要的。您需要在真正發(fā)生問題之前就能判定故障，予以解決，并消除負(fù)面影響。例如：您的某個(gè)服務(wù)或API出現(xiàn)了耗盡內(nèi)存的情況，那么您就可以及時(shí)通過監(jiān)控系統(tǒng)，檢測到API對于內(nèi)存使用率的極速增長，并在超過既定閾值的時(shí)候收到警報(bào)信息。而針對此類情況，我們往往可以通過擴(kuò)展出更多的實(shí)例進(jìn)程，來為根本原因的查找和解決贏得時(shí)間。

故障診斷

對于事件的故障診斷，及時(shí)收集到故障的相關(guān)數(shù)據(jù)是非常重要的。首先，我們需要從API和服務(wù)處收集到所有的運(yùn)行時(shí)日志，通過對其進(jìn)行索引，以便快速輕松地進(jìn)行搜索，進(jìn)而獲取和識別特定時(shí)間段發(fā)生的系統(tǒng)事件。在掌握事件日志之后，我們需要根據(jù)“蛛絲馬跡”按需啟用進(jìn)一步的日志跟蹤，以獲取內(nèi)存dump、網(wǎng)絡(luò)等方面的信息。

您應(yīng)該致力于構(gòu)建能夠以理想的零故障率或最小的客戶影響率進(jìn)行故障排除的系統(tǒng)。這樣做的一種流行模式是將一組故障節(jié)點(diǎn)隔離到一個(gè)單獨(dú)的群集中，該群集要么不接收客戶的流量，要么僅接收一小部分流量，以方便執(zhí)行故障排除。

業(yè)務(wù)監(jiān)控

現(xiàn)如今，許多企業(yè)都將對外提供API作為自身業(yè)務(wù)的主要增長點(diǎn)。因此，他們需要通過衡量API的使用，來決定組織業(yè)務(wù)的策略。為此，我們需要一個(gè)系統(tǒng)來捕獲與實(shí)現(xiàn)與當(dāng)前業(yè)務(wù)目標(biāo)相關(guān)的所有API數(shù)據(jù)，其中包括：前一個(gè)月新API的使用者數(shù)量，基于現(xiàn)有API構(gòu)建的新應(yīng)用的數(shù)量，調(diào)用當(dāng)前API的應(yīng)用在其響應(yīng)時(shí)間上的改進(jìn)，特定區(qū)域內(nèi)API用戶的增長等方面。我們通過深入挖掘API的調(diào)用，以衡量業(yè)務(wù)KPI的表現(xiàn)。

總結(jié)

通過上述討論，希望您已經(jīng)了解到：

• 為客戶提供價(jià)值是我們的第一要?jiǎng)?wù)?；谖⒎?wù)的架構(gòu)能夠以更快的速度交付出可靠的軟件，從而為客戶提供更高的價(jià)值。
• API是企業(yè)創(chuàng)建數(shù)字體驗(yàn)的架構(gòu)基礎(chǔ)。
• 現(xiàn)代化API往往是自下而上開發(fā)的，因此開發(fā)人員和CI/CD流程尤為重要。
• API的治理在確保正確地交付API方面發(fā)揮著重要的作用。
• 組織應(yīng)具有將服務(wù)的異構(gòu)集合組合到不同API中的能力。
• API的安全性主要包括：內(nèi)容檢查，身份驗(yàn)證和授權(quán)，以及異常模式的分析。
• API應(yīng)該具有可擴(kuò)展性，以滿足云原生應(yīng)用的需求。
• 我們需要通過云服務(wù)給API帶來更高的可用性。
• 對于API的監(jiān)控是企業(yè)持續(xù)發(fā)展的重要保障。

原文標(biāo)題：Delivering a Successful API: Know What it Takes，作者：Nuwan Dias

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】