Architektura mikrousług - plan
Firma Microservice wewnętrznie implementuje architekturę SOA. W szerszym sensie możemy go traktować jako podzbiór jednej aplikacji SOA.
Reguła i przepływ pracy
Poniżej przedstawiono zasady, o które należy zadbać przy tworzeniu mikrousługi.
High Cohesion- Wszystkie modele biznesowe należy w jak największym stopniu podzielić na najmniejszą część biznesową. Każda usługa powinna być skoncentrowana na wykonywaniu tylko jednego zadania biznesowego.
Independent - Wszystkie usługi powinny mieć charakter pełnego stosu i być od siebie niezależne.
Business Domain Centric - Oprogramowanie będzie ulegać modularyzacji w zależności od jednostki biznesowej i nie jest oparte na warstwach.
Automation- Wdrażanie testów zostanie zautomatyzowane. Spróbuj wprowadzić minimalną interakcję międzyludzką.
Observable - Każda usługa będzie miała charakter pełnego stosu i powinna być niezależnie wdrażana i obserwowalna, jak aplikacja korporacyjna.
Zarządzanie zespołem
„Dwie reguły pizzy” to rodzaj reguły, która ogranicza liczbę uczestników w zespole programistów mikrousług. Zgodnie z tą zasadą liczba osób w zespole jednej aplikacji powinna być na tyle mała, aby można było ich karmić dwoma pizzami. Generalnie liczba nie powinna być większa niż 8. Ponieważ mikrousługa ma charakter pełnego stosu, zespół ma również charakter pełnego stosu. Aby zwiększyć produktywność, musimy zbudować jeden zespół składający się maksymalnie z 8 członków z wszelkiego rodzaju wiedzą wymaganą do tej usługi.
Zarządzanie zadaniami
Zadanie odgrywa ważną rolę w cyklu życia oprogramowania. Tworzenie aplikacji na dużą skalę można podzielić na kilka małych jednostek zadań. Rozważmy, że musimy stworzyć jedną aplikację, taką jak Facebook. Następnie funkcjonalność „Zaloguj się” można traktować jako zadanie całego procesu kompilacji. Postęp w każdym z tych zadań musi być odpowiednio monitorowany przez wysoko wykwalifikowanych specjalistów. Agile to dobrze znana struktura procesów stosowana w branżach, która zapewnia dobre zarządzanie zadaniami.