Share via

Ocena i gotowość mikrousług

  • Artykuł

Architektura mikrousług może zapewnić wiele korzyści dla aplikacji, w tym elastyczność, skalowalność i wysoką dostępność. Wraz z tymi korzyściami ta architektura stanowi wyzwanie. Podczas tworzenia aplikacji opartych na mikrousługach lub przekształcania istniejących aplikacji w architekturę mikrousług należy przeanalizować i ocenić bieżącą sytuację, aby zidentyfikować obszary wymagające poprawy.

Ten przewodnik pomoże Ci zrozumieć niektóre zagadnienia, które należy wziąć pod uwagę podczas przechodzenia do architektury mikrousług. Ten przewodnik umożliwia ocenę dojrzałości aplikacji, infrastruktury, metodyki DevOps, modelu programowania i nie tylko.

Informacje o priorytetach biznesowych

Aby rozpocząć ocenę architektury mikrousług, musisz najpierw zrozumieć podstawowe priorytety firmy. Podstawowe priorytety mogą być na przykład związane z elastycznością, wdrażaniem zmian lub szybkim rozwojem. Musisz przeanalizować, czy architektura jest dobrym rozwiązaniem dla podstawowych priorytetów. Należy pamiętać, że priorytety biznesowe mogą się zmieniać w czasie. Na przykład innowacje są priorytetem dla startupów, ale po kilku latach główne priorytety mogą być niezawodnością i wydajnością.

Oto kilka priorytetów, które należy wziąć pod uwagę:

  • Innowacje
  • Niezawodność
  • Wydajność

Udokumentuj umowy SLA dopasowane do różnych części aplikacji, aby zapewnić zaangażowanie organizacji, które może służyć jako przewodnik po ocenie.

Rejestruj decyzje dotyczące architektury

Architektura mikrousług pomaga zespołom stać się autonomicznymi. Na przykład zespoły mogą podejmować własne decyzje dotyczące technologii, metodologii i składników infrastruktury. Jednak te wybory powinny uwzględniać formalnie uzgodnione zasady znane jako współdzielonego ładu, które wyrażają porozumienie między zespołami w sprawie sposobu rozwiązania szerszej strategii mikrousług.

Rozważ następujące czynniki:

  • Czy ład współużytkowany jest w miejscu?
  • Czy śledzisz decyzje i ich kompromisy w czasopiśmie architektury?
  • Czy twój zespół może łatwo uzyskać dostęp do dziennika architektury?
  • Czy masz proces oceny narzędzi, technologii i struktur?

Ocena składu zespołu

Musisz mieć odpowiednią strukturę zespołu, aby uniknąć niepotrzebnej komunikacji między zespołami. Architektura mikrousług zachęca do tworzenia małych, skoncentrowanych, współzarządzanych zespołów i wymaga zmiany sposobu myślenia, która musi być poprzedzona restrukturyzacją zespołu.

Rozważ następujące czynniki:

  • Czy zespoły są podzielone na podstawie poddomen, zgodnie z zasadami projektowania opartego na domenie (DDD)?
  • Czy twoje zespoły działają wspólnie z wystarczającą pojemnością, aby tworzyć i obsługiwać powiązane mikrousługi niezależnie?
  • Ile czasu poświęca się na działania ad hoc i zadania, które nie są związane z projektami?
  • Ile czasu poświęca się na współpracę między zespołami?
  • Czy masz proces identyfikowania i minimalizowania długu technicznego?
  • W jaki sposób wnioski i doświadczenia są przekazywane między zespołami?

Korzystanie z metodologii dwunastoskładnikowej

Podstawowym celem wyboru architektury mikrousług jest szybsze dostarczanie wartości i adaptacyjne zmienianie, postępując zgodnie z praktykami agile. Metodologia aplikacji Dwunastoskładnikowych zawiera wskazówki dotyczące tworzenia utrzymywania i skalowalnych aplikacji. Te wytyczne promują atrybuty, takie jak niezmienność, efemerylność, konfiguracja deklaratywna i automatyzacja. Uwzględniając te wytyczne i unikając typowych pułapek, można utworzyć luźno powiązane, samodzielne mikrousługi.

