Cześć wszystkim!
Jesteśmy społecznością programistów .NET z Raiffeisen Banku i chcemy opowiedzieć o zestawie bibliotek infrastrukturalnych na .NET Core, które umożliwiają szybkie tworzenie mikrousług w jednolitej ekosystemie. Udostępniliśmy to w Open Source!
Historia
Kiedyś mieliśmy duży monolityczny projekt, który stopniowo przekształcał się w zestaw mikrousług (szczegóły tego procesu można przeczytać w ). W trakcie realizacji napotkaliśmy problem, że przy tworzeniu nowych mikrousług często musieliśmy kopiować różne rozwiązania infrastrukturalne – takie jak konfiguracja logowania, praca z bazą danych, WCF itd. Nad tym projektem pracowała jedna ekipa, a wszyscy przyzwyczaili się do pewnego ustalonego podejścia do pracy z infrastrukturą. W związku z tym wydzieliliśmy wspólny kod do osobnego repozytorium, zbudowane biblioteki spakowaliśmy w pakiety Nuget i umieściliśmy w naszym wewnętrznym repozytorium Nuget.
Czas mijał, projekt nieco się rozdrabniał, pojawiła się chęć tworzenia nowych modułów części klienckiej w nowoczesnym frameworku Js i uruchamiania ich w przeglądarce. Zaczęliśmy przechodzić z WCF/SOAP na REST/HTTP, dlatego potrzebowaliśmy nowych bibliotek do szybkiego uruchamiania usług opartych na AspNet WebApi. Pierwsza wersja na .Net Framework 4.5 została stworzona przez naszego architekta niemal w wolnym czasie, ale już z pudełka pozwalała na uruchomienie usługi z autoryzacją (NTLM), logowaniem, Swaggerem, IoC/DI na bazie Castle Windsor oraz skonfigurowanymi klientami HTTP, przekazującymi różne nagłówki w celu zapewnienia pełnego logowania w całym projekcie. A wszystko to można było dodatkowo skonfigurować już bezpośrednio w pliku konfiguracyjnym usługi.
Jednak nie wszystko było gładkie: ta biblioteka okazała się niezwykle sztywna w kwestii wdrażania nowych modułów. Na przykład, aby dodać jakieś specjalne middleware, trzeba było stworzyć nową kompilację i dziedziczyć po klasie bazowej uruchamiającej usługę, co było niezwykle niewygodne. Na szczęście takich przypadków było niewiele.
Era Dockera i Kubernetesa
Nadeszła chwila, kiedy fala Dockera i Kubernetesa dotarła również do nas, na którą uważnie się przyglądaliśmy: był to doskonały moment, aby zainicjować postęp technologiczny w .Net Core. Oznacza to, że będziemy potrzebować nowej infrastruktury do uruchamiania usług: część bibliotek została przeniesiona z .Net Framework do .Net Standard i .Net Core praktycznie bez zmian, część z niewielkimi ulepszeniami. Najbardziej chcieliśmy przerobić funkcjonalność związaną z uruchamianiem usług na AspNet Core.
Na początku rozważany był koncept, który pozwoliłby usunąć główną wadę poprzedniej wersji: brak elastyczności. Dlatego postanowiono uczynić cały system bibliotek jak najbardziej niezależnym i modularnym, a usługi o odpowiedniej funkcjonalności składać jak klocki.
Głównym celem jest stworzenie zunifikowanego podejścia, które opisuje, jak współpracować z bazami danych, szynami i innymi usługami. Staraliśmy się, aby integracje były szybkie i bezproblemowe, a programiści mogli skupić się na pisaniu logiki biznesowej, a nie infrastruktury – ta jest już gotowa. Wspólny repozytorium pomaga poprawić doświadczenie pracy w zespołach: kiedy używane są bardzo podobne wewnętrzne infrastruktury, łatwiej włączyć się w proces rozwoju innego zespołu i wymieniać wiedzą.
A po co nam Open Source?
Chcemy pokazać dojrzałość naszej ekspertyzy i uzyskać wartościowy feedback: osoba spoza banku może wnieść coś od siebie. Interesuje nas także rozwój praktyk pracy z mikroserwisami i DDD na .NET w branży, być może ktoś zechce zabrać niektóre części frameworka dla siebie.
Właściwie, ViennaNET
Teraz przyjrzyjmy się wszystkiemu bliżej. .
ViennaNET.WebApi.*
Zestaw tych bibliotek składa się z „rdzenia” ViennaNET.WebApi, zawierającego klasę budującą usługę CompanyHostBuilder oraz zestaw konfiguratorów ViennaNET.WebApi.Configurators.*, z których każdy pozwala dodać i skonfigurować pewną funkcjonalność w tworzonej usłudze. Wśród konfiguratorów można znaleźć podłączenie do logowania, diagnostyki, typu uwierzytelnienia i autoryzacji, swaggera itd.
ViennaNET.WebApi.Runners.* zawiera wstępnie skonfigurowane budownicze usług. Te pakiety pozwalają nie przypominać sobie za każdym razem, tworząc nową usługę, jakie konfiguratory należy podłączyć. Nie ograniczają one jednak funkcjonalności budowniczego usług.
ViennaNET.Mediator.*
Biblioteki, które umożliwiają stworzenie wewnętrznej szyny pośredniej dla poleceń i zapytań w obrębie usługi. Takie podejście pozwala na zmniejszenie liczby wstrzyknięć DI do jednego, na przykład w kontrolerach. Dzięki temu można dodawać różne dekoratory do zapytań, co ujednolica ich przetwarzanie i zmniejsza ilość kodu.
ViennaNET.Validation
Zbiór zawierający zestaw klas do tworzenia reguł walidacyjnych i ich sekwencji. Bardzo przydatny do realizacji walidacji domenowej, gdyż pozwala opisać każdy warunek biznesowy w formie prostej i oddzielnej reguły.
ViennaNET.Redis
Biblioteka z opakowaniami do wygodnej pracy z Redis w roli in-memory cache.
ViennaNET.Specifications
Zbiór zawierający klasy implementujące wzorzec „Specyfikacja”.
To zaledwie nie wszystko, co znajduje się w naszym zestawie. Pozostałe można zobaczyć . Wkrótce planowane jest wydanie naszych bibliotek do współpracy z bazami danych w modelu OpenSource.
Dziękujemy za uwagę, czekamy na Wasze komentarze i pull requesty.
Źródło: habr.com
