api網關和esb區別

我最近談論了微服務模式的演變，以及來自Lyft的Envoy之類的服務代理如何幫助將彈性，服務發現，路由，指標收集等責任推到應用程序下一層。 否則，我們冒著希望并祈禱各種應用程序將正確實現這些關鍵功能或依靠特定于語言的庫來實現這一目標的風險。 有趣的是，這種服務網格的想法與企業空間中的客戶所知道的其他概念有關，并且我對此關系有很多疑問。 具體來說，服務網格與ESB，消息代理和API管理之類的事物有何關系？ 這些概念肯定存在重疊，因此讓我們深入研究吧。 歡迎在Twitter上關注@christianposta，以獲取有關此主題的更多信息！

四個假設

1）服務通過網絡進行通信

首先要說的是：我們正在談論通過異步，分組交換網絡相互通信和交互的服務。 這意味著它們在自己的進程和自己的“時間邊界”（因此在這里是異步性）中運行，并通過網絡發送數據包進行通信。 不幸的是， 不能保證異步網絡的交互 ：我們可能會以失敗的交互，停滯/潛在的交互等為最終結果，而這些場景彼此之間是無法區分的。

2）如果仔細觀察，這些相互作用是不平凡的

第二點是：這些服務如何相互交互并非易事； 我們必須處理失敗/部分成功，重試，重復檢測，序列化/反序列化，語義/格式轉換，多語言協議，路由到正確的服務以處理我們的消息，處理消息泛濫，服務編排，安全性等問題含義等。很多事情可能并且確實會出錯。

3）了解網絡有很多價值

第三：了解應用程序之間如何通信，消息如何交換以及潛在地控制此流量的方法具有很大的價值。 這一點與我們對3/4層網絡的看法非常相似； 了解哪些TCP段和IP數據包正在穿越我們的網絡，控制有關如何路由它們，允許什么的規則等，這很有價值。

4）最終是應用程序的責任

最后：正如我們從頭到尾的論點所知道的那樣，是應用程序本身負責其聲稱的業務邏輯的安全性和正確的語義實現–不管我們從底層基礎結構（重試，事務，重復檢測等）獲得什么可靠性。我們的應用程序仍必須防范用戶的愚蠢行為（兩次下訂單）–有助于實現這一目標的任何事情都是實施/優化細節。 不幸的是，這沒有辦法。

應用網絡功能

我認為，無論您喜歡哪種服務體系結構（微服務，SOA，對象請求代理，客戶端/服務器等），這些觀點都是有效的–但是，在過去，我們模糊了關于優化屬于何處的界限。 在我看來，有水平的應用程序網絡功能是公平的游戲，可以優化我們的應用程序（并放入基礎架構中，就像我們在較低級別的堆棧中所做的一樣），還有其他一些與我們的業務更緊密相關不應輕易“優化”的邏輯 。

網絡

讓我們快速退后一步，了解我們的應用程序下面的網絡是什么樣的（非?，嵥楹透呒?#xff1a;）。 當我們從一項服務向另一項服務發送“消息”時，我們將其傳遞到操作系統的網絡堆棧，然后該網絡堆棧將弄清楚如何將其放入網絡。 網絡根據級別來處理傳輸單元 （幀，數據報，數據包）等。這些傳輸單元通常由一個結構組成，該結構包括一個“標頭”和一個“有效載荷”，而“標頭”包含有關該標頭的足夠元數據。我們可以做一些基本的事情，例如路由，確認跟蹤/去重復等。

這些傳輸單元是通過網絡中的不同點發送的，這些點決定是否允許該單元通過，是否將其路由到其他網絡或將其傳遞給預期的接收者。 這些傳輸單元可以在路徑上的任何位置被丟棄，復制，重新排序或延遲。 我們的操作系統的網絡堆棧中存在TCP等更高級別的“可靠性”功能，可以跟蹤重復，確認，超時，排序，丟失單元等情況，并可以重試故障，重新排序數據包等。

這些功能類型是由基礎結構提供的，并且沒有與業務邏輯混合使用-并且可以很好地擴展（Internet規模！）。我剛剛遇到了Phil Calcado的精彩博客，也對此做了很好的解釋 。