Omówienie podejścia dekompozycji

Przekształcanie aplikacji monolitycznej w architekturę mikrousług wymaga czasu. Zacznij od usług brzegowych. Usługi brzegowe mają mniej zależności od innych usług i można je łatwo rozkładać z systemu jako niezależne usługi. Zdecydowanie zalecamy wzorce, takie jak Strangler Fig i Warstwa antykorupcyjna, aby zachować aplikację monolityczną w stanie roboczym, dopóki wszystkie usługi nie zostaną rozłożone na oddzielne mikrousługi. Podczas segregacji zasady DDD mogą pomóc zespołom w wyborze składników lub usług z aplikacji monolitycznej na podstawie poddomen.

Na przykład w systemie handlu elektronicznego mogą istnieć następujące moduły: koszyk, zarządzanie produktami, zarządzanie zamówieniami, cennik, generowanie faktur i powiadomienia. Decydujesz się rozpocząć transformację aplikacji za pomocą modułu powiadomień, ponieważ nie ma zależności od innych modułów. Jednak inne moduły mogą zależeć od tego modułu do wysyłania powiadomień. Moduł powiadomień można łatwo podzielić na oddzielną mikrousługę, ale musisz wprowadzić pewne zmiany w aplikacji monolitycznej, aby wywołać nową usługę powiadomień. Decydujesz się na następne przekształcenie modułu generowania faktur. Ten moduł jest wywoływany po wygenerowaniu zamówienia. Aby obsługiwać tę transformację, można użyć wzorców, takich jak Strangler i Anti-corruption.

Synchronizacja danych, wiele zapisów w interfejsach monolitycznych i mikrousług, własność danych, dekompozycja schematu, sprzężenia, ilość danych i integralność danych mogą utrudnić podział danych i migrację. Istnieje kilka technik, których można użyć, takich jak utrzymywanie udostępnionej bazy danych między mikrousługami, oddzielenie baz danych od grupy usług na podstawie możliwości biznesowych lub domeny i izolowanie baz danych z usług. Zalecanym rozwiązaniem jest dekompilowanie każdej bazy danych z każdą usługą. W wielu okolicznościach nie jest to praktyczne. W takich przypadkach można użyć wzorców, takich jak wzorzec widoku bazy danych i wzorzec usługi opakowującego bazy danych.

Ocena gotowości metodyki DevOps

Podczas przechodzenia do architektury mikrousług ważne jest, aby ocenić kompetencje devOps. Architektura mikrousług ma na celu ułatwienie elastycznego tworzenia aplikacji w celu zwiększenia elastyczności organizacji. Metodyka DevOps jest jedną z kluczowych praktyk, które należy wdrożyć w celu osiągnięcia tych kompetencji.

Podczas oceniania możliwości metodyki DevOps dla architektury mikrousług należy pamiętać o następujących kwestiach:

  • Czy ludzie w organizacji znają podstawowe praktyki i zasady metodyki DevOps?
  • Czy zespoły rozumieją narzędzia kontroli źródła i ich integrację z potokami ciągłej integracji/ciągłego wdrażania?
  • Czy prawidłowo implementujesz praktyki Metodyki DevOps?
    • Czy stosujesz rozwiązania agile?
    • Czy ciągła integracja jest implementowana?
    • Czy ciągłe dostarczanie jest implementowane?
    • Czy ciągłe wdrażanie jest implementowane?
    • Czy ciągłe monitorowanie jest implementowane?
    • Czy infrastruktura jako kod (IaC) jest w miejscu?
  • Czy używasz właściwych narzędzi do obsługi ciągłej integracji/ciągłego wdrażania?
  • W jaki sposób konfiguracja środowisk przejściowych i produkcyjnych jest zarządzana dla aplikacji?
  • Czy łańcuch narzędzi ma wsparcie społeczności i model pomocy technicznej oraz zapewnia odpowiednie kanały i dokumentację?

Identyfikowanie obszarów biznesowych, które zmieniają się często

