微API設計模式
摘要：本文介紹了微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來部署。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%