Mikroserwisy w akcji. Отсутствует
systemu, który jest celem budowy.
Rozmyślna symbioza ze strukturą organizacyjną jest jednym z przykładów powszechnej praktyki w zakresie mikroserwisów. Aby móc czerpać korzyści z mikroserwisów i odpowiednio zarządzać ich złożonością, trzeba opracować zasady działania i praktyki, które są skuteczne dla tego typu aplikacji, zamiast używać takich samych technik jak do budowy monolitów.
■ Mikroserwisy są zarówno stylem architektonicznym, jak i zestawem praktyk kulturowych, opartych na pięciu kluczowych zasadach: autonomii, odporności, przejrzystości, automatyzacji i ukierunkowaniu.
■ Mikroserwisy zmniejszają tarcia w rozwoju, umożliwiając autonomię, elastyczność techniczną i luźne powiązania.
■ Projektowanie mikroserwisów może być trudne ze względu na potrzebę odpowiedniej wiedzy o domenie oraz równoważeniu priorytetów w zespołach.
■ Usługi wystawiają kontrakty dla innych usług. Dobre kontrakty są zwięzłe, kompletne i przewidywalne.
■ Złożoność w długo funkcjonujących systemach oprogramowania jest nieunikniona, ale można zapewnić ich zrównoważony rozwój, jeśli zostaną dokonane wybory, które minimalizują tarcia i ryzyka.
■ Niezawodne wdrażanie bez incydentów (nudne) zmniejsza ryzyka związane z mikroserwisami, dzięki automatycznym i zweryfikowanym wydaniom.
■ Kontenery przesłaniają różnice między usługami w trakcie wykonywania, upraszczając zarządzanie heterogenicznymi mikroserwisami na dużą skalę.
■ Awaria jest nieunikniona – mikroserwisy muszą być przejrzyste i możliwe do obserwowania dla zespołów, które proaktywnie zarządzają, rozumieją i obsługują działanie usług … oraz ich brak.
■ Zespoły wdrażające mikroserwisy muszą być operacyjnie dojrzałe i skupiać się na całym cyklu życia usługi, nie tylko na etapie projektowania i budowy.
2. Mikroserwisy w SimpleBanku
Niniejszy rozdział dotyczy:
■ przedstawienia SimpleBanku, firmy, która wprowadza mikroserwisy;
■ projektowania nowej funkcjonalności za pomocą mikroserwisów;
■ udostępniania światu funkcjonalności opartych na mikroserwisach;
■ sprawdzania, czy funkcjonalności są gotowe do produkcji;
■ wyzwań stojących przed skalowaniem sposobu wdrażania mikroserwisów.
Z rozdziału 1 dowiedzieliśmy się o kluczowych zasadach mikroserwisów oraz dlaczego są one atrakcyjnym podejściem do zrównoważonego dostarczania oprogramowania. Wprowadziliśmy również praktyki w zakresie projektowania i rozwoju, które stanowią podstawę tworzenia mikroserwisów. W tym rozdziale omówimy, w jaki sposób można zastosować te zasady i praktyki w celu opracowania za pomocą mikroserwisów nowych funkcjonalności produktu.
W tym rozdziale przedstawimy fikcyjną firmę SimpleBank. To firma z wielkimi planami zmiany świata inwestycji, dla których pracujemy jako inżynier. Zespół inżynierów SimpleBanku chce móc szybko dostarczać nowe funkcjonalności, zapewniając jednocześnie skalowalność i stabilność – w końcu mają do czynienia z cudzymi pieniędzmi! Mikroserwisy mogą być dokładnie tym, czego potrzebują.
Budowa i uruchamianie aplikacji składającej się z niezależnie wdrażanych i autonomicznych usług to zupełnie inne wyzwanie niż zbudowanie tej aplikacji jako pojedynczej jednostki monolitycznej. Zaczniemy od rozważenia, dlaczego architektura mikroserwisowa może być odpowiednia dla SimpleBanku, a następnie przejdziemy przez projekt nowej funkcjonalności z użyciem mikroserwisów. Na koniec określimy kroki potrzebne do opracowania proof of concept w aplikacji klasy produkcyjnej. Zaczynamy.
2.1. Czym zajmuje się SimpleBank?
Członkowie zespołu SimpleBanku chcą zaoferować inteligentne inwestycje finansowe każdemu, bez względu na to, ile ma pieniędzy. Uważają, że kupowanie akcji, sprzedaż funduszy lub handel walutami powinny być tak proste, jak otwarcie konta oszczędnościowego.
To ważna misja, ale niełatwa. Produkty finansowe mają wiele wymiarów złożoności – SimpleBank będzie musiał zrozumieć zasady rynkowe i skomplikowane przepisy, a także zintegrować się z istniejącymi systemami branżowymi, jednocześnie spełniając rygorystyczne wymagania dotyczące jakości.
W poprzednim rozdziale określiliśmy niektóre funkcjonalności oferowane przez SimpleBank klientom: otwieranie rachunków, zarządzanie płatnościami, składanie zleceń i modelowanie ryzyka. Rozwińmy te możliwości i zobaczmy, jak mogą one pasować do szerszego zakresu narzędzia inwestycyjnego. Na rysunku 2.1 ilustrowano różne elementy tego zakresu.
Rysunek 2.1. Ogólny (i w żadnym razie niewyczerpujący) model funkcjonalności, który mógłby zbudować SimpleBank
Jak widać na rysunku, narzędzie inwestycyjne będzie musiało robić więcej, niż tylko oferować funkcjonalności związane z klientem, takie jak możliwość otwierania rachunków i zarządzania portfelem finansowym. Będzie musiało również zarządzać zasobami, czyli tym, w jaki sposób bank utrzymuje aktywa w imieniu klientów i przenosi w ich lub poza ich posiadanie oraz tworzeniem produktów finansowych odpowiednich do potrzeb klientów.
Jak widać, nie jest to takie proste! Możemy zacząć dostrzegać niektóre zdolności biznesowe, które mogą zostać wdrożone przez SimpleBank: zarządzanie portfelem, integracja danych rynkowych, zarządzanie zleceniami, tworzenie funduszy i analiza portfela. Każdy ze wskazanych obszarów biznesowych może się składać z dowolnej liczby usług współpracujących ze sobą lub z usługami w innych obszarach.
Tego typu ogólny model zakresu jest przydatnym pierwszym krokiem przy tworzeniu koncepcji dowolnego systemu, natomiast kluczowe znaczenie ma przy budowaniu mikroserwisów. Bez zrozumienia tego zakresu można podejmować błędne decyzje dotyczące granic usług. Nie chcemy budować usług anemicznych – istniejących tylko w celu wykonywania prostych operacji tworzenia, odczytu, aktualizacji i usuwania (CRUD). Często stają się one źródłem silnego sprzężenia w aplikacji. Jednocześnie chcemy uniknąć umieszczania nadmiernej odpowiedzialności w ramach jednej usługi. Mniej spójne usługi powodują, że zmiany w oprogramowaniu są wolniejsze i bardziej ryzykowne – dokładnie to, czego próbujemy uniknąć.
Wreszcie, bez tego spojrzenia możemy paść ofiarą na wyrost zaprojektowanego narzędzia – wyboru mikroserwisów tam, gdzie nie jest to uzasadnione przez rzeczywistą złożoność produktu lub zastosowania.
2.2. Czy mikroserwisy są dobrym wyborem?
Inżynierowie z SimpleBank uważają, że mikroserwisy to najlepszy wybór, pozwala bowiem poradzić sobie ze złożonością dziedziny i być elastycznym wobec złożonych i zmieniających się wymagań. Przewidują, że w miarę rozwoju działalności firmy mikroserwisy zmniejszą ryzyko zmian w oprogramowaniu, prowadząc do lepszego produktu i zadowolenia klientów.
Załóżmy na przykład, że trzeba będzie przetwarzać każdą transakcję kupna lub sprzedaży, aby określić skutki podatkowe. Jednak zasady podatkowe w każdym kraju są inne i często się zmieniają. W aplikacji monolitycznej musielibyśmy wprowadzić skoordynowane zmiany, w odpowiednim momencie wydania całej platformy, nawet jeśli chcielibyśmy wprowadzić te zmiany tylko w jednym kraju. W aplikacji mikroserwisowej możemy budować autonomiczne usługi obsługi podatków (zależne od kraju, rodzaju podatku, rodzaju rachunku) i wdrażać je niezależnie.
Czy SimpleBank dokonuje właściwego wyboru? Wybór architektury oprogramowania zawsze wiąże się