應用

在應用程序級別，我們做類似的事情。 我們將與合作者服務的對話分成“消息”（請求，事件等）的傳輸單元 。 當我們通過網絡撥打電話時，我們必須能夠對應用程序消息執行超時，重試，確認，施加反壓等操作。 這些是普遍的應用程序級問題，并且在我們構建服務風格的體系結構時總是會出現。 我們需要以某種方式解決它們。 我們需要一種實現應用程序網絡功能的方法。

例如：過去，我們嘗試使用消息傳遞代理解決這些問題。 我們有一套集中的，面向消息傳遞的中間件（甚至可能具有多協議支持，因此我們可以轉換消息有效負載并“集成”客戶端），這些中間件負責在客戶端之間傳遞消息。 在我看到的許多示例中，該模式基本上是在消息傳遞系統上執行請求/答復（RPC）。

這默認地幫助解決了圍繞應用程序網絡功能的一些問題：諸如負載平衡，服務發現，背壓，重試等之類的事情都委托給了消息傳遞代理。 由于所有流量都打算通過這些代理流動，因此我們有一個中心點可以從中觀察和控制網絡流量。 但是，正如@tef_ebooks在Twitter上指出的那樣，這種方法相當繁瑣 。 它也往往是體系結構中的一個大瓶頸，并且在交通控制，路由，策略執行等方面并沒有我們想象的那么容易。

因此，我們也嘗試這樣做。 我們認為“好吧，讓我們只添加路由，轉換，策略控制”到我們已經擁有的集中式消息總線中。 實際上，這是自然發展的過程–我們可以使用消息傳遞主干來提供集中化/控制和應用程序網絡功能，例如服務發現，負載平衡，重試等–但是，我們還將在更多事情上分層，例如協議中介，消息轉換，消息路由，業務流程等。我們認為，如果我們可以將這些看似水平的東西推入基礎架構，我們的應用程序可能會更輕/更薄/更敏捷等。這些擔憂確實是ESB真正發展起來的，可以幫助解決這些問題。

正如我的同事Wolfram Richter指出的那樣：“關于ESB概念，IBM 2005年關于SOA體系結構的白皮書（ http://signallake.com/innovation/soaNov05.pdf第2.3.1章 ）將ESB定義如下：”

The enterprise service bus (ESB) is a silent partner in the SOA logical architecture. Its presence in the architecture is transparent to the services of your SOA application. However, the presence of an ESB is fundamental to simplifying the task of invoking services – making the use of services wherever they are needed, independent of the details of locating those services and transporting service requests across the network to invoke those services wherever they reside within your enterprise.

似乎是合法的！ 甚至似乎是我們正在嘗試的新興技術中要做的一些事情。 你知道嗎？ 我們是！！！ 過去的問題不僅已經神奇地消失了 ，而且背景和環境也發生了變化。 希望我們能夠從過去的未兌現承諾中學習。

例如，在大型供應商所設想的SOA時代（通過委員會等編寫了無休止的規范，對EAI進行了品牌重塑等），我們發現三件事促成了“ ESB”的未兌現承諾：

• 組織結構（讓我們再建一個筒倉！）
• 技術很復雜（SOAP / WS-*，JBI，Canonical XML，專有格式等）
• 需要業務邏輯來實現路由，轉換，中介，編排等操作

最后一點是什么過分的事情。 我們希望敏捷，但是我們將重要的業務邏輯從我們的服務中分散到另一個團隊擁有的集成層中。 現在，當我們想對我們的服務進行更改（敏捷）時，我們就可以了。 我們必須停止并與ESB團隊進行重大同步（脆弱）。 隨著這個團隊和這個體系結構成為許多應用程序的中心，我們可以了解ESB團隊是如何被請求（敏捷）所淹沒，但卻無法跟上（脆弱）的。 因此，盡管用意良好，但我們發現將核心應用程序網絡功能與與業務邏輯相關性更高的功能混合在一起并不是一個好主意。 我們最終會出現膨脹和瓶頸。

