Micro Service z API Gateway

Question

W przypadku mojego nowego projektu muszę korzystać z usług Mikro usług z bramką Api. Zebrałem więc szczegółowe informacje na temat Micro Service, ale część Api Gateway nie jest jasna.

Moje pytanie brzmi,

1. Czy ktoś wie o tym, jak wniosek o routingu część odbywa się w Api Gateway?
2. , że można to zrobić poprzez proste, jeśli warunek [kod pseudo: jeśli (słowo kluczowe == "produkt"), następnie trasa ("Usługa produkt")]?
3. A może to lepszy sposób?

Używam C# .Net do opracowania Api.
Mam pewne informacje o Api Brama z https://www.nginx.com/blog/building-microservices-using-an-api-gateway/

Answer 1

dość dużo zadawane trzy pytania, a oni wszystko nieco podobne więc postaram mojej mocy, aby rozwiązać wszystkie trzy razem.

Po pierwsze, żądanie routingu w bramie API jest czymś więcej niż tylko proxy, a implementacja nie będzie wymagać warunków sprawdzenia żądania przed wysłaniem go do usługi niższego rzędu. Bramka API prawdopodobnie byłaby jedynym punktem dostępu do twoich usług, w którym uwierzytelnianie będzie również obsługiwane na warstwie, aby zapewnić, że żądanie ma pozwolenie na przejście do usługi niższego rzędu. Uwierzytelnienie może być inną usługą. Wysokopoziomowa implementacja bramki API prawdopodobnie skonsoliduje większość, jeśli nie wszystkie, punktów końcowych we wszystkich usługach końcowych.

Weźmy mały przykład, taki jak aplikacja e-commerce, która zawiera usługę do wystawiania produktów na aukcję, wyszukiwania produktów i koszy na zakupy. Bramka API będzie również miała te same punkty końcowe i przekaże żądanie dalej do usługi odpowiedzialnej za żądanie. Interfejs API w tym przykładzie może mieć /products, aby wymienić wszystkie produkty, /products?query=..., aby wyszukać produkty, a na końcu /carts/:id/products, aby wyświetlić listę produktów w koszyku. Mam nadzieję, że to odpowiada na twoje pytanie. Poza tym, wiem, że wspomniałeś o tym, że jest to nowy projekt i chciałeś dać ci 2 centy, że nie jest to najlepsza architektura do wykorzystania w nowym projekcie, jeśli twój zespół jest naprawdę mały, ponieważ istnieje duży koszt operacyjny. Obciążenie wymagające standaryzacji, automatyzacji wdrożeń, integracji itd. Najprawdopodobniej najlepiej zacząć od tradycyjnej architektury MVC i powoli ewoluować do mikrousług, gdy projekt zostanie uruchomiony.

Answer 2

W zależności od architektury można użyć naprawdę fajnego oprogramowania, takiego jak Weave with CoreOS (https://github.com/weaveworks/weave). Używamy Dockera do dystrybucji naszych aplikacji na węzły CoreOS, a następnie wewnętrzny DNS jest obsługiwany przez Weave.

To jest naprawdę świetne, ponieważ możemy po prostu przekazać żądanie do nazwy aplikacji z portem, a następnie jesteśmy wyłączeni.

Na przykład, użytkownik zażąda application.com/api/apiName/request/path

Nasza brama został zrealizowany przy węźle.js i przeniesienie apiName after/api do tego api, a następnie następująca ścieżka adresu URL do dołączenia do samego wywołania.

Żądanie z bramy będzie wewnętrznie proxy, tak jak apiName: 8080/request/path. W tym względzie interfejs API nie wymaga żadnych zmian w przypadku pojawienia się nowych usług, ponieważ ścieżka jest tworzona dynamicznie z żądania.

To jest świetne, ponieważ nie musimy się martwić o śledzenie ścieżek z różnych API i przechowywanie ich gdzieś.

Jeśli nie, musisz zachować pewną (prawdopodobnie zewnętrzną) listę punktów końcowych, aby ułatwić sobie pracę. Można to zrobić programowo z samych API.

Nie jestem pewien, jakie są Twoje wymagania, a ponieważ Will udzielił odpowiedzi, wiąże się to z dużym kosztem infrastruktury. Jednak nasze wersje są szybkie i bezbolesne, ponieważ nie musimy się martwić o wprowadzanie zmian w kodzie w wielu warstwach, a nowe interfejsy API pobierają za darmo nasze proxy, logowanie i uwierzytelnianie bramy.