Ahoj všichni!
Jsme komunita .NET vývojářů v Raiffeisenbank a chceme hovořit o sadě infrastrukturních knihoven založených na .NET Core pro rychlé vytváření mikroslužeb s jediným ekosystémem. Přinesli to do Open Source!
Trocha historie
Kdysi dávno jsme měli velký monolitický projekt, který se postupně proměnil v sadu mikroslužeb (o vlastnostech tohoto procesu si můžete přečíst v ). V průběhu jsme narazili na problém, že při vytváření nových mikroslužeb jsme museli často kopírovat různá infrastrukturní řešení – např. nastavení logování, práce s databází, WCF atp. Na tomto projektu pracoval jeden tým a všichni už byli zvyklí na nějaký zavedený přístup k práci s infrastrukturou. Proto jsme společný kód oddělili do samostatného úložiště, shromážděné knihovny zabalili do balíčků Nuget a umístili je do našeho interního úložiště Nuget.
Čas plynul, projekt se postupně fragmentoval a vznikla touha vytvářet nové moduly na straně klienta na moderním frameworku JS a spouštět je v prohlížeči. Začali jsme přecházet z WCF/SOAP na REST/HTTP, takže jsme potřebovali nové knihovny pro rychlé spouštění služeb založených na AspNet WebApi. První verzi na .Net Frameworku 4.5 vytvořil náš architekt téměř na koleně ve svém volném čase, ale hned z krabice umožnila spustit službu se třemi řádky v Program.cs, která obsahovala autorizaci (NTLM), logging, Swagger, IoC/DI on založené na Castle Windsor, přizpůsobení HTTP klienti, kteří předávají různé hlavičky, aby poskytovali end-to-end protokolování v průběhu celého projektu. A toto celé by se dalo dále konfigurovat přímo v konfiguračním souboru služby.
Ne vše však proběhlo hladce: tato knihovna se ukázala jako extrémně neflexibilní z hlediska zavádění nových modulů. Pokud jste například potřebovali přidat nějaký speciální middleware, museli jste vytvořit nové sestavení a dědit ze základní třídy, která službu spouští, což bylo extrémně nepohodlné. Naštěstí takových případů nebylo moc.
Éra Docker a Kubernetes
Nastal čas, kdy k nám dorazila vlna Dockeru a Kubernetes, kterou jsme bedlivě sledovali: koneckonců to byla skvělá šance začít se posouvat dál po technologiích, v .Net Core. To znamená, že pro provoz služeb budeme potřebovat novou infrastrukturu: některé knihovny migrovaly z .Net Frameworku na .Net Standard a .Net Core prakticky beze změn, některé s drobnými vylepšeními. Ale hlavně jsem chtěl přepracovat funkcionalitu spojenou se spouštěním služeb na AspNet Core.
První věc, kterou jsme zvažovali, byl koncept, který by odstranil hlavní nevýhodu předchozí verze: nedostatek flexibility. Proto bylo rozhodnuto udělat celý knihovní systém co nejvíce nezávislý a modulární a shromáždit služby potřebné pro funkčnost jako konstruktor.
Hlavním cílem je vytvořit jednotný přístup, který popisuje, jak interagovat s databázemi, sběrnicemi a dalšími službami. Snažili jsme se, aby byly integrace rychlé a bezbolestné a vývojáři se mohli soustředit na psaní obchodní logiky spíše než na infrastrukturu – ta je již připravena. Společné úložiště pomáhá zlepšovat zkušenosti z interakce v rámci týmů: když se používají velmi podobné interní infrastruktury, je snazší zapojit se do procesu vývoje jiného týmu a vyměňovat si odborné znalosti.
A proč potřebujeme Open Source?
Chceme ukázat vyspělost naší odbornosti a získat kvalitní zpětnou vazbu: člověk mimo banku bude moci přinést něco ze sebe. Zajímá nás také vývoj praktik pro práci s mikroslužbami a DDD na .NET v branži, možná bude chtít někdo převzít určité části frameworku.
Vlastně ViennaNET
Nyní se na to podíváme blíže. .
ViennaNET.WebApi.*
Tato sada knihoven se skládá z „kořenového“ ViennaNET.WebApi, který obsahuje třídu builder pro službu CompanyHostBuilder, a sady konfigurátorů ViennaNET.WebApi.Configurators.*, z nichž každý umožňuje přidávat a konfigurovat některé funkce k vytvořeným servis. Mezi konfigurátory najdete připojení pro logování, diagnostiku, typy autentizace a autorizace, swagger atd.
ViennaNET.WebApi.Runners.* také obsahuje předkonfigurované tvůrce služeb. Tyto balíčky vám umožňují nepamatovat si pokaždé, když vytváříte novou službu, které konfigurátory je třeba připojit. Nijak však neomezují funkčnost tvůrce služeb.
ViennaNET.Mediator.*
Knihovny, které vám umožňují vytvořit interní zprostředkující sběrnici pro příkazy a požadavky v rámci služby. Tento přístup umožňuje snížit počet DI injekcí na jeden, například v ovladačích. Díky tomu můžete do požadavků přidávat různé dekorátory, což sjednocuje jejich zpracování a snižuje množství kódu.
ViennaNET.Ověření
Sestavení obsahující sadu tříd pro vytváření ověřovacích pravidel a sekvencí z nich. Je velmi vhodný pro implementaci ověřování domény, protože umožňuje popsat každou obchodní podmínku formou jednoduchého a samostatného pravidla.
ViennaNET.Redis
Knihovna s obaly pro pohodlnou práci s Redis jako in-memory cache.
ViennaNET.Specifikace
Sestavení obsahující třídy, které implementují vzor specifikace.
To není vše, co je v naší sadě. Zbytek můžete vidět . Brzy plánujeme vydat naše knihovny pro práci s databázemi pro OpenSource.
Děkujeme za pozornost, těšíme se na vaše komentáře a žádosti o stažení.
Zdroj: www.habr.com