Podsumowanie projektu inżynierskiego – architektura mikroserwisowa

Od kliku miesięcy projekt inżynierski zajmował 90% czasu, który mogłem poświęcić na programowanie po godzinach. Oficjalnie projekt nosił nazwę „Architektura mikroserwisowa na przykładzie aplikacji do komunikacji”. Na początku nieco obawiałem się podejmować problem (czyt. mikroserwisy), który znałem tylko teoretycznie, ale po pewnym czasie przekonałem się, że nie taki diabeł straszny jak go malują. Wykonane odpowiednio wcześnie planowanie oraz wczesne rozpoczęcie projektu pozwoliło mi na zrealizowanie go z dużym zapasem czasowym. Cały proces rozwijania architektury był bardzo przyjemny, ponieważ połączyłem zagadnienie, które interesuje mnie od dłuższego czasu z wizją, że zdobytą wiedzę będę mógł wykorzystać poza murami uczelni. Sytuacja win-win.

Zarządzanie projektem

Od początku trwania projektu zakładałem, że nie będę stosował żadnej metodologii zarządzania projektem. Jedyne co wiedziałem to to, że będę używał aplikacji Trello ze standardowym przepływem zadań: TO DO – IN PROGRESS – DONE (każdy tydzień miał tworzoną osobną kolumnę DONE w celu wygodniejszego przeglądania całej listy). Z czasem dodałem kolejne kolumny: KNOWN BUGS dla błędów, które musiałem rozwiązać, ale nie chciałem się zajmować nimi w danej chwili oraz REFACTORING PLAN dla zadań wchodzących w skład szeroko pojętej refaktoryzacji, którą wykonywałem pod koniec realizacji projektu.

Łącznie tablica została wypełniona 111 zadaniami, z których 109 zostało wykonanych.

Użycie aplikacji Trello było (po raz kolejny) strzałem w 10. Cały czas miałem poczucie, że panuję nad realizacją projektu oraz nie muszę pamiętać o dodatkowych zadaniach – wszystko było na tablicy.

Kształt architektury

Przy opisie architektury zacznę od samego początku. Wszystkie serwisy uruchamiane były w systemie Linux Ubuntu, który to był wirtualizowany za pomocą narzędzia Vagrant. Aplikacje korzystały z dwóch baz danych MySQL oraz PostgreSQL uruchomionych jako kontenery Docker.

Długo zastanawiałem się nad poziomem granulacji poszczególnych usług. Ostatecznie wybór padł na definiowanie usług na poziomie encji domenowych, ponieważ przy specyfice tego projektu o wiele bardziej zależało mi na poznaniu architektury od strony technicznej niż na poprawnym określeniu granic każdego serwisu.

Ostatecznie w skład architektury mikroserwisowej wchodziło 6 usług:

  1. gateway-service – usługa serwująca interfejs użytkownika oraz obsługująca zdarzenia w nim występujące
  2. user-service – usługa odpowiedzialna za zarządzanie użytkownikami
  3. contact-service – usługa odpowiedzialna za realizację logiki związanej z książką kontaktów użytkownika
  4. search-service – serwis mający za zadanie obsługę wyszukiwarki wiadomości
  5. folder-message-service – usługa odpowiedzialna za zarządzanie wiadomościami i folderami, ze względu na bliskość encji folderu i wiadomości postanowiłem zamknąć je w ramach jednego serwisu
  6. eureka-discovery-service – usługa będąca rejestrem wszystkich usług działających w systemie

W skład architektury wchodziła również aplikacja Central Authentication Service odpowiadająca za zarządzanie tożsamością użytkownika.

 

Opis technologii

Jak wspomniałem wcześniej, u podstaw całej architektury znajdował się Vagrant z systemem Linux Ubuntu oraz Docker.

Wszystkie mikroserwisy były to aplikacje u podstaw których stał Spring Boot. W zależności od potrzeba dokładane były kolejne projekty Spring: Data, Cloud, Security, MVC. Usługa odpowiedzialna za uwierzytelnianie (gateway-service) wykorzystywała dodatkowo bibliotekę Pac4J.

Rejestr wszystkich usług był realizowany za pomocą narzędzi spring-cloud-netflix oraz Eureka. Do odpowiedniej wymiany danych pomiędzy każdą z usług użyte zostało narzędzie Feign (spring-cloud-netflix Feign).

Do zarządzania zależnościami w poszczególnych aplikacjach użyto narzędzia Maven.

Interfejs graficzny został stworzony za pomocą HTML, CSS, jQuery, mustache.js (jedno z ciekawszych odkryć – zapewnia minimum potrzebne do realizacji SPA).

Testowanie

Aplikacja testowana była za pomocą 3 rodzajów testów. Pierwszymi z nich były testy jednostkowe, które powstawały równolegle do tworzonych funkcjonalności.

Kolejne to testy mutacyjne realizowane za pomocą narzędzia PIT. Miały one za zadanie sprawdzać jakość testów jednostkowych poprzez wprowadzanie mutacji w kodzie.

Ostatnimi były testy manualne, które były przeprowadzane przez cały cykl tworzenia aplikacji.

Błędy

W trakcie realizacji projektu podjąłem wiele decyzji, które w dłuższej perspektywie okazały się błędnymi.

Jednym z poważniejszych przeoczeń było nadużywanie usługi gateway-service w celu realizacji logiki biznesowej. Serwis ten wykonywał zdecydowanie za dużo, co więcej, zbyt wiele wiedział o pozostałych serwisach i ich odpowiedzialnościach.

Literatura

Pozycją, która w największym stopniu pomogła mi zrozumienie idei architektury mikroserwisowej oraz jej założeń była „Building microservices” (S. Newman). W celu lepszego zrozumienia praw rządzących w szeroko pojętym środowisku chmurowym posilałem się książką o tytule „Chmura obliczeniowa. Rozwiązania dla biznesu”.

Nieocenione okazały się dokumentacje projektów Spring, a w szczególności Cloud oraz Security.

Oczywiście całej literatury jest zdecydowanie więcej, ale chciałem wspomnieć tylko o pozycjach najbardziej przydatnych.

You may also like

Comments