Architektura mikrousług jest elastyczna i elastyczna. Podczas oceny należy prowadzić dyskusję w organizacji, aby określić obszary, które współpracownicy myślą, że często się zmienią. Tworzenie mikrousług umożliwia zespołom szybkie reagowanie na zmiany, które klienci żądają i minimalizują nakłady pracy związane z testowaniem regresji. W aplikacji monolitycznej zmiana w jednym module wymaga wielu poziomów testowania regresji i zmniejsza elastyczność wydawania nowych wersji.

Rozważ następujące czynniki:

  • Czy usługa jest wdrażana niezależnie?
  • Czy usługa przestrzega zasad DDD?
  • Czy usługa jest zgodne z zasadami SOLID?
  • Czy baza danych jest prywatna dla usługi?
  • Czy usługa została utworzona przy użyciu obsługiwanego wzorca obudowy mikrousług?

Ocena gotowości infrastruktury

Po przejściu do architektury mikrousług gotowość infrastruktury jest krytycznym punktem do rozważenia. Wydajność, dostępność i skalowalność aplikacji będą miały wpływ, jeśli infrastruktura nie zostanie prawidłowo skonfigurowana lub jeśli odpowiednie usługi lub składniki nie są używane. Czasami aplikacja jest tworzona ze wszystkimi sugerowanymi metodologiami i procedurami, ale infrastruktura jest niewystarczająca. Skutkuje to niską wydajnością i konserwacją.

Podczas oceny gotowości infrastruktury należy wziąć pod uwagę następujące czynniki:

  • Czy infrastruktura zapewnia skalowalność wdrożonych usług?
  • Czy infrastruktura obsługuje aprowizowanie za pośrednictwem skryptów, które można zautomatyzować za pośrednictwem ciągłej integracji/ciągłego wdrażania?
  • Czy infrastruktura wdrażania oferuje umowę SLA dla dostępności?
  • Czy masz plan odzyskiwania po awarii i rutynowe harmonogramy testowania?
  • Czy dane są replikowane do różnych regionów odzyskiwania po awarii?
  • Czy masz plan tworzenia kopii zapasowych danych?
  • Czy opcje wdrażania są udokumentowane?
  • Czy infrastruktura wdrażania jest monitorowana?
  • Czy infrastruktura wdrażania obsługuje samonaprawiania usług?

Ocena cykli wydania

Mikrousługi są adaptacyjne w celu zmiany i korzystają z elastycznego programowania w celu skrócenia cykli wydania i zwiększenia wartości dla klientów. Podczas oceniania cykli wydania należy wziąć pod uwagę następujące czynniki:

  • Jak często kompilujesz i publikujesz aplikacje?
  • Jak często wydania kończą się niepowodzeniem po wdrożeniu?
  • Jak długo trwa odzyskiwanie lub korygowanie problemów po awarii?
  • Czy używasz semantycznego przechowywania wersji dla aplikacji?
  • Czy utrzymujesz różne środowiska i propagujesz tę samą wersję w sekwencji (na przykład najpierw do przemieszczania, a następnie do środowiska produkcyjnego)?
  • Czy używasz przechowywania wersji dla interfejsów API?
  • Czy przestrzegasz odpowiednich wytycznych dotyczących przechowywania wersji dla interfejsów API?
  • Kiedy zmieniasz wersję interfejsu API?
  • Jakie jest Twoje podejście do obsługi przechowywania wersji interfejsu API?
    • Przechowywanie wersji ścieżki identyfikatora URI
    • Przechowywanie wersji parametrów zapytania
    • Przechowywanie wersji typu zawartości
    • Przechowywanie wersji nagłówka niestandardowego
  • Czy masz praktykę w zakresie przechowywania wersji zdarzeń?

Ocena komunikacji między usługami

Mikrousługi to samoobsługowe usługi komunikujące się ze sobą przez granice procesów w celu rozwiązywania problemów ze scenariuszami biznesowymi. Aby uzyskać niezawodną i niezawodną komunikację, należy wybrać odpowiedni protokół komunikacyjny.

