В чем разница между API Gateway и ESB?

ESB является традиционным промежуточным программным обеспечением, используемым в SOA-решениях для маршрутизации, преобразования сообщений, моста протоколов, между прочим. Ряд поставщиков предлагают новую категорию промежуточных решений под названием API Gateway. Эти решения обычно описываются как центральная точка доступа к службам REST и SOAP, предлагаемым публично организацией. Однако решения API Gateway, похоже, предлагают подмножество типичных функций ESB.

Итак, каковы различия между ESB и API Gateway? Когда следует использовать один или другой?

Ответ 1

Шлюз API - это то, что обычно действует как прокси для ваших веб-сервисов и обеспечивает интересную ценность, например: протоколирование, предоставление SOAP-сервисов, вызываемых как службы REST, отладочная справка, отслеживание и т.д.... Поскольку шлюз API сидя между потребителем и вашими услугами, он может легко захватывать трафик и делать такие вещи.

Корпоративная служебная шина (например, nServiceBus) предназначена для работы поверх протокола обмена сообщениями (например, RabbitMQ), чтобы предоставить ему функциональность, которая не входит (или функциональность, которую трудно реализовать), основной обмен сообщениями или pub-sub, например: база данных хранимых долговечных сообщений, логика повтора, инкапсуляция слушателя, более простые способы подписки на сообщения и саги. Вы можете использовать протокол обмена сообщениями, не используя ESB, но не наоборот. Например, вы можете использовать RabbitMQ без использования nServiceBus.

Ответ 2

Поскольку оба шлюза API и ESB способны обслуживать прокси-службы, если рассматривать только средства посредничества и преобразования этих двух инструментов, они могут казаться идентичными. Ключевое различие в шлюзе API для меня заключается в конкретной цели, для которой он предназначен. Шлюз API должен иметь возможность выступать в качестве точки входа в ресурсы, выходящие из него, помимо предоставления преобразований и некоторых возможностей маршрутизации. Кроме того, они должны иметь возможность делегировать аспекты контроля доступа и дросселирования другим специализированным компонентам, используя их, чтобы они могли гарантировать желаемое поведение. Поскольку шлюз API будет включен в состав решения по управлению API, все эти возможности будут поддерживаться OOTB.

Возможно, будет достигнуто подобное поведение для служебных прокси, используя ESB и другие внешние компоненты или программное обеспечение. Тем не менее, поскольку ESB предназначены для удовлетворения более широкого набора требований к интеграции и не являются специализированными для использования в управлении API, их выполнение будет намного сложнее.

Ответ 3

Шлюз API - это прокси, предоставленный для клиента. Шлюз предоставляет клиенту согласованный интерфейс независимо от каких-либо изменений во внутренней системе. Это позволяет внутренней системе меняться, не влияя на клиента. API-шлюз может также обеспечивать согласованные сквозные задачи, такие как ведение журнала безопасности, создание отчетов и аналитика API.

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

Вариантов и деталей реализации очень много, но это принципиальное отличие.