Wyślij zapytanie Dołącz do Sii

Wielu z Was zapewne nie raz spotkała się z systemem wykorzystującym architekturę monolitu. Na początku prac nad projektem IT, jest to jedno z najlepszych rozwiązań ze względu na prostotę oraz łatwość w projektowaniu, a to wszystko dzięki braku zbędnych powiązań.

Im dłużej jednak projekt żyje, tym bardziej system się rozrasta. Dochodzą nowe funkcjonalności, nowe zależności, a kodu w monolicie przybywa, co nie ułatwia, a wręcz znacznie utrudnia pracę z takim projektem. Niektórzy określają taki monolit „wielką kulą błota”, ponieważ cała implementacja znajduje się w jednym projekcie, a zależności pomiędzy rożnymi bibliotekami przeplatają się w wielu klasach.

Aby poprawić jakość takiego systemu zgodnie ze sztuką refaktoryzacji, oczywistym krokiem byłoby rozbicie monolitu na moduły w wybranym przez nas kierunku podziału. Co jeśli jednak klient wymaga dodania nowej funkcjonalności do projektu i nie chce czekać, aż uporamy się z refaktoryzacją? Argumentów blokujących refaktoryzację, która z reguły dla klienta jest zbędną stratą czasu, może być dużo więcej, ale oczekiwanie na nową funkcjonalność pozostaje.

Zmiana technologii z WCF na gRPC

Taka sytuacja spotkała mnie bardzo krótko po dołączeniu do projektu. Nie chcąc komplikować już i tak sporego kawałka kodu, w którym rozszerzenie miało być wykorzystywane, przygotowałem najpierw propozycję zmian, ale w taki sposób, żeby jego implementacja znajdowała się poza aktualnym projektem. Dodatkowo, przygotowałem dla klienta propozycję wykorzystywania technologii innej niż WCF, która była używana do tamtej chwili.

Istotnym argumentem za zmianą technologii był koniec wsparcia dla WCF ze strony Microsoftu. Wybór padł na gRPC ze względu na podobieństwo do WCF. Taka argumentacja uświadomiła klientowi, że trzeba rozpocząć przepisywanie systemu na nowszą technologię. Zwróciłem uwagę klienta również na to, że warto zacząć to robić stopniowo, z możliwością równoległej pracy starego systemu opartego na WCF oraz systemu, który będzie zawierał te same funkcjonalności lub nowe, jednak wykorzystujące już technologię gRPC.

Schemat wymiany danych w protokole gRPC
Ryc. 1 Schemat wymiany danych w protokole gRPC

Czym jest gRPC i dlaczego warto z niego korzystać?

gRPC jest to system zdalnego wywołania procedur (Remote Procedure Call), pierwotnie opracowany przez Google. Gdy system ten stał się już dojrzały, został udostępniony w ramach projektu typu open-source. Taki krok pozwolił protokołowi zyskać popularność oraz wsparcie ze strony społeczności, a to przyciągnęło do niego jeszcze większą rzeszę zwolenników.

gRPC jest wykorzystywane m.in. przez Netflix i Cisco, co potwierdza potencjał tej technologii. Dużym plusem dla programistów WCF jest również podobieństwo w definiowaniu kontraktu wymiany informacji pomiędzy dostawcą i odbiorcą. W przypadku gRPC kontrakt jest zdefiniowany z użyciem specjalnego języka „Proto” oraz przetrzymywany w pliku o rozszerzeniu *.proto. Istnieje jednak możliwość implementacji kontraktu w niemal identyczny sposób jak odbywa się to w WCF, jednak trzeba zachować kilka reguł. Więcej informacji można znaleźć w materiałach.

Zastosowanie gRPC w działającym systemie

Aby umożliwić wykorzystanie gRPC w aktualnie działającym systemie, zastosowałem wzorzec projektowy Pośrednik (Proxy). Zakłada on wykorzystanie obiektu pośredniczącego pomiędzy klientem, który wywołuje operację a rzeczywistym obiektem, który zapewnia wymaganą funkcjonalność. Taka architektura przydaje się, gdy nie chcemy wiązać się z konkretnym obiektem po stronie klienta lub gdy rzeczywisty obiekt znajduje się na zdalnym systemie.