Weź pod uwagę następujące czynniki:

  • Czy obserwujesz podejście oparte na interfejsie API, w którym interfejsy API są traktowane jako obywatele pierwszej klasy?
  • Czy masz długotrwałe operacje, w których wiele usług komunikuje się sekwencjonowo za pośrednictwem synchronicznego protokołu komunikacyjnego?
  • Czy uważasz za asynchroniczną komunikację w dowolnym miejscu w systemie?
  • Czy oceniono technologię brokera komunikatów i jej możliwości?
  • Czy rozumiesz przepływność komunikatów odbieranych i przetwarzanych przez usługi?
  • Czy używasz bezpośredniej komunikacji typu klient-usługa?
  • Czy musisz utrwalać komunikaty na poziomie brokera komunikatów?
  • Czy używasz wzorca zmaterializowanego widoku, aby rozwiązać problem z zachowaniem mikrousług?
  • Czy zaimplementowano ponawianie prób, wyłącznik, wycofywanie wykładnicze i jitter w celu zapewnienia niezawodnej komunikacji? Typowym sposobem obsługi tego rozwiązania jest użycie wzorca ambasadora.
  • Czy zdefiniowano zdarzenia domeny w celu ułatwienia komunikacji między mikrousługami?

Ocena sposobu uwidaczniania usług klientom

Brama interfejsu API jest jednym z podstawowych składników architektury mikrousług. Bezpośrednie uwidacznianie usług klientom powoduje problemy związane z możliwościami zarządzania, kontrolą i niezawodną komunikacją. Brama interfejsu API służy jako serwer proxy, przechwytując ruch i rozsyłając go do usług zaplecza. Jeśli musisz filtrować ruch według adresu IP, autoryzacji, pozornych odpowiedzi itd., możesz to zrobić na poziomie bramy interfejsu API bez wprowadzania żadnych zmian w usługach.

Weź pod uwagę następujące czynniki:

  • Czy usługi są używane bezpośrednio przez klientów?
  • Czy istnieje brama interfejsu API, która działa jako fasada dla wszystkich usług?
  • Czy brama interfejsu API może skonfigurować zasady, takie jak limity przydziału, pozorowanie odpowiedzi i filtrowanie adresów IP?
  • Czy używasz wielu bram interfejsu API do zaspokojenia potrzeb różnych typów klientów, takich jak aplikacje mobilne, aplikacje internetowe i partnerzy?
  • Czy brama interfejsu API udostępnia portal, w którym klienci mogą odnajdywać i subskrybować usługi, takie jak portal dla deweloperów w usłudze Azure API Management?
  • Czy twoje rozwiązanie zapewnia funkcje równoważenia obciążenia L7 lub zapory aplikacji internetowej (WAF) wraz z bramą interfejsu API?

Ocena obsługi transakcji

Transakcje rozproszone ułatwiają wykonywanie wielu operacji jako pojedynczą jednostkę pracy. W architekturze mikrousług system jest rozłożony na wiele usług. Pojedynczy przypadek użycia biznesowego jest rozwiązywany przez wiele mikrousług w ramach jednej transakcji rozproszonej. W transakcji rozproszonej polecenie jest operacją uruchamianą po wystąpieniu zdarzenia. Zdarzenie wyzwala operację w systemie. Jeśli operacja zakończy się pomyślnie, może ona wyzwolić inne polecenie, które może następnie wyzwolić inne zdarzenie i tak dalej, dopóki wszystkie transakcje nie zostaną ukończone lub wycofane, w zależności od tego, czy transakcja zakończy się pomyślnie.

Weź pod uwagę następujące kwestie:

  • Ile transakcji rozproszonych istnieje w systemie?
  • Jakie jest Twoje podejście do obsługi transakcji rozproszonych? Oceń użycie wzorca Saga z orkiestracją lub choreografią.
  • Ile transakcji obejmuje wiele usług?
  • Czy obserwujesz model transakcji ACID lub BASE, aby osiągnąć spójność i integralność danych?
  • Czy używasz długotrwałych operacji łańcuchowych dla transakcji obejmujących wiele usług?

Ocena modelu tworzenia usługi

Jedną z największych zalet architektur mikrousług jest różnorodność technologiczna. Systemy oparte na mikrousługach umożliwiają zespołom opracowywanie usług przy użyciu wybieranych technologii. W przypadku tradycyjnego tworzenia aplikacji można ponownie użyć istniejącego kodu podczas tworzenia nowych składników lub utworzyć wewnętrzną strukturę deweloperów w celu zmniejszenia nakładu pracy programistycznej. Korzystanie z wielu technologii może uniemożliwić ponowne użycie kodu.

