Myślę, że może to być nieco bardziej teoretyczne. Jednym z motywujących pomysłów mikrousług jest wspólny proces przekazywania wiadomości. Mikrousługa jest jak aktor w modelu aktora. Oznacza to, że każdy proces utrzymuje swój stan lokalny, a jedynym sposobem na uzyskanie dostępu do stanu innego procesu jest wysłanie wiadomości (i nawet wtedy drugi proces może odpowiedzieć, jak chce na te wiadomości). Pod pojęciem „każda mikrousługa ma swoją własną bazę danych”, tak naprawdę stan procesu (tj. Mikrousługa) jest lokalny i prywatny . W dużej mierze sugeruje to, że „baza danych” powinna być kolokowanaz mikrousługą, tj. „baza danych” powinna być przechowywana i wykonywana w tym samym węźle logicznym co mikrousługa. Różne „instancje” mikrousług są osobnymi procesami, dlatego też każda powinna mieć własną „bazę danych”.
Globalna baza danych lub baza danych współdzielona między mikrousługami, a nawet instancjami mikrousług, stanowiłaby z tego punktu widzenia stan współdzielony. „Odpowiednim” sposobem na poradzenie sobie z tym z perspektywy mikrousług jest udostępnianie wspólnej bazy danych za pośrednictwem mikrousług „bazy danych”. Inne mikrousługi, które chciałyby wiedzieć o zawartości bazy danych, wysyłałyby wiadomości do tej „mikrousługi bazy danych”. Zazwyczaj nie eliminuje to potrzeby stanu lokalnego (tj. „Baz danych” instancji mikrousług) dla oryginalnych mikrousług! Jakie zmiany reprezentuje ten stan lokalny. Zamiast przechowywać „User Sally jest administratorem”, zapisuje „Mikrousługa bazy danych powiedziała„ User Sally jest administratorem pięć minut temu ”. Innymi słowy, o stanie innych mikrousług.
Zaletą tego jest to, że każda mikrousługa jest samodzielna. To sprawia, że mikrousługa jest atomową jednostką awarii. (W większości) nie musisz się martwić o mikrousługę w częściowo częściowo funkcjonalnym stanie. Oczywiście problem został przeniesiony do sieci mikrousług. Mikrousługa może nie być w stanie wykonać żądanej funkcji z powodu niemożności skontaktowania się z innymi mikrousługami. Korzyścią jest jednak to, że mikrousługa będzie w dobrze zdefiniowanym stanie i może być w stanie oferować usługi o obniżonej jakości lub ograniczone, np. Poprzez wypracowanie przestarzałych przekonań. Minusem jest to, że bardzo trudno jest uzyskać spójną migawkę systemu jako całości i może być dość (niepożądana) redundancja i duplikacja.
Oczywiście nie sugeruje się umieszczania instancji Oracle w każdym kontenerze Docker. Po pierwsze, nie każda mikrousługa potrzebuje „bazy danych”. Niektóre procesy nie wymagają żadnego trwałego stanu do poprawnego działania. Na przykład mikrousługa, która tłumaczy dwa protokoły, niekoniecznie potrzebuje żadnego trwałego stanu. Gdy bowiem potrzebny jest stan trwały, słowo „baza danych” to tylko słowo „stan trwały”. Może to być plik z JSON, baza danych Sqlite lub lokalnie działająca kopia Oracle, jeśli chcesz, lub dowolny inny sposób lokalnietrwałe przechowywanie danych. Jeśli „baza danych” nie jest lokalna, to z perspektywy czystych mikrousług należy ją traktować jak osobną (mikro) usługę. W tym celu nigdy nie ma sensu, aby instancja RDS była „bazą danych” dla mikrousług. Ponownie, perspektywa nie polega na „grupie mikrousług z ich własnymi bazami danych RDS”, ale „grupie mikrousług, które komunikują się z bazami danych RDS”. W tym momencie nie ma znaczenia, czy dane są przechowywane w tej samej instancji bazy danych, czy nie.
Pragmatycznie architektura mikrousług powoduje ogromną złożoność. Ta złożoność to tylko cena poważnego radzenia sobie z częściową awarią. Dla wielu jest to przesada, która prawdopodobnie nie jest warta korzyści. Powinieneś swobodnie projektować swój system w jakikolwiek sposób, który wydaje się najbardziej korzystny. Istnieje duża szansa, że obawy związane z prostotą i wydajnością mogą prowadzić do odchyleń od architektury czystej mikrousług. Kosztem będzie dodatkowe sprzężenie, które wprowadza własne złożoności, takie jak niewidoczne interakcje między usługami oraz ograniczenia swobody wdrażania i skalowania według własnego uznania.