【51CTO.com快譯】衆所周知，API是一種接口。您可以使用此類接口將業務功能和業務數據作爲有價值的信息傳遞給客戶。例如：一家零售店可以通過API將其商品出售給足不出戶的客戶。顯然，如果您想發展自己的業務，則需要接觸更多的客戶。API恰好就能夠滿足這一點。藉助API，您可以與客戶、合作伙伴、甚至其他員工進行虛擬的連接，進而構建出完整的供應鏈。

可見，API的基本思想是：構建一個向內部和外部用戶公開的業務功能接口。而通過互聯網(或內網)公開服務的最常見、且廣泛被採用的機制(或協議)，便是REST over HTTP。您可以將接口定義爲客戶與系統之間的協約。此類協約可以通過採用Swagger、Open API Specification(OAS)或RAML等標準。一旦使用了標準機制來定義接口(協約)，用戶就可以據此來準備其客戶端應用(包括移動和Web應用)，而不必考慮協約背後、以及業務應用內部發生的事情。

那麼，承載所有這些接口，以便客戶可以訪問的接口組件，就被稱爲API網關。下面，讓我們來看看API網關是如何通過API，向用戶交付業務功能的。

圖：使用API網關向用戶公開業務功能

如上圖所示，用戶可以通過聯繫API網關，來獲取客戶端應用所需的業務功能。您可以將網關想象爲一個門衛或接待員，它通常需要具有以下功能：

• 基於標準格式(例如REST、Swagger、OAS)的託管類API。
• 允許多個用戶同時訪問。
• 使用某種形式的身份驗證，來驗證API用戶。

當然，隨着API程序的普及，您可能還會用到或提供許多其他高級的功能。

如何使您的API受歡迎?

現在，讓我們來看兩個通過使用API網關，向內、外部用戶開放特定的功能和數據，以改善業務流程的典型示例。

• 一家保險機構向保險經紀人公開了一組API，以註冊新的交易，併爲客戶生成報價。據此，經紀人和組織節省了大量的時間和精力。
• 某個製造型組織向代理商公開了一組API，以檢查生產線中某些產品的可用性，並根據該可用性做出訂單和取貨的決策，進而協助經銷商計劃其銷售、訂單和運輸的安排。

目前，我們有着多種接觸新客戶的方式。其中較爲簡單的一種方法是：開發併發布移動應用到諸如Google Play商店或Apple應用商店中。當然，我們需要配合進行一系列的營銷工作，促進應用能夠實現流行下載。

不過有了API，我們就可以通過對外發布，與供人調用的方式來創造價值。爲此，我們需要通過某個API商店或開發者門戶，來讓自己的API被發現，並與整個架構進行交互。

圖：通過開發者門戶擴展您的API使用

如上圖所示，開發者門戶允許外部開發人員使用您的API，並構建出與其當前應用相集成的更好體驗。例如：汽車銷售公司可以使用保險公司的API，讓汽車購買者直接從其汽車購買的應用中獲取對應的保險。可見，開發者門戶可以提供如下基本功能：

• 提供API目錄，以供用戶輕鬆地搜索和瀏覽到。
• 通過相關的文檔，來全面介紹API及其用法。
• 提供測試API各項功能的機制(可選)。

爲了提高在與外部開發人員交互時的整體效率，一些API管理產品還會包括如下高級功能：

• 給每個提供API評分和評論功能。
• 能夠通過社交媒體來共享API。
• API的使用情況分析。
• 細粒度的API安全配置。
• API的營利狀況。

您可以按需選擇具有上述功能的API管理平臺。

如何在組織內部擴展您的API策略?

讓我們來考慮這樣的情況：組織內部的會計部門準備“入住”現有的API平臺。他們不僅希望成爲API的使用者，也希望託管自己的API，以供內部其他部門使用。那麼，滿足該要求的最簡單方法是：從會計部門獲取API的具體要求，着手開發，然後在管理API平臺的團隊的監督下將其發佈出去。不過，此類方法在流程上容易造成各種瓶頸，時下流行的敏捷開發實踐和交付實踐不太適合。在此，我們就需要引入API Federation的概念了。它的基本思想是：我們應該能夠根據不同部門的需求，來聯合管理API平臺，而不是由一個單獨的團隊說的算。據此，該平臺應能夠能夠爲各個部門提供必需的獨立性和敏捷性，並能夠開發和維護自己的一套API和安全策略。

當然，這並不一定意味着您應該爲每個部門分別部署一套API平臺。相反，您可以使用“多租戶”的概念，在多個部門之間共享相同的API平臺。此舉的好處包括：更大的靈活性，更低的成本，以及更容易被採用的API平臺。

圖：通過Federation擴展組織內的API平臺

如上圖所示，一組方便內部業務部門使用的新API被部署到了API網關處。它們是由各個業務部門的開發人員所開發的，因此只有該部門的用戶，才能在開發者門戶中查看這些API，並在網關中執行它們。

當然，我們需要在網關級別上具有特定的、基於角色、或基於組的訪問控制功能，並且在開發者門戶級別上，需要有與之相對應的可視性控制。目前，大多數API管理供應商都能夠通過“多租戶”功能，來支持此類需求。

如何使您的API平臺成爲雲原生?

爲了能夠讓API平臺設計面向未來，我們往往需要其具有云原生(cloud-native)特性。也就是說，我們的API平臺需要具有云服務的四大優點：高可用性、彈性伸縮、節省成本、以及即付即用。

其中，可伸縮性和可維護性主要得益於模塊化的體系結構。如果您將所有的功能都整合到某個單一的應用中，那麼可擴展性會變得相當困難。在此，我們可以藉助微服務架構之類的概念來實現。也就是說，在將功能組件分爲彼此兼容、但又獨立的模塊之後，我們的部署將變得更加靈活。下面，讓我們來看看如何爲API平臺定義雲原生的架構。

圖：具有微型網關的模塊化API平臺

在前文中我們討論了：將API網關、以及API開發者門戶分別視爲一種單獨的組件。那麼在上面這張圖中，我們將API網關的安全性部分也單獨地視爲一個的組件，並稱之爲API密鑰管理，以便它能夠獨立地處理那些與安全性相關的需求。

在此，我們還引入了兩個分別用於API分析和API開發的附加模塊。如果您想根據不同的參數，分析API的使用情況，並據此做出決斷的話，那麼API分析組件最合適此類需求。而API開發組件是API開發人員在構建API時需要交互的組件。它既可以基於GUI的接口，又可以與源代碼管理系統、以及Jenkins之類的構建管道，綁定到完全自動化的過程中。

上圖中的另一個關鍵點是：內、外部網關的分離。它保證了不同API在執行或運行時(runtime)不會互相影響。此外，圖中灰色六邊形的組件描述了可以在某些用例中被使用的微型網關。您需要在隔離的運行時中部署一個、或一組可以獨立於其他組件運行的指定API。

最後，圖中所有帶有docker圖標的組件，都能夠像docker那邊被部署到雲原生的平臺中。您可以根據自己企業和項目的實際情況，選取如下基礎架構類型：

• 本地(物理/VM)
• IaaS(基於VM)
• 容器式
• Kubernetes

平臺的選擇

有了前文關於API平臺的基本介紹，您一定想知道有哪些可供選擇的API管理平臺。下面便是我爲您羅列五種的常見供應商：

• IBM API Connect(https://www.ibm.com/cloud/api-connect)
• Apigee(https://cloud.google.com/apigee)
• WSO2 API Manager(https://wso2.com/api-management/)
• Kong Enterprise(https://konghq.com/products/kong-enterprise/)
• Mulesoft anypoint platform(https://www.mulesoft.com/platform/enterprise-integration)

原標題：How to Select an API Management Platform for Your Business 

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