SQL注入攻擊深度解析與防護策略
ESB 的設計模仿了計算機硬件架構中的硬件總線，充當多個外圍設備之間的通信橋梁。從長遠來看，ESB 充當服務之間穩定的通信總線。它不是一個標準或有形產品，而是一種架構和通信模式。它提供了一個概念藍圖，其中包含一組通過確保充分解耦來在代表業務服務的軟件組件之間進行編排和調解的指南。
ESB 被設想為 SOA 的內部組件。因此對于最終用戶來說，它是一個看不見的黑匣子。與 ESB 交互的唯一角色是應用程序開發人員和 IT 工程師。
應用程序開發人員負責定義他們開發的服務的接口。這些接口成為其他服務通過 ESB 與它們通信的服務訪問點。 IT 工程師負責部署、維護和監控 ESB 基礎設施，以確保其附帶的服務數量不斷增加時達到最佳性能。
如果您查看一家擁有少量服務和應用程序的小公司的 IT 部署，那么客戶端-服務器或點對點通信模型就可以滿足您的需要。然而，在大型企業中，事情變得太復雜太快了。在這種情況下，ESB 的優點在處理與以下相關的復雜性時脫穎而出：
在兩個或多個應用程序之間提供無縫通信的挑戰并不新鮮。多年來，人們提出了許多標準，并建立了專有應用程序和協議。 ESB 的發展與基于 SOA 的企業應用程序部署趨勢相一致，這種趨勢幾乎可以追溯到萬維網誕生之初。因此它早于當前的云時代技術。
盡管 EBS 可能被認為已經過時，但它仍然與 IT 集成和數字化轉型相關。然而，隨著新一代技術的出現，有必要進行比較以闡明 ESB 的優點和局限性。
ESB 與服務網格– 服務網格與微服務架構 (MSA) 的當前趨勢更相關，微服務架構使用容器通過云原生技術定義更細粒度的服務編排。在較高層面上，ESB 實現了與服務網格相同的功能。然而，它主要是作為一組整體的應用程序組件構建的。在過去幾年中，出現了利用云的混合部署模型。因此，ESB 和服務網格之間的界限現在變得模糊。
ESB 與集成平臺即服務 (iPaaS) ：iPaaS 是一套云服務，支持集成流程的開發、執行和治理，將本地和基于云的流程、服務、應用程序和數據的任意組合連接起來或跨多個組織。它是一個用于在云內以及云與企業之間構建和部署集成的平臺。從功能上講，ESB 和 iPaaS 提供相同的解決方案。與整體 ESB 相比，iPaaS 成本更低且擴展更靈活。在某些情況下，ESB 是首選，例如支持傳統的、流程繁重的軟件系統，這些系統支撐敏感公司數據的安全管理。
ESB 與 Pub/Sub ：Pub/Sub 是一個通用概念。它是一種抽象通信模式，用于構建需要解耦消息中間件的互聯網規模應用程序。它可以被視為 ESB 的子系統，因為 ESB 還需要服務之間的解耦消息傳遞層。然而，與 ESB 不同，Pub/Sub 是一個理論概念。
ESB 與 Apache Kafka – Apache Kafka 是一個真正的產品。它最初是在 Linkedin 內構思的，由于其大規模處理系統間消息傳遞的獨特方式，在過去十年中獲得了巨大的受歡迎。您可以將 Apache Kafka 視為抽象 Pub/Sub 模式的現實實現。與 ESB 相比，Apache Kafka 的職責范圍較小，僅限于消息交換。
ESB 與 ETL ：ETL（提取、轉換、加載）是一種數據管道，主要用作機器學習模型執行的數據預處理階段的一部分。 它主要是一個線性過程，其中數據從一側饋送并從另一側檢索。因此，它是與 ESB 完全不同的概念。
由于缺乏標準化，ESB 沒有統一的架構。不同的供應商有自己的方法將 ESB 系統劃分為其子系統。因此，將一組標準組件組合在一起以呈現跨供應商的一致架構并不容易。
考慮到 SOA 支持者設想的功能，以下是 ESB 的關鍵組件。
作為老一代技術的一部分，ESB 的作用很大程度上已被更新的架構框架所取代。然而，遺留應用程序運行在 SOA 模型上，ESB 仍然可以很好地發揮作用。只要這些應用程序不進行技術更新，ESB 就會發揮關鍵作用。
雖然可以公平地說，ESB 將在未來幾年內走向衰落，但它在塑造分布式計算的新架構模型方面的影響不容忽視。作為 ESB 的一部分提出的用于處理服務間通信的概念和機制在當前的云時代仍然有效。因此，可以說，當前這一代概念，如Service Mesh、iPaaS，是站在ESB這個巨人的肩膀上。
原文鏈接：https://rapidapi.com/blog/enterprise-service-bus/
