Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / API Gateway w prostych słowach: routing, bezpieczeństwo i ograniczanie ruchu dla mikrousług – czy go potrzebujesz? (Dubbing AI)

Transcript

API Gateway w prostych słowach: routing, bezpieczeństwo i ograniczanie ruchu dla mikrousług – czy go potrzebujesz? (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Gotowi na 10 dni z Microsoft 365, Copilot, iAzure oraz ludźmi kształtującymi przyszłość pracy?
• 0:07
  W styczniu wraca M365Con i tym razem działamy z większym rozmachem.
• 0:12
  Dołącz do nas na sesję na żywo, praktyczne dema i wiedzę od MVP oraz ekspertów z całego świata,
• 0:18
  bez ogólnych slajdów i bez kończących się modnych haseł.
• 0:22
  Zmierzamy się z prawdziwymi wyzwaniami, Copilot Studio, agentami, iFabrik, bezpieczeństwem, ładem i automatyzacją.
• 0:28
  Niezależnie od tego, czy jesteś informatykiem, programistą czy liderem biznesowym, przygotowaliśmy sesję dla Ciebie.
• 0:35
  Podczas 10 pełnych dni odkryjesz wiele technologii i połączysz się z globalną społecznością.
• 0:40
  Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji.
• 0:44
  Styczeń 2027 roku, 10 dni, jedna społeczność Microsoft. Rejestracja jest już otwarta.
• 0:51
  Wejdź na m365con.net i zarezerwuj miejsce już dziś.
• 0:56
  To m365con.net.
• 0:58
  Dołącz teraz na m365con.net.
• 1:03
  Widzimy się na żywo w styczniu.
• 1:05
  Stworzyłeś działającą aplikację, dodajesz kolejną usługę i następną, a zarządzanie ruchem między nimi staje się koszmarem.
• 1:11
  Czym więc dokładnie jest API Gateway i czy w ogóle go potrzebujesz?
• 1:14
  Pod koniec tego odcinka zrozumiesz, co robi API Gateway, dlaczego rozwiązuje chaos zarządzania wieloma usługami i jak sprawdzić, czy jest Ci potrzebny.
• 1:22
  Zacznijmy od problemu, potem przejdziemy do elementów i tego, jak do siebie pasują.
• 1:26
  Problem? Zbyt wiele drzwi.
• 1:29
  Wyobraź sobie, że prowadzisz firmę, która szybko rośnie.
• 1:32
  Masz zespół sprzedaży na trzecim piętrze, księgowość w piwnicy i dział IT w tylnym skrzydle.
• 1:37
  Teraz wyobraź sobie, że każdy z tych działów ma własne wejście, własny numer telefonu i własnego ochroniarza, który nie rozmawia z innymi.
• 1:43
  Jeśli jesteś gościem i chcesz zostawić przesyłkę, powodzenia.
• 1:46
  Musisz dokładnie wiedzieć, których drzwi użyć, z którym ochroniarzem rozmawiać i co zrobić, gdy ma przerwę.
• 1:51
  Dokładnie tak dzieje się, gdy Twoja aplikacja ma wiele usług zaplecza, a każdy klient wywołuje każdą z nich bezpośrednio.
• 1:56
  Klient, niezależnie czy to aplikacja mobilna, strona internetowa czy inna usługa, musi wiedzieć, gdzie znajduje się każda usługa, jak się z nią uwierzytelnić i co zrobić, gdy coś się zepsuje.
• 2:04
  Każda usługa musi sama obsłużyć swoje bezpieczeństwo, limity żądań i obsługę błędów.
• 2:09
  To powielona praca i łatwo o brak spójności.
• 2:12
  Weźmy na przykład bank.
• 2:13
  Mają oddzielne usługi dla kont, płatności, kredytów i wykrywania oszustw.
• 2:17
  W starym modelu każda z nich jest udostępniona bezpośrednio.
• 2:19
  Aplikacja mobilna musi znać cztery różne adresy URL, cztery różne metody uwierzytelniania i cztery różne sposoby obsługi błędów.
• 2:25
  To czterokrotnie większa złożoność i czterokrotnie większe pole do błędów, a właśnie ten chaos ma naprawić bramka API.
• 2:32
  Jakie jest więc rozwiązanie?
• 2:34
  Czym jest bramka API?
• 2:35
  Wyobraź sobie bramkę API jako recepcję w hotelu.
• 2:38
  Gdy wchodzisz, nie musisz wiedzieć, na którym piętrze jest sprzątanie, gdzie jest kuchnia, ani jak skontaktować się z obsługą techniczną.
• 2:44
  Po prostu podchodzisz do recepcji, mówisz czego potrzebujesz, a oni zajmują się resztą.
• 2:48
  Kierują Twoją prośbę do odpowiedniej osoby, sprawdzają, czy masz prawo tam przebywać, a nawet sami realizują podstawowe żądania.
• 2:54
  Bramka API robi to samo dla Twojego oprogramowania. To pojedynczy punkt wejścia, który znajduje się między Twoimi klientami a usługami zaplecza.
• 3:01
  Każde żądanie przechodzi najpierw przez bramkę. Decyduje ona, dokąd je wysłać, czy na nie pozwolić i co odesłać w odpowiedzi.
• 3:07
  To wcale nie jest nowy pomysł.
• 3:09
  Odwrotne serwery proxy istnieją od dekad, ale bramka API stała się niezbędna w mikrousługach.
• 3:14
  Kiedy dzielisz aplikacje na wiele małych usług, nagle masz wiele drzwi.
• 3:17
  Bramka zapewnia Ci jedne drzwi wejściowe.
• 3:19
  W świecie Azure, Azure API Management to pełna platforma, a bramka to kluczowy element obsługujący ruch.
• 3:24
  Wzorzec jest jednak wszędzie taki sam.
• 3:26
  Jeden punkt wejścia, scentralizowana kontrola.
• 3:29
  Każde żądanie nadchodzi. Bramka sprawdza je, kieruje dalej i odsyła odpowiedź.
• 3:33
  Klient nigdy nie komunikuje się bezpośrednio z usługami zaplecza.
• 3:36
  Rozmawia tylko z bramką. Przeanalizujmy, co to właściwie oznacza.
• 3:39
  Zacznijmy od najbardziej podstawowego zadania, czyli routingu.
• 3:42
  Część pierwsza, kierowanie ruchem.
• 3:44
  Najprostszym zadaniem bramki API jest routing, czyli kierowanie każdego żądania do odpowiedniej usługi.
• 3:48
  Pomyśl o tym, jak działa strona internetowa.
• 3:50
  Kiedy klikasz link, Twoja przeglądarka wysyła żądanie.
• 3:53
  To żądanie ma ścieżkę.
• 3:54
  Jeśli ścieżka to użytkownicy, bramka wie, że ma wysłać je do usługi użytkowników.
• 3:58
  Jeśli to zamówienia, trafia do usługi zamówień.
• 4:00
  Bramka odczytuje ścieżkę, ustala cel i przekazuje żądanie dalej.
• 4:03
  Bez bramki Twoi klienci muszą znać adres URL każdej pojedynczej usługi.
• 4:07
  Aplikacja mobilna potrzebuje adresu usługi użytkowników, usługi zamówień, płatności i katalogu.
• 4:11
  To całkiem sporo adresów URL do zarządzania.
• 4:13
  A jeśli którykolwiek z tych adresów się zmieni, musisz zaktualizować każdego klienta.
• 4:17
  Dzięki bramie klienci znają tylko jeden adres URL.
• 4:19
  Adres samej bramy nie interesuje ich, gdzie faktycznie znajdują się usługi.
• 4:23
  Wysyłają zapytanie do bramy, a ona zajmuje się resztą.
• 4:26
  To jeden z najczęstszych przypadków użycia bramy API Routing oparty na zasobach.
• 4:30
  Badania Apache AP i S i X wspominają o tym wyraźnie.
• 4:33
  Kierujesz ruchem na podstawie ścieżki metody HTTP, nagłówków, a nawet lokalizacji klienta.
• 4:37
  Jeśli ktoś w Europie wysyła zapytanie, możesz skierować go do Europejskiego Centrum Danych.
• 4:41
  Jeśli zapytanie pochodzi z USA, trafia do amerykańskiego Centrum Danych.
• 4:44
  Klient nie ma pojęcia, że cokolwiek z tego się dzieje.
• 4:46
  Po prostu otrzymuje szybką odpowiedź.
• 4:48
  Routing obsługuje również wersjonowanie.
• 4:49
  Załóżmy, że masz nową wersję usługi użytkownika.
• 4:52
  Starzy klienci nadal używają V1 Users, a nowi używają V2 Users.
• 4:56
  Brama kieruje ich do odpowiednich backendów.
• 4:58
  Starzy klienci działają dalej, podczas gdy Ty wdrażasz nową wersję.
• 5:01
  Możesz zmieniać backend bez psucia działania aplikacji u klientów.
• 5:04
  To ogromna zaleta, gdy zarządzasz działającą aplikacją z prawdziwymi użytkownikami.
• 5:07
  Pomyśl o platformie e-commerce. Masz osobne usługi dla katalogu koszyka, kasy i kont użytkowników.
• 5:13
  Bez bramy aplikacja mobilna musiałaby znać cztery różne adresy URL.
• 5:17
  Dzięki bramie zna tylko jeden.
• 5:19
  Brama odczytuje ścieżkę katalog koszyk, kasa, konto i wysyła każde żądanie do właściwej usługi.
• 5:25
  Prosty routing to tylko początek.
• 5:26
  W kolejnym zadaniu robi się naprawdę ciekawie.
• 5:29
  Część druga – bezpieczeństwo na wejściu.
• 5:31
  Każde wywołanie API musi zostać sprawdzone.
• 5:33
  Kto wysyła to zapytanie? Czy ma odpowiednie uprawnienia?
• 5:36
  Bez bramy każda usługa musi sama zajmować się uwierzytelnianiem.
• 5:39
  Oznacza to powielanie pracy i łatwo obłędy.
• 5:42
  Jedna usługa może poprawnie sprawdzać tokeny, inna może pominąć krok, a jeszcze inna użyć zupełnie innej metody.
• 5:48
  Efektem jest niespójne bezpieczeństwo w całej aplikacji.
• 5:51
  Brama to zmienia.
• 5:52
  Obsługuje uwierzytelnianie i autoryzację w jednym centralnym miejscu.
• 5:55
  Jeden punkt kontroli, jeden punkt egzekwowania, jeden punkt aktualizacji przy zmianie zasad.
• 5:59
  To najlepsza praktyka w zakresie bezpieczeństwa.
• 6:01
  Weryfikuje klucze API, tokeny JWT, OAuth lub certyfikaty przy każdym zapytaniu.
• 6:06
  Każde żądanie przechodzi przez tę samą kontrolę, bez wyjątków.
• 6:10
  Brama może również wymuszać reguły.
• 6:12
  Możesz określić, ten klucz API może wywoływać tylko punkty końcowe typu odczyt.
• 6:15
  Albo ten klient ma dostęp tylko do usługi katalogu, a nie do płatności.
• 6:19
  Definiujesz precyzyjne uprawnienia na poziomie bramy, a one stosują się automatycznie.
• 6:23
  Usługi zaplecza nigdy nie muszą martwić się o autoryzację.
• 6:26
  Po prostu przetwarzają żądanie i odsyłają dane.
• 6:28
  Oto w czym rzecz.
• 6:29
  Brama to jedno miejsce, w którym można cofnąć dostęp, gdy coś pójdzie nie tak.
• 6:33
  Jeśli klucz API klienta zostanie przejęty, unieważniasz go na bramie.
• 6:36
  Jedna zmiana i gotowe.
• 6:37
  Nie musisz aktualizować każdej usługi, ani niczego restartować.
• 6:40
  Kolejne żądanie z użyciem tego klucza zostaje natychmiast odrzucone.
• 6:43
  Weźmy rzeczywisty przykład.
• 6:44
  Bank posiada usługę płatności i usługę rozliczeniową.
• 6:46
  Tylko usługa płatności potrzebuje dostępu do zapisu w systemie rozliczeniowym.
• 6:49
  Brama egzekwuje to ograniczenie.
• 6:51
  Jeśli klient próbuje zapisać dane w systemie rozliczeniowym przez niewłaściwy punkt końcowy, brama go blokuje.
• 6:55
  Usługa rozliczeniowa nawet nie widzi tego żądania.
• 6:57
  Brama może również wspierać wzajemne TLS i integrację z WAF dla głębszej ochrony.
• 7:02
  Jednak w swojej istocie jest to Twoja pierwsza linia obrony.
• 7:05
  Bezpieczeństwo to jedno, ale co, gdy naraz napływa zbyt wiele żądań?
• 7:08
  Część trzecia, zarządzanie ruchem.
• 7:10
  Co się dzieje, gdy 10 tysięcy użytkowników wchodzi do Twojej aplikacji w tym samym czasie?
• 7:14
  Może prowadzisz wyprzedaż błyskawiczną?
• 7:15
  Może premiera produktu stała się viralem?
• 7:17
  Albo to po prostu zwykły wtorek i wszyscy postanowili zalogować się naraz?
• 7:20
  Bez bramy Twojej usługi zaplecza są bezpośrednio atakowane i mogą ulec awarii.
• 7:25
  Nie powoli, lecz nagle.
• 7:26
  Wtedy właśnie wkracza zarządzanie ruchem.
• 7:28
  Brama może ograniczyć liczbę żądań, jakie każdy klient może wysłać.
• 7:32
  Limitowanie tempa i dławienie to standardowe funkcje.
• 7:34
  Ustawiasz reguły na bramie, a ona je egzekwuje.
• 7:37
  Twoje usługi zaplecza nigdy nie odczuwają skoku ruchu.
• 7:39
  Możesz ustawić limity na użytkownika, na klucz API lub na adres IP.
• 7:42
  Powiedzmy, że masz darmowy poziom dostępu do swojego API.
• 7:45
  Darmowi użytkownicy otrzymują 100 żądań na godzinę.
• 7:47
  Użytkownicy premium otrzymują 10 tysięcy.
• 7:49
  Brama śledzi każde żądanie i egzekwuje te limity przy wejściu.
• 7:52
  Gdy darmowy użytkownik osiągnie swój limit,
• 7:54
  brama odsyła uprzejmą wiadomość, by spróbować ponownie później.
• 7:56
  Usługi zaplecza nawet nie wiedzą, że żądanie miało miejsce.
• 7:59
  Działają dalej, obsługując płacących klientów.
• 8:02
  Brama obsługuje również równoważenie obciążenia.
• 8:04
  Jeśli masz uruchomionych wiele instancji tej samej usługi,
• 8:07
  brama rozdziela między nieżądania.
• 8:12
  Dzieje się to automatycznie, a jeśli jedna instancja przestanie działać,
• 8:15
  brama przekierowuje ruch do innej.
• 8:16
  Klienci nigdy się o tym nie dowiadują.
• 8:18
  Po prostu otrzymują swoją odpowiedź.
• 8:19
  Równoważenie obciążenia z kontrolami stanu zapewnia płynne działanie.
• 8:22
  Brama pęk każdą instancję, aby upewnić się, że żyje.
• 8:25
  Jeśli nie, przestaje wysyłać tam ruch.
• 8:27
  Jest to szczególnie ważne w przypadku API o dużym natężeniu ruchu.
• 8:30
  Bez bramy sieciowej nagły wzrost ruchu uderza bezpośrednio w Twoje usługi.
• 8:33
  Z bramą skok ruchu trafia najpierw do niej,
• 8:36
  ona go przejmuje, rozkłada i chroni Twoje usługi przed przeciążeniem.
• 8:40
  Dobrze, ale co jeśli dane nie wyglądają właściwie po dotarciu?
• 8:44
  Część czwarta – transformacja danych.
• 8:46
  Czasami dane wysyłane przez klienta nie pasują do tego, czego oczekuje backend.
• 8:50
  Być może klient wysyła JSON, a Twój backend rozumie tylko XML.
• 8:54
  Być może nazwy pól się nie zgadzają.
• 8:56
  Klient używa first name, a backend oczekuje imię.
• 8:58
  Takie niedopasowania psują działanie systemu.
• 9:01
  W starym modelu musiałbyś poprawić każdego klienta lub napisać backend od nowa.
• 9:04
  Słabe rozwiązanie. Brama może przekształcić dane, zanim dotrą one do backendu.
• 9:08
  Pomyśl o niej jak o tłumaczu.
• 9:09
  Stoi po środku i może zmieniać dane w drodze do środka, na zewnątrz lub w obie strony.
• 9:13
  To w skrócie transformacja żądań i odpowiedzi.
• 9:15
  Podam Ci rzeczywisty przykład.
• 9:17
  Załóżmy, że masz system Legacy, który oczekuje XML.
• 9:19
  Działa już od 15 lat.
• 9:21
  Sprawdza się doskonale, ale teraz budujesz nową aplikację mobilną, a one mówią w formacie JSON.
• 9:25
  Bez bramy musiałbyś przepisać stary system lub zmusić aplikację do wysyłania XML.
• 9:29
  Z bramą nie musisz robić żadnej z tych rzeczy.
• 9:31
  Aplikacja mobilna wysyła JSON.
• 9:32
  Brama konwertuje go na XML.
• 9:34
  System otrzymuje dokładnie to, czego oczekuje.
• 9:36
  Aplikacja mobilna dostaje odpowiedź z powrotem w formacie JSON.
• 9:39
  Nikt nie musiał niczego przepisywać.
• 9:40
  Na tym polega jej piękno.
• 9:42
  Brama może też dodawać lub usuwać nagłówki, zmieniać adresy URL czy maskować wrażliwe dane.
• 9:46
  Wyobraź sobie, że odpowiedź zawiera numer karty kredytowej.
• 9:48
  Nie chcesz, aby trafił on z powrotem do klienta.
• 9:50
  Brama może go usunąć przed wysłaniem odpowiedzi lub zastąpić zamaskowaną wersją.
• 9:54
  Backend nie musi się wcale zmieniać.
• 9:55
  Brama zajmuje się tym za niego.
• 9:57
  Jest to szczególnie przydatne przy modernizacji starych systemów.
• 9:59
  Nie musisz przepisywać backendu.
• 10:01
  Nie musisz zmuszać klientów do zmian.
• 10:03
  Po prostu zmieniasz konfigurację bramy.
• 10:04
  To jak tłumacz na międzynarodowej konferencji.
• 10:07
  Każdy mówi w swoim języku, ale tłumacz sprawia, że wszyscy się rozumieją.
• 10:10
  Brama jest takim właśnie tłumaczem dla twojego oprogramowania.
• 10:12
  Więc routing, bezpieczeństwo, frotting, transformacja to sporo.
• 10:15
  Ale to nie są cztery oddzielne rzeczy.
• 10:17
  Pokażę ci, jak są ze sobą połączone.
• 10:19
  Jak to wszystko się łączy.
• 10:20
  Oto w czym rzecz.
• 10:21
  Te cztery zadania nie są odseparowane.
• 10:23
  Współpracują przy każdym pojedynczym żądaniu za każdym razem, gdy ono wpływa.
• 10:26
  Brama sprawdza uwierzytelnienie, weryfikuje limit zapytań, kieruje ruch do odpowiedniej usługi.
• 10:31
  W razie potrzeby przekształca dane.
• 10:33
  Odbiera odpowiedź.
• 10:34
  Jeśli trzeba, przekształca również ją.
• 10:36
  Następnie odsyła wszystko do klienta.
• 10:38
  Jeden potok.
• 10:38
  Każdy krok dzieje się automatycznie, w kolejności, bez angażowania usług.
• 10:42
  Prawdziwa siła nie tkwi w pojedynczej funkcji, lecz w integracji.
• 10:45
  Możesz dodać nową politykę bezpieczeństwa, nie ruszając routingu.
• 10:49
  Usługę backendową bez zmieniania klienta.
• 10:51
  Możesz zaktualizować limity zapytań bez ponownego wdrażania czegokolwiek.
• 10:54
  Każdy element jest niezależny, ale wszystkie działają w tym samym potoku.
• 10:58
  A ponieważ wszystko przechodzi przez jedno miejsce, masz pełny wgląd w sytuację.
• 11:02
  Logi, metryki, analityka, wszystko z jednego punktu.
• 11:05
  Widzisz, ile zapytań wpłynęło, które zawiodły, które były wolne i kto zużywa najwięcej zasobów.
• 11:10
  Bez bramy musiałbyś zbierać te dane z każdej usługi z osobna.
• 11:13
  Z bramą wszystko jest dostępne od razu.
• 11:15
  To jest kluczowy wniosek.
• 11:16
  Brama to nie tylko router.
• 11:18
  To centrum sterowania całą twoją platformą API.
• 11:20
  Każde zapytanie, odpowiedź i błąd przepływają przez jeden punkt.
• 11:23
  Masz jednolity wgląd we wszystko, co się dzieje.
• 11:26
  Jak więc faktycznie tego użyć?
• 11:28
  Porozmawiajmy o tym, co możesz zrobić w tej chwili.
• 11:30
  Konkretne wnioski.
• 11:31
  Bądźmy szczerzy.
• 11:32
  Jeśli masz jedną lub dwie usługi, prawdopodobnie nie potrzebujesz jeszcze bramy API.
• 11:35
  Możesz samodzielnie zarządzać routingiem i uwierzytelnianiem w każdej usłudze.
• 11:38
  Nie jest to eleganckie, ale działa.
• 11:40
  Jednak gdy osiągniesz trzy usługi lub udostępnisz API klientom zewnętrznym, złożoność szybko rośnie.
• 11:45
  Brama szybko się zwraca.
• 11:47
  Jaki jest więc twój najlepszy pierwszy krok?
• 11:49
  Scentralizuj uwierzytelnianie na bramie.
• 11:50
  Zrób to przed wszystkim innym.
• 11:52
  Wybierz jedną usługę i przenieś sprawdzanie dostępu do bramy.
• 11:54
  Od razu zauważysz, że kod twojej usługi staje się czystszy.
• 11:57
  Koniec z logiką walidacji tokenów rozproszoną wszędzie.
• 12:00
  Koniec z zastanawianiem się, czy wdrożyłeś to tak samo w każdej usłudze.
• 12:03
  Brama obsługuje to raz, a każda usługa na tym korzysta.
• 12:06
  Następny krok – limity zapytań.
• 12:08
  Nawet prosty limit chroni twój backend przed przeciążeniem.
• 12:11
  Zacznij od czegoś podstawowego, na przykład
• 12:12
  100 zapytań na minutę dla klienta.
• 12:14
  To powstrzyma niekontrolowanego klienta przed wyłączeniem twoich usług.
• 12:16
  Możesz porozmawiać.