Witam wszystkich!
Jesteśmy społecznością programistów .NET w Raiffeisenbank i chcemy porozmawiać o zestawie bibliotek infrastrukturalnych opartych na .NET Core do szybkiego tworzenia mikrousług w jednym ekosystemie. Wprowadzili to na Open Source!
Trochę historii
Dawno, dawno temu mieliśmy duży monolityczny projekt, który stopniowo przekształcił się w zestaw mikroserwisów (o cechach tego procesu możesz przeczytać w ). Przy okazji napotkaliśmy problem polegający na tym, że tworząc nowe mikroserwisy często musieliśmy kopiować różne rozwiązania infrastrukturalne – takie jak konfiguracja logowania, praca z bazą danych, WCF itp. Nad projektem pracował jeden zespół i wszyscy byli już przyzwyczajeni do pewnego ustalonego podejścia do pracy z infrastrukturą. Dlatego też rozdzieliliśmy wspólny kod do osobnego repozytorium, opakowaliśmy zebrane biblioteki w pakiety Nuget i umieściliśmy je w naszym wewnętrznym repozytorium Nuget.
Czas mijał, projekt stopniowo się fragmentaryzował i pojawiła się chęć stworzenia nowych modułów po stronie klienta na nowoczesnym frameworku JS i uruchomienia ich w przeglądarce. Zaczęliśmy przechodzić z WCF/SOAP na REST/HTTP, dlatego potrzebowaliśmy nowych bibliotek, aby szybko uruchamiać usługi oparte na AspNet WebApi. Pierwszą wersję na .Net Framework 4.5 nasz architekt w wolnym czasie wykonywał niemal na kolanach, ale od razu po wyjęciu z pudełka umożliwiła uruchomienie usługi z trzema linijkami w Program.cs zawierającymi autoryzację (NTLM), logowanie, Swagger, IoC/DI w oparciu o Castle Windsor, niestandardowi klienci HTTP, którzy przekazują różne nagłówki, aby zapewnić kompleksowe rejestrowanie w całym projekcie. Całość można dodatkowo skonfigurować bezpośrednio w pliku konfiguracyjnym usługi.
Nie wszystko jednak poszło gładko: biblioteka ta okazała się wyjątkowo mało elastyczna, jeśli chodzi o wprowadzanie nowych modułów. Na przykład, jeśli trzeba było dodać specjalne oprogramowanie pośredniczące, trzeba było utworzyć nowy zestaw i dziedziczyć z klasy bazowej, która uruchamia usługę, co było wyjątkowo niewygodne. Na szczęście takich przypadków nie było zbyt wiele.
Era Dockera i Kubernetesa
Nadszedł czas, kiedy dotarła do nas fala Dockera i Kubernetesa, czemu bacznie się przyglądaliśmy: w końcu była to świetna szansa, aby zacząć iść dalej w technologiach, w .Net Core. Oznacza to, że do uruchomienia usług będziemy potrzebować nowej infrastruktury: część bibliotek migrowała z .Net Framework do .Net Standard i .Net Core praktycznie bez zmian, niektóre z niewielkimi ulepszeniami. Ale przede wszystkim chciałem przerobić funkcjonalność związaną z uruchamianiem usług na AspNet Core.
Pierwszą rzeczą, którą rozważaliśmy, była koncepcja, która usunie główną wadę poprzedniej wersji: brak elastyczności. Dlatego zdecydowano się uczynić cały system biblioteczny możliwie jak najbardziej niezależnym i modułowym oraz zebrać usługi niezbędne do funkcjonalności jako konstruktor.
Głównym celem jest stworzenie ujednoliconego podejścia opisującego sposób interakcji z bazami danych, autobusami i innymi usługami. Staraliśmy się, aby integracje były szybkie i bezbolesne, a programiści mogli skoncentrować się na pisaniu logiki biznesowej, a nie infrastruktury - jest już gotowa. Wspólne repozytorium pomaga poprawić jakość interakcji w zespołach: gdy korzysta się z bardzo podobnej infrastruktury wewnętrznej, łatwiej jest włączyć się w proces rozwoju innego zespołu i wymieniać się wiedzą.
I dlaczego potrzebujemy Open Source?
Chcemy pokazać dojrzałość naszej wiedzy i otrzymać wysokiej jakości informację zwrotną: osoba spoza banku będzie mogła wnieść coś od siebie. Jesteśmy również zainteresowani rozwojem praktyk pracy z mikroserwisami i DDD na .NET w branży, być może ktoś będzie chciał przejąć pewne części frameworka.
Właściwie ViennaNET
Teraz przyjrzyjmy się bliżej. .
ViennaNET.WebApi.*
Ten zestaw bibliotek składa się z „rootowej” biblioteki ViennaNET.WebApi, zawierającej klasę budowniczego dla usługi CompanyHostBuilder oraz zestawu konfiguratorów ViennaNET.WebApi.Configurators.*, z których każdy umożliwia dodawanie i konfigurowanie niektórych funkcjonalności do utworzonego praca. Wśród konfiguratorów można znaleźć połączenia do logowania, diagnostyki, typów uwierzytelniania i autoryzacji, swagger itp.
ViennaNET.WebApi.Runners.* zawiera również wstępnie skonfigurowane kreatory usług. Pakiety te pozwalają nie pamiętać za każdym razem, gdy tworzysz nową usługę, które konfiguratory należy podłączyć. Nie ograniczają one jednak w żaden sposób funkcjonalności kreatora usług.
ViennaNET.Mediator.*
Biblioteki umożliwiające utworzenie wewnętrznej magistrali pośredniczącej dla poleceń i żądań w ramach usługi. Takie podejście pozwala zredukować ilość wtrysków DI do jednego np. w sterownikach. Dzięki temu do żądań można dodawać różne dekoratory, co ujednolica ich przetwarzanie i zmniejsza ilość kodu.
Walidacja ViennaNET
Zestaw zawierający zestaw klas do tworzenia reguł walidacji i sekwencji z nich. Jest to bardzo wygodne przy realizacji walidacji domeny, gdyż pozwala opisać każdy warunek biznesowy w formie prostej i osobnej reguły.
WiedeńNET.Redis
Biblioteka z opakowaniami do wygodnej pracy z Redisem jako pamięcią podręczną w pamięci.
Dane techniczne ViennaNET
Zestaw zawierający klasy, które implementują wzorzec specyfikacji.
To nie wszystko, co znajduje się w naszym zestawie. Resztę możesz zobaczyć . Planujemy wkrótce udostępnić nasze biblioteki do pracy z bazami danych w środowisku OpenSource.
Dziękujemy za uwagę, czekamy na Twoje komentarze i prośby o ściągnięcie.
Źródło: www.habr.com