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

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

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

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

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

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

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

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

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

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

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

二、API治理

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

API工作流程

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

三、可組合性

API的可組合性

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

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

四、API安全

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

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

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

API安全性工作流

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

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

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

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

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

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

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

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

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

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

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

五、可擴展性

API的擴展

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

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

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

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

六、可用性

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

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

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

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

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

七、維護

我們可以從如下三個方面及時獲悉API有效性與性能:

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

運營監(jiān)控

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

故障診斷

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

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

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

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

總結(jié)

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

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

原文標題：Delivering a Successful API: Know What it Takes，作者：Nuwan Dias

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