Відмінності між шлюзами API та ESB? [зачинено]

Зачинено. Це питання поза темою . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб це було темою для обміну стеками програмного забезпечення.

Закрито 5 років тому .

Компанія, над якою працюю, оцінює деякі рішення проміжного програмного забезпечення для управління, обліку та безпеки веб-служб. В даний час ми використовуємо для цієї мети Enterprise Service Bus (ESB), але деякі круті хлопці з менеджменту вирішили, що збираються розгорнути деяке програмне забезпечення для управління API.

Я трохи дослідив ці рішення щодо управління API (він же API Gateway), але не зміг знайти різницю між ними та фактичними ESB. Я оцінив деякі доповіді від Mule, WSO2, Oracle тощо, але функції, які пропонуються обома продуктами, здаються майже однаковими. Питання полягає в тому, що може зробити API управління, що не може зробити ESB, і навпаки? Яку цінність можна додати до ІТ-інфраструктури, замінивши ESB на шлюз API?

integration middleware

— длібер
джерело

Як питання "Яка різниця між шлюзом API та ESB" поза темою для обговорення програмної інженерії?

— Франциско д'Анконія

Причина, по якій ви заплутувались, полягає в тому, що продавці продають їх у пакеті. Але це, безумовно, окремі поняття.

Шлюз API забезпечує центральну точку доступу для управління, моніторингу та забезпечення доступу до ваших веб-служб, відкритих для громадськості. Це також дозволить вам консолідувати послуги за різними кінцевими точками так, ніби всі вони надходять від одного хоста. Наприклад, скажімо, у вас було десять різних кінцевих точок обслуговування, які були частиною єдиного "набору" послуг. Замість того, щоб сповіщати споживачів вашої послуги про використання service1.yourcompany.com для однієї послуги та service2.yourcompany.com для іншої тощо, ви можете замість того, щоб усі вони вказували на api.yourcompany.com/service1 або api.yourcompany.com / service2 і шлюз будуть нести відповідальність за перенаправлення запитів до відповідних кінцевих точок.

ESB - це внутрішня "шина", яка дозволяє програмам та службам спілкуватися один з одним безперервно. Усі програми можуть підключитися до шини, і вони можуть отримувати будь-яке повідомлення, яке їх цікавить, коли їх публікує інша програма. Вони також можуть публікувати власні повідомлення, на які може прослуховувати та відповідати інша програма. Програми не несуть відповідальності за з'єднання один з одним безпосередньо, вони публікують свої повідомлення в автобусі і всі зацікавлені сторони слухають та реагують.

Логічно шлюз API - це не заміна ESB, а вдосконалення для сервісно орієнтованої архітектури.

— Майкл Браун
джерело

Я вважаю, що аргумент щодо використання ESB є однаковим. ESB є центральними точками доступу і можуть виконувати балансування навантаження, моніторинг, облік та безпеку послуг з різних кінцевих точок. Ви також можете передавати URL-адресу ESB споживачам замість URL-адреси окремих послуг. Поки нічого нового.

— лютого

ESB - це внутрішній шлюз API, призначений для зовнішнього споживання. Якщо ви хочете використовувати внутрішній шлюз API замість ESB, я думаю, що вас ніщо не зупинить.

— Майкл Браун

Саме в цьому і полягає. Існує перекриття особливостей ESB та платформ API. Ви можете розгорнути ESB для зовнішнього доступу або платформу API для внутрішнього доступу. Якщо їх особливості однакові, яка користь від використання одного замість іншого? Що робить їх настільки різними, щоб ви могли використовувати одне замість іншого (або обидва разом) та надавати реальну цінність для свого бізнесу?

— делібер

Одна справа, що ESB розроблений для великого обсягу руху. Зазвичай у ньому є власницький або не-Інтернет-протокол. Шлюз API призначений для перекладу між протоколами Internet (SOAP, JSON, XML, HL7) та розміщення запитів на ESB. В основному ви можете використовувати шлюз для зв'язку між внутрішніми службами, що не обов'язково робить його найкращим чином.

— Майкл Браун