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

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

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

一、顛覆傳統的API交付模式

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

傳統API工作流程

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

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

自下向上的API開發方法

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

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

二、API治理

當然，采用自下而上的API交付模型也需要適當地進行治理。研發團隊有責任確保其發布的API能夠遵循正確的標準，優秀的實踐，以及恰當的保護。

API工作流程

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

三、可組合性

API的可組合性

API不再僅僅是微服務的簡單HTTP接口。現代企業架構由許多不同類型的微服務所組成。您可以讓團隊開發出作為無服務器功能（例如AWS Lambda）的各種微服務，并發布到gRPC，WebSockets上。

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

四、API安全

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

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

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

API安全性工作流

惡意內容和DoS攻擊

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

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

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

身份驗證和授權

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

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

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

為識別模式和檢測異常而持續學習

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

值得一提的是，API網關本身并不能保護系統免受異常攻擊，它只是在橫跨不同網絡的群集之間避免共享用戶的狀態和訪問記錄。因此，API網關需要與某些機器學習和數據模式分析類型的方案一起使用。這些方案將能夠跟蹤用戶的訪問歷史記錄和模式，并在出現問題時向API網關發出警報，以便網關采取適當的措施。

五、可擴展性

API的擴展

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

• 啟動的延遲。
• 對其他系統的依賴性。
• 狀態的復制。

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

有時候，某個進程無法自行擴容，此時您的API及其網關就需要依賴于其他輔助類進程來實現。可見，您的API及其網關越獨立，就越容易實現系統的擴展。另外，如果您的API及其網關需要維持內部、外部狀態的一致性，那么在擴展API時則需要考慮如何復制系統的狀態。與常規有狀態系統相比，獨立且無狀態的API更易于自動擴展。

六、可用性

如今系統的可用性變得越來越重要了。雖然云服務為我們的整體業務提升了魯棒性，但是我們仍然需要考慮如何為API構建和配備具有一定的彈性系統，其中包括：

• 當系統出現故障時，我們能夠快速地恢復系統。
• 數據中心、整體區域、以及IaaS服務的高可用性。

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

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

如今，已經有企業成功地在不同地區的IaaS提供商之間部署了自己的API。他們在不同的IasS上構建了分布式的可擴展系統，并通過分擔整體系統負載的方式，實現了按需擴展與付費。

七、維護

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

• 運營監控
• 故障診斷
• 業務監控

運營監控

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

故障診斷

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

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

業務監控

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

總結

通過上述討論，希望您已經了解到：

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

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

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