Rozważ następujące czynniki:

  • Czy używasz szablonu usługi do rozpoczęcia tworzenia nowych usług?
  • Czy należy przestrzegać metodologii aplikacji Twelve-Factor i używać pojedynczej bazy kodu dla mikrousług, izolowania zależności i konfiguracji zewnętrznej?
  • Czy zachowasz wrażliwą konfigurację w magazynach kluczy?
  • Czy konteneryzujesz usługi?
  • Czy znasz wymagania dotyczące spójności danych?

Ocena podejścia do wdrażania

Twoje podejście do wdrażania to metoda wydawania wersji aplikacji w różnych środowiskach wdrażania. Systemy oparte na mikrousługach zapewniają elastyczność wydawania wersji szybciej niż w przypadku tradycyjnych aplikacji.

Podczas oceniania planu wdrożenia należy wziąć pod uwagę następujące czynniki:

  • Czy masz strategię wdrażania usług?
  • Czy używasz nowoczesnych narzędzi i technologii do wdrażania usług?
  • Jakiego rodzaju współpraca jest wymagana wśród zespołów podczas wdrażania usług?
  • Czy aprowizujesz infrastrukturę przy użyciu infrastruktury jako kodu (IaC)?
  • Czy używasz funkcji metodyki DevOps do automatyzowania wdrożeń?
  • Czy propagujesz te same kompilacje do wielu środowisk, co sugerowane przez metodologię aplikacji Twelve-Factor?

Ocena platformy hostingu

Skalowalność jest jedną z kluczowych zalet architektur mikrousług. Dzieje się tak dlatego, że mikrousługi są mapowane na domeny biznesowe, dzięki czemu każda usługa może być skalowana niezależnie. Aplikacja monolityczna jest wdrażana jako pojedyncza jednostka na platformie hostingu i musi być skalowana całościowo. Powoduje to przestój, ryzyko wdrożenia i konserwację. Aplikacja monolityczna może być dobrze zaprojektowana z składnikami odnoszącymi się do poszczególnych domen biznesowych. Jednak ze względu na brak granic procesów potencjał naruszenia zasad odpowiedzialności pojedynczej staje się trudniejszy. W końcu skutkuje to kodem spaghetti. Ponieważ aplikacja składa się i wdraża jako pojedynczy proces hostingu, skalowalność jest trudna.

Mikrousługi umożliwiają zespołom wybór odpowiedniej platformy hostingu w celu obsługi ich potrzeb w zakresie skalowalności. Różne platformy hostingu są dostępne, aby sprostać tym wyzwaniom, zapewniając możliwości, takie jak skalowanie automatyczne, elastyczne aprowizowanie, wyższa dostępność, szybsze wdrażanie i łatwe monitorowanie.

Rozważ następujące czynniki:

  • Jakiej platformy hostingu używasz do wdrażania usług (maszyn wirtualnych, kontenerów, bezserwerowych)?
  • Czy platforma hostingu jest skalowalna? Czy obsługuje skalowanie automatyczne?
  • Jak długo trwa skalowanie platformy hostingu?
  • Czy rozumiesz umowy SLA zapewniane przez różne platformy hostingu?
  • Czy platforma hostingu obsługuje odzyskiwanie po awarii?

Ocena monitorowania usług

Monitorowanie jest ważnym elementem aplikacji opartej na mikrousługach. Ponieważ aplikacja jest podzielona na wiele usług, które działają niezależnie, rozwiązywanie problemów może być trudne. Jeśli używasz odpowiedniej semantyki do monitorowania usług, zespoły mogą łatwo monitorować, badać i reagować na błędy.

