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?


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.


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,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.