Mikroserwisy

Rozdzielić systemy, zanim zależności zaczną spowalniać pracę.

Niezależny rozwój może pomagać, ale zbyt wiele rozproszonych usług może go też utrudniać. Sprawdzamy sensowne granice biznesowe i wdrażamy odpowiednią architekturę, obejmującą komunikację, odpowiedzialność za dane, dostarczanie oraz eksploatację.

Czym się zajmujemy Omówmy przedsięwzięcie

Model domenowy z podziałem na usługi i interfejsami · planowanie i realizacja przez OTOKO®

Państwa zlecenie dla OTOKO®

Czym się dla Państwa zajmujemy.

Wspólnie z działem biznesowym i zespołem programistycznym analizujemy pojęcia, reguły i zmiany. Funkcje, które regularnie trzeba zmieniać razem, nie powinny być lekkomyślnie rozdzielane. Modularny monolit może zapewnić jasne granice bez wprowadzania rozproszonej eksploatacji. Mikroserwisy mają sens tam, gdzie niezależne zespoły, profile obciążenia lub cykle dostarczania przynoszą uzasadnioną korzyść. Decyzję dokumentujemy wraz z jej konsekwencjami dla eksploatacji, zamiast wybierać architekturę wyłącznie dlatego, że jest modna.

Możliwy zakres usług

Podział na domeny metodą Event Storming i Bounded Context wspólnie z działem biznesowym
Platforma na Kubernetes z Helm, wdrożeniami GitOps i przestrzeniami nazw dla każdego zespołu
Komunikacja między usługami przez REST, gRPC lub wiadomości, z warstwą Service Mesh do szyfrowania i routingu
Przechowywanie danych dla każdej usługi z wzorcem Saga i Outbox dla transakcji rozproszonych
Reguły eksploatacji dla logowania zdarzeń, konfiguracji, danych poufnych i odporności na awarie

Konkretny zakres, Państwa udział i kryteria odbioru ustalamy przed rozpoczęciem.

Technika przedstawiona w zrozumiały sposób

Jak realizujemy to zadanie.

Rozproszenie zmienia transakcje i błędy

Operacja obejmująca kilka usług nie ma automatycznie wspólnej transakcji bazodanowej. Planujemy przejścia stanów, tymczasową niespójność i działania kompensujące. Wzorzec outbox może pomóc w spójnym powiązaniu zmiany danych z publikowanym zdarzeniem. Ponowne próby wymagają biznesowej idempotentności, czyli zdefiniowanego wyniku przy ponownym przetworzeniu. Limity czasowe i zależności są ograniczane, aby wolna usługa nie blokowała całego łańcucha. Te reguły muszą być zrozumiałe i testowalne dla zaangażowanych zespołów.

Zapewnienie gotowości operacyjnej przed dalszym podziałem

Nowa usługa wymaga przypisanej odpowiedzialności, monitorowania, konfiguracji i bezpiecznego wdrażania. Testujemy wybrane awarie częściowe i obserwujemy pełne procesy, a nie tylko poszczególne kontenery. Przekazanie obejmuje decyzje architektoniczne, kontrakty interfejsów oraz runbooki. Istniejące wąskie gardła, struktura zespołów i zależności między wydaniami są najważniejszą podstawą pierwszej oceny.

Wynik możliwy do zweryfikowania

Z tym mogą Państwo dalej pracować.

Model domenowy z podziałem na usługi i interfejsami
Platforma z pipeline'em wdrożeniowym jako kod
Podręcznik eksploatacji z regułami dla każdej usługi

Przekazanie łączy realizację z dokumentacją. Wspólnie sprawdzamy uzgodnione przypadki i zapisujemy pozostałe zadania.

Państwa przedsięwzięcie w szczegółach

Wyznaczanie granic usług tam, gdzie pomagają Państwa produktowi.

Sprawdzamy, które części aplikacji powinny być zmieniane i eksploatowane niezależnie od siebie. Mikroserwisy są jedną z możliwych decyzji architektonicznych; decydujące są granice biznesowe, odpowiedzialność zespołów i procesy eksploatacyjne, nad którymi można zapanować.

Wyjaśnienie odpowiedzialności i własności danych przed podziałem technicznym

Usługa musi mieć zrozumiałe zadanie biznesowe. Analizujemy procesy, własność danych i zależności między zmianami, zanim komponenty zostaną wyodrębnione. Jeśli kilka usług współdzieli te same tabele i musi być zawsze wdrażanych razem, często powstaje tylko rozproszona zależność bez pożądanej korzyści.

Odróżniamy synchroniczne zapytania od asynchronicznych kroków procesu. Dla procesów biznesowych obejmujących wiele usług wyraźnie modelujemy stany przejściowe i mechanizmy kompensacji. Anulowanie rezerwacji jest na przykład działaniem biznesowym, a nie dowolnym technicznym rollbackiem obejmującym wszystkie bazy danych.

Widoczność i obsługa rozproszonych błędów

Przy wielu usługach pojawiają się dodatkowe ścieżki sieciowe i możliwe częściowe awarie. Planujemy limity czasu, ograniczenia i ponowne próby tak, aby wolna usługa nie blokowała całej aplikacji. Automatyczne ponawianie wymaga pewności, że dana operacja nie zostanie niezamierzenie wykonana wielokrotnie.

Wprowadzenie odbywa się w wyodrębnionym obszarze o wymiernej korzyści. Wspólne standardy dotyczące logów, śledzenia, wdrażania i dyżurów zapobiegają sytuacji, w której każda usługa wymyśla własne reguły eksploatacji. Jeśli oczekiwana korzyść nie uzasadnia nakładu pracy, lepszym rozwiązaniem może pozostać jasno zbudowana aplikacja modułowa.

Poglądowy scenariusz projektu

Jak usługa pomaga w codziennej pracy.

Przykład: generowanie dokumentów spowalnia aplikację specjalistyczną w momentach szczytowego obciążenia. Analizujemy biznesowe i techniczne zależności generowania dokumentów i w razie potrzeby wyodrębniamy właśnie ten proces. Wynik jest udostępniany za pomocą jednoznacznego statusu zadania, podczas gdy proces główny działa dalej w sposób kontrolowany.

Ten przykład opisuje możliwy przebieg i nie jest referencją klienta.

Przed pierwszym krokiem

Mikroserwisy: Państwa pytania.

Czy musimy w tym celu wdrożyć Kubernetes?

Nie. Model eksploatacji zależy od liczby usług, ich skalowania i wymagań. Kubernetes może być dobrym rozwiązaniem, ale nie jest warunkiem koniecznym dla biznesowo rozdzielonych aplikacji.

Czy dzięki temu rozwój oprogramowania zawsze przebiega szybciej?

Nie. Systemy rozproszone wymagają dodatkowej koordynacji i eksploatacji. Korzyści oceniamy na podstawie Państwa rzeczywistych zależności i wąskich gardeł.

Państwa przedsięwzięcie

Jakie zadanie chcą Państwo rozwiązać?

Proszę opisać swoją sytuację wyjściową i oczekiwany wynik. Wybrana usługa zostanie uwzględniona w zapytaniu kontaktowym.

Zapytaj o tę usługę

Menu

Rozdzielić systemy, zanim zależności zaczną spowalniać pracę.