Rozważ następujące czynniki:

  • Czy monitorujesz wdrożone usługi?
  • Czy masz mechanizm rejestrowania? Jakich narzędzi używasz?
  • Czy masz wbudowaną infrastrukturę śledzenia rozproszonego?
  • Czy rejestrujesz wyjątki?
  • Czy utrzymujesz kody błędów biznesowych na potrzeby szybkiej identyfikacji problemów?
  • Czy używasz sond kondycji dla usług?
  • Czy używasz rejestrowania semantycznego? Czy zaimplementowano kluczowe metryki, progi i wskaźniki?
  • Czy maskujesz poufne dane podczas rejestrowania?

Ocena przypisania tokenu korelacji

W architekturze mikrousług aplikacja składa się z różnych mikrousług hostowanych niezależnie, współdziałając ze sobą w celu obsługi różnych przypadków użycia firmy. Gdy aplikacja współdziała z usługami zaplecza w celu wykonania operacji, możesz przypisać do żądania unikatowy numer znany jako token korelacji. Zalecamy rozważenie użycia tokenów korelacji, ponieważ mogą one pomóc w rozwiązywaniu problemów z błędami. Pomagają one określić główną przyczynę problemu, ocenić wpływ i określić podejście do rozwiązania problemu.

Tokeny korelacji można użyć do pobrania dziennika żądania, identyfikując, które usługi zawierają token korelacji i które nie. Usługi, które nie mają tokenu korelacji dla tego żądania, nie powiodły się. Jeśli wystąpi awaria, możesz później ponowić próbę transakcji. Aby wymusić idempotentność, tylko usługi, które nie mają tokenu korelacji, będą obsługiwać żądanie.

Jeśli na przykład masz długi łańcuch operacji obejmujących wiele usług, przekazywanie tokenu korelacji do usług może ułatwić badanie problemów, jeśli którakolwiek z usług ulegnie awarii podczas transakcji. Każda usługa zwykle ma własną bazę danych. Token korelacji jest przechowywany w rekordzie bazy danych. W przypadku ponownego odtwarzania transakcji usługi, które mają ten konkretny token korelacji w swoich bazach danych, ignorują żądanie. Tylko usługi, które nie mają tokenu, obsługują żądanie.

Rozważ następujące czynniki:

  • Na którym etapie przypisujesz token korelacji?
  • Który składnik przypisuje token korelacji?
  • Czy zapisujesz tokeny korelacji w bazie danych usługi?
  • Jaki jest format tokenów korelacji?
  • Czy rejestrujesz tokeny korelacji i inne informacje o żądaniu?

Ocena potrzeby struktury obudowy mikrousług

Struktura obudowy mikrousług to podstawowa struktura, która zapewnia możliwości dotyczące problemów obejmujących wiele cięć, takich jak rejestrowanie, obsługa wyjątków, śledzenie rozproszone, zabezpieczenia i komunikacja. Jeśli używasz struktury obudowy, bardziej skupiasz się na implementowaniu granicy usługi niż w interakcjach z funkcją infrastruktury.

Załóżmy na przykład, że tworzysz usługę zarządzania koszykami. Chcesz zweryfikować token przychodzący, zapisać dzienniki w bazie danych rejestrowania i komunikować się z inną usługą, wywołując punkt końcowy tej usługi. Jeśli używasz struktury obudowy mikrousług, możesz zmniejszyć nakłady pracy programistycznej. Dapr to jeden system, który udostępnia różne bloki konstrukcyjne do implementowania zagadnień dotyczących krzyżowego cięcia.

Rozważ następujące czynniki:

  • Czy używasz struktury obudowy mikrousług?
  • Czy używasz języka Dapr do interakcji z problemami krzyżowymi?
  • Czy język struktury obudowy jest niezależny?
  • Czy struktura obudowy jest ogólna, więc obsługuje wszystkie rodzaje aplikacji? Struktura obudowy nie powinna zawierać logiki specyficznej dla aplikacji.
  • Czy struktura obudowy zapewnia mechanizm korzystania z wybranych składników lub usług zgodnie z potrzebami?

Ocena podejścia do testowania aplikacji

Tradycyjnie testowanie odbywa się po zakończeniu programowania, a aplikacja jest gotowa do wdrożenia w środowiskach testowych akceptacji użytkowników i środowiskach produkcyjnych. Obecnie istnieje zmiana tego podejścia, przeniesienie testowania na początku (po lewej) w cyklu projektowania aplikacji. Testowanie po lewej stronie zwiększa jakość aplikacji, ponieważ testowanie odbywa się w każdej fazie cyklu projektowania aplikacji, w tym fazy projektowania, programowania i po zakończeniu programowania.

