Różnice między bramkami API a ESB? [Zamknięte]

20

Firma, dla której pracuję, ocenia niektóre rozwiązania oprogramowania pośredniego w zakresie zarządzania, pomiaru i bezpieczeństwa usług internetowych. Obecnie używamy do tego celu Enterprise Service Bus (ESB), ale niektórzy fajni koledzy z zarządzania postanowili wdrożyć oprogramowanie pośrednie do zarządzania API.

Zagłębiłem się trochę w te rozwiązania API Management (czyli API Gateway), ale nie mogłem znaleźć różnicy między nimi a rzeczywistymi ESB. Oceniłem kilka oficjalnych dokumentów z Mule, WSO2, Oracle itp., Ale funkcje oferowane przez oba produkty wydają się prawie takie same. Pytanie brzmi: co może zrobić API Management, czego nie może zrobić ESB i odwrotnie? Jaką wartość można dodać do infrastruktury IT, zastępując ESB bramą API?

integration middleware dliber
źródło
4
W jaki sposób pytanie „Jaka jest różnica między bramką API a ESB” jest poza tematem dyskusji inżynierii oprogramowania?
Francisco d'Anconia

Odpowiedzi:

21

Powodem, dla którego pogmatwane są te koncepcje, jest to, że dostawcy sprzedają je w pakiecie. Ale są to zdecydowanie odrębne koncepcje.

API Gateway zapewnia centralny punkt dostępu do zarządzania, monitorowania i zabezpieczania dostępu do publicznie ujawnionych usług internetowych. Umożliwiłoby to również konsolidację usług na różnych punktach końcowych, tak jakby wszystkie pochodziły z jednego hosta. Załóżmy na przykład, że masz dziesięć różnych punktów końcowych usług, które wszystkie są częścią jednego „zestawu” usług. Zamiast informować konsumentów o Twojej usłudze, aby korzystali z service1.twojafirma.com dla jednej usługi i service2.twojafirma.com dla innej i tak dalej, możesz zamiast tego poprosić ich o wskazanie api.twojafirma.com/service1 lub api.twojafirma.com / service2, a brama byłaby odpowiedzialna za przekierowanie żądań do odpowiednich punktów końcowych.

ESB to wewnętrzna „magistrala”, która umożliwia aplikacjom i usługom komunikowanie się ze sobą w niepowiązany sposób. Wszystkie aplikacje mogą podłączyć się do magistrali i mogą otrzymywać dowolne wiadomości, które ich interesują, gdy zostaną opublikowane przez inną aplikację. Mogą także publikować własne wiadomości, na które inna aplikacja może nasłuchiwać i odpowiadać na nie. Aplikacje nie są odpowiedzialne za bezpośrednie łączenie się ze sobą, publikują swoje wiadomości w autobusie, a wszystkie zainteresowane strony słuchają i reagują.

Logicznie brama API nie zastępuje ESB, ale raczej ulepszenie architektury zorientowanej na usługi.

Michael Brown
źródło
1
Uważam, że argument za wykorzystaniem ESB jest taki sam. ESB są centralnymi punktami dostępu i mogą wykonywać równoważenie obciążenia, monitorowanie, pomiar i bezpieczeństwo usług z różnych punktów końcowych. Możesz również przekazać adres URL ESB konsumentom zamiast adresu URL poszczególnych usług. Jak dotąd nic nowego.
dliber
ESB jest wewnętrzną bramą API przeznaczoną do użytku zewnętrznego. Jeśli chcesz używać API Gateway wewnętrznie zamiast ESB, myślę, że nic Cię nie powstrzyma.
Michael Brown,
Właśnie o to chodzi. Funkcje ESB i platform API pokrywają się. Możesz wdrożyć ESB dla dostępu zewnętrznego lub platformę API dla dostępu wewnętrznego. Jeśli ich funkcje są takie same, jaka jest korzyść z używania jednej zamiast drugiej? Co sprawia, że ​​są tak różne, że możesz używać jednego zamiast drugiego (lub obu razem) i dostarczać prawdziwej wartości swojej firmie?
dliber
Jedna rzecz, którą ESB zaprojektowano dla ruchu o dużym natężeniu ruchu. Zwykle ma zastrzeżony lub nieprzyjazny dla Internetu protokół. Interfejs API Gateway służy do tłumaczenia protokołów internetowych (SOAP, JSON, XML, HL7) i umieszczania żądań w ESB. Zasadniczo, MOŻESZ wykorzystać bramę do komunikacji między swoimi usługami wewnętrznymi, co niekoniecznie czyni ją najlepiej dopasowaną.
Michael Brown,