隨之而來的是REST革命和基于API的思維方式。 這一運動在某種程度上是對SOAP / ESB / SOA復雜性的抵制，再加上一種新的思考方式（通過API）將我們的數據內翻以激發新的業務模型并擴展現有模型。 我們還為我們的體系結構引入了新的基礎架構：API管理網關。 該網關為我們提供了集中式控制方式，以通過安全ACL，訪問配額和API使用計劃，指標收集，計費，文檔編制等來控制外部對我們業務API的訪問。但是，就像我們在前面的示例中看到的消息代理一樣，當我們進行某種集中式治理時，我們冒著想要用它完成太多事情的風險。 例如，當API調用通過我們的網關進行時，為什么不添加路由，轉換和編排之類的內容呢？ 問題在于，我們開始著手構建將基礎架構級別的網絡問題與業務邏輯相結合的ESB。 這是一個死胡同。

但是，即使在REST /非SOAP時代，我們仍然必須解決服務之間的上述問題（不僅僅是所謂的“南北”流量，我們還需要解決“東西向”流量）互動）。 更具挑戰性的是，我們需要找出一種使用商品基礎架構環境（又名云）的方法，這種環境會加劇這些問題。 傳統的消息代理，ESB等不太適合此模型。 相反，我們最終在業務邏輯中編寫了應用程序網絡功能。 …我們開始看到諸如Netflix OSS堆棧 ， Twitter Finagle甚至我們自己的Fuse Fabric之類的東西可以解決這些問題。 這些通常是旨在解決上述某些問題的庫或框架，但是它們是特定于語言的，并與我們的業務邏輯（或我們遍布整個基礎架構的業務邏輯）混合在一起。 該模型也存在問題。 這種方法需要在每種語言/框架/運行時上進行大量投資。 我們基本上必須跨語言/框架重復工作，并期望所有不同的實現都能高效，正確且一致地工作。

通過這些試驗和磨難，我們可以將應用程序網絡功能以最低的開銷和高度分散的功能推入基礎架構，并具有控制/配置/監視應用程序級請求的能力，從而解決了一些較早的問題。 我們一直稱其為“服務網格”。 一個很好的例子是基于Envoy Proxy的istio.io項目。 這使我們在架構上將應用程序網絡功能的關注點與側重于區分業務邏輯的關注點分開：

正如Phil Calcado解釋的那樣 ，這與我們對TCP / IP網絡層所做的非常相似。 網絡功能被推出到操作系統中，并且不直接屬于應用程序。

那么這與…有什么關系？

通過服務網格，我們將應用程序網絡功能與應用程序代碼，業務邏輯明確分離，并將其向下推入一層（進入基礎結構），這與我們對網絡堆棧，TCP等所做的操作類似）。

有問題的網絡功能包括：

• 簡單的基于元數據的路由
• 自適應/客戶端負載平衡
• 服務發現
• 斷路
• 超時/重試/預算
• 限速
• 指標/記錄/跟蹤
• 故障注入
• A / B測試/流量調整/請求屏蔽

明確不包含的內容（更適合您的業務邏輯/應用程序/服務，而不是某些集中式基礎結構）：

• 信息轉換
• 消息路由（基于內容的路由）
• 服務編排

那么，服務網格與…有何不同？

ESB

• 某些網絡功能重疊
• 分散的控制點
• 特定于應用程序的策略
• 不嘗試處理業務邏輯問題（映射，轉換，基于內容的路由等）

消息經紀人

• 服務發現，負載平衡，重試，背壓方面的重疊（從30,000英尺高度開始）
• 分散的控制點
• 特定于應用程序的策略
• 對消息不承擔任何責任

API管理

• 在策略控制，速率限制，ACL，配額安全性的某些方面存在重疊
• 不處理API的業務方面（定價，文檔，用戶到計劃的映射等）
• 相似之處在于它不執行業務邏輯

關于API管理，似乎確實有些重疊，但是我想將這些東西視為高度互補。 API管理提供有關API的高級語義（例如文檔，用戶注冊/訪問，生命周期管理，針對開發人員的API計劃，用于計費和退款的計量等）。 調用API時，低級應用程序網絡（如斷路器，超時，重試等）至關重要，但它們非常適合服務網格層。 重疊點，例如ACL，速率限制，配額和策略實施等，可以由API管理層定義，但實際上由服務網格層實施。 這樣，我們可以擁有完整的端到端策略和訪問控制，并可以增強對北/南流量和東/西流量的彈性。 正如@ZackButcher （來自Istio團隊） 在Twitter上指出的那樣： “隨著您的規模越來越大，從生產和管理服務的角度來看，東西向的流量開始越來越像南北向?！?

匯集全部

點擊查看完整圖片

我們需要對我們的系統架構采用API優先的方法。 我們還必須解決諸如彈性之類的問題。 我們還發現我們面臨整合挑戰。 并且在許多方面，基于異步事件傳遞和事件處理作為API和微服務交互的底板的體系結構可以幫助提高可用性，彈性和降低脆弱性。 過去，解決這些問題一直是充滿挑戰的產品，因為競爭產品和解決方案重疊并混淆了關注點-當我們遷移到云架構時，很明顯，我們需要梳理這些關注點并將它們放在我們架構的適當位置，否則我們將會屈從于一些相同的經驗教訓。

從上圖中，我們可以看到以下幾點：

• 北向/南向交通的API管理
• 服務網格（控制+數據平面），用于服務之間的應用程序網絡功能
• 用于東西方流量的Service Mesh強制API管理策略
• 集成（業務流程，轉換，反腐敗層）作為應用程序的一部分
• 事件驅動的消息背板可實現真正的異步/事件驅動的交互

如果我們不聽前面提出的四個假設，那么我們將努力解決這些問題：

• 第一點：服務通過網絡進行交互–我們使用服務網格數據平面/服務代理
• 第二點：交互是不平凡的–在服務本身中實現業務集成
• 第三點：控制和可觀察性–使用API??管理+服務網格控制平面
• 第四點：您的特定業務邏輯； 使用服務網格/消息傳遞/等進行優化

您真的可以分離出業務邏輯嗎？

我想是的。 但是，會有模糊的線條。 在服務網格中，我們是說我們的應用程序應了解應用程序網絡功能，但不應在應用程序代碼中實現。 關于使應用程序更智能，應用程序網絡功能/服務網格層到底在做什么，有很多話要說。 我想我們會在這種情況下看到庫/框架。 例如，如果Istio服務網格引發斷路器，重試某些請求或由于特定原因而失敗，那么對于應用程序而言，可以更好地了解這些情況或上下文將是很好的。 我們需要一種方法來捕獲此錯誤并將其傳達回服務。 另一個示例是在服務之間傳播跟蹤上下文（類似于OpenTracing的分布式跟蹤），并透明地完成此操作。 我們可能會看到這些專用于應用程序/語言的精簡庫，這些庫可以使應用程序/服務更智能，并允許他們采用特定于錯誤的資源。

我們從這里去哪里

今天，該體系結構的各個部分處于不同的成熟度級別。 即使如此，對我們的服務體系結構采取有原則的方法也是關鍵。 將業務邏輯與應用程序網絡分開。 使用服務網格來實現應用程序網絡，使用API??管理層來處理以更高階的API為中心的問題，特定于業務的集成駐留在服務層中，并且我們可以通過事件驅動的背板構建數據密集型/可用系統。 我認為，隨著我們的前進，我們將繼續在特定的技術實現中看到這些原則的發展。 在紅帽（我工作的地方），我們看到這樣的技術3比例 ， Istio.io上Kubernetes ， Apache的駱駝和消息傳遞技術，如ActiveMQ的阿蒂米斯 / Apache的Qpid調度路由器 （包括非紅帽的技術，如Apache的卡夫卡恕我直言）強積木建立遵循這些原則的服務架構。

翻譯自: https://www.javacodegeeks.com/2017/08/application-network-functions-esbs-api-management-now-service-mesh.html

api網關和esb區別

總結

以上是生活随笔為你收集整理的api网关和esb区别_具有ESB，API管理和Now .. Service Mesh的应用程序网络功能。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。