Na przykład podczas tworzenia aplikacji zaczynasz od projektowania architektury. W przypadku korzystania z podejścia shift-left testujesz projekt pod kątem luk w zabezpieczeniach przy użyciu narzędzi takich jak Modelowanie zagrożeń firmy Microsoft. Po rozpoczęciu programowania możesz skanować kod źródłowy, uruchamiając narzędzia takie jak statyczne testowanie zabezpieczeń aplikacji (SAST) i korzystając z innych analizatorów w celu wykrycia problemów. Po wdrożeniu aplikacji możesz użyć narzędzi, takich jak dynamiczne testowanie zabezpieczeń aplikacji (DAST), aby przetestować ją, gdy jest hostowana. Testowanie funkcjonalne, testowanie chaosu, testowanie penetracyjne i inne rodzaje testów odbywają się później.

Rozważ następujące czynniki:

  • Czy piszesz plany testów obejmujące cały cykl projektowania?
  • Czy testerzy dołączają testerów na spotkaniach wymagań i w całym cyklu projektowania aplikacji?
  • Czy używasz projektu opartego na testach lub projektowania opartego na zachowaniu?
  • Czy testujesz scenariusze użytkowników? Czy uwzględnisz kryteria akceptacji w scenariuszach użytkownika?
  • Czy testujesz projekt przy użyciu narzędzi takich jak Microsoft Threat Modeling?
  • Czy piszesz testy jednostkowe?
  • Czy używasz statycznych analizatorów kodu lub innych narzędzi do mierzenia jakości kodu?
  • Czy używasz zautomatyzowanych narzędzi do testowania aplikacji?
  • Czy implementujesz rozwiązania Secure DevOps ?
  • Czy przeprowadzasz testowanie integracji, kompleksowe testowanie aplikacji, testowanie obciążenia/wydajności, testowanie penetracyjne i testowanie chaosu?

Ocena zabezpieczeń mikrousług

Ochrona usług, bezpieczny dostęp i bezpieczna komunikacja należą do najważniejszych zagadnień dotyczących architektury mikrousług. Na przykład system oparty na mikrousługach obejmujący wiele usług i używający weryfikacji tokenu dla każdej usługi nie jest opłacalnym rozwiązaniem. Ten system wpłynie na elastyczność całego systemu i potencjał wprowadzenia dryfu implementacji między usługami.

Problemy z zabezpieczeniami są zwykle obsługiwane przez bramę interfejsu API i zaporę aplikacji. Brama i zapora przyjmują żądania przychodzące, weryfikują tokeny i stosują różne filtry i zasady, takie jak implementowanie zasad OWASP Top 10 w celu przechwycenia ruchu. Na koniec wysyłają żądanie do mikrousług zaplecza. Ta konfiguracja ułatwia deweloperom skoncentrowanie się na potrzebach biznesowych, a nie na przekrojowym problemie z zabezpieczeniami.

Rozważ następujące czynniki:

  • Czy uwierzytelnianie i autoryzacja są wymagane dla usługi?
  • Czy używasz bramy interfejsu API do weryfikowania tokenów i żądań przychodzących?
  • Czy używasz protokołu SSL lub mTLS do zapewnienia bezpieczeństwa komunikacji z usługą?
  • Czy istnieją zasady zabezpieczeń sieci, aby umożliwić wymaganą komunikację między usługami?
  • Czy używasz zapór (L4, L7), jeśli ma to zastosowanie do zapewnienia zabezpieczeń dla komunikacji wewnętrznej i zewnętrznej?
  • Czy używasz zasad zabezpieczeń w usłudze API Gateway do kontrolowania ruchu?

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

  • Ovais Mehboob Ahmed Khan | Starszy architekt rozwiązań w chmurze — inżynieria
  • Nabil Siddiqui | Architekt rozwiązań w chmurze — innowacje w zakresie technologii cyfrowych i aplikacji

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki