API架構的七級成熟度模型，看看你家的應用屬於哪一個級別？ - Sensedia

banq發表於2019-12-26
API架構模型

成熟度模型分為7個級別，分為3個常規分類：
  • 不基於API：  系統和整合體系結構不基於正式API，在某些情況下沒有通訊，而其他通常共享檔案，使用佇列，非結構化Web服務甚至製作一些TCP / Socket技術以提供應用程式之間的通訊。
  • 部分基於API：  系統和整合體系結構部分基於API，這意味著使用Service Repository和Developer Portal等資源對SOAP和RESTful Web服務進行了廣泛使用，但治理程度低，標準化和關注點分離（API和服務之間）。
  • 完全基於API：  系統和整合體系結構完全基於API，這意味著在API，服務和應用程式等層之間存在關注點分離。從業務角度看，API是新業務模型的基礎，或者業務本身依賴於API。還觀察到其他技術特徵和功能，例如強大的安全機制，API治理，監視，分析措施以及改進的API開發人員體驗。

級別1：隔離的應用程式
在這種情況下，系統架構基於無/低整合的隔離應用程式。應用程式的主要型別為：整體應用程式，現成的應用程式（如ERP或CRM）。

級別2：非結構化整合
應用程式之間有整合，但是它們是非結構化的，這意味著沒有訊息結構甚至使用技術的標準。此外，整合渠道是分散的（點對點），沒有集線器或某種匯流排-整合是臨時建立的，可以解決特定問題。通常使用的技術有：

  • 訊息佇列
  • Socket連線
  • 資料庫複製
  • 檔案共享（例如XML，CSV或EDI）


級別3：基於元件的體系結構
此級別指的是基於元件的系統架構，此處使用的主要架構模型為：

  • EJB（企業Java Bean）
  • CORBA
  • Microsoft COM / COM + / DCOM
  • 獨立的Web服務應用程式

主要整合技術為：
  • TCP /套接字（例如Java RMI，COM​​，EJB）
  • 定製Socket連線
  • HTTP端點（例如SOAP，HTTP上的RPC）

在此級別中發現的主要問題是：整合和介面沒有互操作性或互操作性很差，因為所使用的技術僅與另一側的同一技術通訊。Web服務是一個例外，但是通常它們不遵循標準，並且沒有任何形式的治理，這使得互操作性難以維護。

級別4：面向服務的體系結構
在此級別上，系統體系結構實現了SOA原理，例如，服務層和業務應用層之間的關注點分離。通常，應用層涉及業務和資料儲存功能，服務層涉及合同/介面標準化，抽象，可組合性，發現等。
系統架構的主要特徵是：

  • 單體應用程式（應用程式層）
  • SOA堆疊（ESB，BPEL，複雜事件處理器，服務暫存器等）
  • 本地基礎架構

整合技術為：
  • SOAP Web服務
  • RESTFul Web服務（但初期使用）
  • 訊息傳遞（例如，JMS，ActiveMQ等）

最後，與此級別相關的主要問題是：雖然服務層與應用層分離了，但是服務層和API層之間沒有關注點分離（請參見下圖），服務層也包含一些API功能。

API架構的七級成熟度模型，看看你家的應用屬於哪一個級別？ - Sensedia

級別5：基於微服務架構的私有API
在這個級別上，系統架構使用微服務方法。通常有兩種型別的層：微服務所駐留的前端層和後端層，在這種架構中，API閘道器的作用在某些情況下似乎是為了提供前端和後端之間的整合。由於只有內部前端應用程式使用這些API，因此我們將其歸類為私有API。
系統架構的主要特徵是：

  • 微服務模式的使用
  • API閘道器
  • 主要基於雲基礎架構和容器。
  • 網狀Mesh架構的初期使用

使用的主要整合技術是：
  • RESTful API（暴露於前端，甚至微服務之間的通訊）
  • AMQP（例如Kafka，RabbitMQ等）
  • 最初使用新的通訊協議，例如gRPC，Thrift等。

但是，此級別與API相關的關鍵問題是：API未被完全管理。僅使用一些功能，例如安全性和節流功能，這些功能由API閘道器提供。另一個重要特徵是，也不管理微服務公開的API，這意味著通訊是點對點的，沒有集中管理（缺少網格體系結構功能）。
要觀察的另一點是，該體系結構基於單個API閘道器，這不容易擴充套件到整個公司，強烈建議採用API平臺來維持這種體系結構的發展。
由於上述所有問題，我們將此級別分類為部分基於API。

級別6：開放式API
在這個級別上，公司通常具有其他級別的一些技術特徵，但是主要技術特徵是在其他之上具有API層。
在這種情況下，API是業務的重要組成部分，因為它支援業務增長。公司可以建立合作伙伴生態系統和開放的創新環境，以支援創造新的價值流和創新服務。
從技術角度看，可以觀察到其他特徵：

  • 商業或開源API平臺及其模組的使用
  • 使用開發人員入口網站來增加合作伙伴和初創公司的開發人員體驗
  • 使用Google Analytics（分析）模組監控技術和業務行為
  • 應用WAF和DDoS保護的強大安全約束。
  • RESTful API作為外部整合的標準。


級別7：API作為業務
顧名思義，在此級別的公司完全基於API來執行其業務。
以下是必須遵守的技術特徵：

  • 強大的API策略
  • 全面控制外部和內部API（包括服務和微服務之間）
  • 使用API​​平臺的全部功能
  • 嚴格遵守法規（例如PSD2）
  • 使用服務網格的成熟的微服務架構
  • 強大的基於雲的基礎架構和基礎
  • 多種託管通訊協議，例如RESTful，GraphQL，WebSockets，gRPC等。


成熟路線圖
一旦評估了公司並瞭解了公司的當前水平和期望水平，就可以建立發展路線圖，當然，此計劃的細節取決於各種因素，例如業務驅動因素，技術約束和未來前景。
但是，在建立計劃時，建議您考慮一些技巧，例如：

  • 首先，請從4級移至5級，而不是從4級移至7級，寶貝！
  • 選擇一個MVP專案來驗證您的假設，從小做起，測試，學習和應用建議
  • 從內部和受控API開始
  • 定義一些API模式並建立最小的API治理。

結論
實際上，要以某種形式參與API經濟，您的公司需要針對內部或外部上下文管理您的API。無論貴公司位於哪個級別，公司都可以啟動API策略的建立，例如，以建立基於API的合作伙伴生態系統為目標。
本文的主要重點是指出基於某些場景的體系結構有多成熟，以瞭解要實施的最佳技術解決方案和技術策略，以便根據業務和技術要求提供成熟的API體系結構。
 

相關文章