Diagram klas dla wzorca pośrednik
Ryc. 2 Diagram klas dla wzorca pośrednik

Do istniejącej już solucji dodałem projekt biblioteki typu .NET Standard 2.1. Taka wersja frameworku pozwoliła na użycie technologii gRPC w oparciu o ASP.NET oraz jego referencję w głównym projekcie (monolicie), który wykorzystuje .NET Framework 4.7.

W nowym projekcie zaimplementowany został obiekt Proxy, który jednocześnie jest klientem gRPC. Jego implementacja składa się z kilku metod, które wykorzystują klienta gRPC. W starym projekcie, wykorzystującym WCF, tworzona jest instancja obiektu Proxy, która, po wywołaniu odpowiedniej metody, pośredniczy w wysłaniu prośby o wykonanie zdalnej procedury do serwera gRPC, a następnie konsumuje otrzymane informacje w celu przygotowania odpowiedzi.

Ponieważ w technologii gRPC komunikacja pomiędzy klientem, a serwerem odbywa się poprzez protokół HTTP, serwer gRPC może być umieszczony w dowolnym miejscu, a technologia użyta do jego implementacji nie jest ograniczona przez technologię użytą do implementacji klienta.

Diagram sekwencji z uwzględnieniem pośrednika i mikroserwisów
Ryc. 3 Diagram sekwencji z uwzględnieniem pośrednika i mikroserwisów

Uniezależnienie od wcześniejszych decyzji projektowych

Nowa funkcjonalność, której dodania wymagał od nas klient, została zaimplementowana w ramach serwera gRPC. W naszym przypadku serwer początkowo działał jako lokalny serwis Windowsa, wykorzystujący technologię ASP.NET 5 i hostowany był za pomocą wbudowanego serwera Kestrel. Ograniczyło to instalowanie dodatkowych serwerów WWW oraz ich administrację. Aby jeszcze bardziej uniezależnić się od narzuconych wcześniej decyzji projektowych, aktualnie serwer gRPC działa w kontenerze Docker. Zaletą takiego rozwiązania jest możliwość hostowania serwisu, który jest częścią naszego systemu na innych maszynach niż lokalny serwer, jak również w chmurze.

gRPC – co dalej?

Na ten moment system posiada już 3 osobne mikroserwisy, które przez cały czas są rozwijane i usprawniane. Opisana tutaj architektura pozwala na rozwój funkcjonalności istniejącego już systemu oraz na możliwość przeprowadzenia równoległych prac nad przepisaniem systemu z działającego w technologii WCF do gRPC.

Docelowo, cały system będzie hostowany w chmurze, jednak jego migracja następuje stopniowo. Krokiem pośrednim będzie hostowanie mikroserwisów w kontenerach w infrastrukturze chmury, a część systemu nadal będzie hostowana w lokalnej infrastrukturze.

Możliwość korzystania z najnowszych technologii zachęci dodatkowe osoby do pracy w naszym projekcie, ponieważ WCF już od jakiegoś czasu nie jest wykorzystywany w nowych projektach. Również brak ograniczeń architektonicznych przez użycie technologii gRPC zwiększa swobodę w rozbudowie zespołu o osoby nie mające wcześniej do czynienia z technologią Microsoft WCF, a nawet z .NET Framework.

5/5 ( głosy: 7)
Ocena:
5/5 ( głosy: 7)
Autor
Avatar
Szymon Urbański

Programista z doświadczeniem w produkcji i utrzymaniu systemów dla przemysłu ciężkiego, medycznego i finansowego. Praca z LegacyCode stała się dla niego formą specjalizacji – podczas gdy wiele osób obawia się pracy z nie swoim kodem, dla niego to świetna zabawa, ponieważ w jej trakcie pojawia się wiele pytań typu: Co autor miał na myśli?

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?