Различия между шлюзами API и ESB? [закрыто]

20

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

Я немного исследовал эти решения по управлению API (иначе говоря, API Gateway), но не смог найти разницу между ними и реальными ESB. Я оценил некоторые технические документы от Mule, WSO2, Oracle и т. Д., Но функции, предлагаемые обоими продуктами, кажутся почти одинаковыми. Вопрос в том, что может сделать управление API, чего не может ESB, и наоборот? Какую ценность можно добавить в ИТ-инфраструктуру, заменив ESB на шлюз API?

integration middleware dliber
источник
4
Как вопрос «В чем разница между шлюзом API и ESB» не входит в тему обсуждения программной инженерии?
Франциско д'Анкония

Ответы:

21

Причина, по которой вы путаете понятия, заключается в том, что продавцы продают их в упаковке. Но это определенно отдельные понятия.

Шлюз API предоставляет центральную точку доступа для управления, мониторинга и защиты доступа к вашим публично доступным веб-службам. Это также позволит вам консолидировать сервисы на разных конечных точках, как если бы они все приходили с одного хоста. Например, допустим, у вас было десять различных конечных точек служб, которые были частью одного «набора» служб. Вместо того, чтобы информировать потребителей вашего сервиса об использовании service1.yourcompany.com для одного сервиса и service2.yourcompany.com для другого и т. Д., Вместо этого вы можете попросить их указать на api.yourcompany.com/service1 или api.yourcompany.com. / service2 и шлюз будут отвечать за перенаправление запросов на соответствующие конечные точки.

ESB - это внутренняя «шина», которая позволяет приложениям и сервисам обмениваться данными друг с другом. Все приложения могут подключиться к шине, и они могут получить любое интересующее их сообщение при публикации другим приложением. Они также могут публиковать свои собственные сообщения, которые другое приложение может прослушивать и отвечать на них. Приложения не несут ответственности за прямое соединение друг с другом, они публикуют свои сообщения в шине, и все заинтересованные стороны слушают и реагируют.

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

Майкл Браун
источник
1
Я считаю, что аргумент в пользу использования ESB такой же. ESB являются центральными точками доступа и могут выполнять балансировку нагрузки, мониторинг, измерение и безопасность служб с разных конечных точек. Вы также можете передать URL-адрес ESB потребителям вместо URL-адресов отдельных служб. Пока что ничего нового.
Делибер
ESB - это внутренний API-шлюз, предназначенный для внешнего потребления. Если вы хотите использовать API-шлюз для внутреннего использования вместо ESB, я думаю, вам ничто не помешает.
Майкл Браун
В том-то и дело. Существует частичное совпадение функций ESB и платформ API. Вы можете развернуть ESB для внешнего доступа или платформу API для внутреннего доступа. Если их функции одинаковы, какая польза от использования одного вместо другого? Что делает их такими разными, чтобы вы могли использовать одно вместо другого (или оба вместе) и приносить реальную пользу вашему бизнесу?
Dliber
Одна вещь ESB разработан для большого объема трафика. У него обычно есть проприетарный или не дружественный к Интернету протокол. Шлюз API предназначен для преобразования между интернет-протоколами (SOAP, JSON, XML, HL7) и размещения запросов в ESB. По сути, вы МОЖЕТЕ использовать шлюз для связи между вашими внутренними сервисами, что не обязательно делает его наиболее подходящим.
Майкл Браун