微API設計模式

關鍵時刻，第一時間送達！

作者丨Lukas Rosenstock

翻譯丨雁驚寒

摘要：本文介紹了微API設計模式的基本概念、組網及其優勢。以下是譯文

互聯網上的軟體部署始於伺服器。然後，有了虛擬化。 IaaS（infrastructure-as-a-service， 基礎設施即服務）是雲計算的第一步，它使得人們可以在一小時內配置好虛擬伺服器。 PaaS（platform-as-a-service， 平台即服務）是在物理機器和開發人員的代碼之間增加了一個抽象層。最後，構建微服務（而不是單體、集成API和遠程託管服務）的趨勢導致了當前階段無伺服器平台雲計算或FaaS（功能即服務）的出現，在此平台上部署了小單元的代碼，以及由託管服務提供商自動管理的整個基礎設施。

基於無伺服器和FaaS的思想，我在這裡要介紹一個我個人稱之為微API的概念。我將其定義為描述一段軟體的設計模式，這個軟體：

向其消費者公開Web API（REST或RPC風格），

在單個文件中實現，具有合理的低LOC（lines of code，代碼行），

依賴於一個標準化的框架和一系列的依賴關係

無需關心本地狀態。

微API在「執行引擎」中運行，執行引擎提供了標準化的框架和依賴關係。由於自定義邏輯非常小，因此微API可能是按需部署的，這意味著每當需要由特定的微API處理的請求出現時，可以從存儲庫中下載代碼，然後緩存到引擎內並立即執行。執行引擎被設計成多租戶的模式。它將自定義代碼放在沙箱中，這樣，不同的微API之間就不會相互影響。

由於其按需部署和多租戶的設計，分布在世界各地伺服器上的託管微API執行引擎網路可以像CDN（Content Delivery Network， 內容傳送網路）那樣工作。如果代碼在檢索到之後並沒有完成緩存，那麼就會在距離最近的消費者處接收並執行API請求。有了這樣一個邊緣伺服器網路，伺服器端邏輯的分發和擴展可以像分發靜態Web內容一樣簡單！在前期，不需要準備任何資源，這意味著託管一個微API端的成本幾乎為零。每秒數千個請求的高可擴展性可以通過水平或垂直的方式擴展執行引擎來實現。另一方面，在部署了引擎伺服器之後，微API也可以在單租戶環境中使用。引擎伺服器可部署在私有和混合雲中，甚至部署在網路邊緣的設備中。

與其他無伺服器環境不同，由於框架和依賴關係的選擇，以及執行引擎的影響，微API可能看起來限制很大。這是故意這麼設計的，因為這樣使得開發人員能夠專註於業務邏輯，可以快速啟動大量獨立的微API，而無需進行架構決策並管理每個微API的依賴關係。另外，還可以針對特定要求設計不同的執行引擎。

微API是完成以下任務的完美選擇：

一個API是另一個API的代理或外觀，用於橋接不同的身份驗證協議或轉換數據格式（例如，將XML轉換為JSON）。

在調用其他API或Webhook之前修改或檢查數據的webhook接收器。（譯者註：Webhook是用戶通過自定義回調函數的方式來改變Web應用的一種行為）

在通過另一個API或基於雲的存儲系統在存儲數據之前，需要一個簡單的數據驗證層。

將來自多個API的數據組合成單個響應。

具有靜態或半靜態響應的模型。

微服務架構中的路由組件。

總而言之，微API就像膠水一樣非常有用，它可以通過易於創建和部署的自定義代碼來連接任何東西，使它們比可視化集成和聚合服務更具通用性。

在CloudObjects公司，我們正在構建一個基於PHP和Silex 微框架的微API執行引擎，它利用PHPSandbox來提供一個安全的運行時環境。我們給它起了個名字叫phpMAE。phpMAE是圍繞著CloudObjects Core和其他即將到來的CloudObjects產品的集成而設計的，它為開發和混合部署以託管服務和完全開源的形式來分發提供。 微API的配置和源代碼存儲在CloudObjects Core中，並通過CloudObjects Core來部署。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！