Hello!
Mi a Raiffeisenbank .NET-fejlesztőinek közössége vagyunk, és a .NET Core-on alapuló infrastruktúra-könyvtárakról akarunk beszélni, amelyek egyetlen ökoszisztémával gyorsan hozhatnak létre mikroszolgáltatásokat. Nyílt forráskódra hozták!
Egy kis történelem
Valamikor réges-régen volt egy nagy monolitikus projektünk, ami fokozatosan mikroszolgáltatások sorozatává alakult (a folyamat jellemzőiről itt olvashat ). Ennek során azzal a problémával találkoztunk, hogy az új mikroszolgáltatások létrehozásakor gyakran kellett másolni a különféle infrastrukturális megoldásokat - például naplózás beállítása, adatbázissal való munka, WCF stb. Egy csapat dolgozott ezen a projekten, és mindenki megszokta már az infrastruktúrával való munka valamilyen bevált megközelítését. Ezért a közös kódot külön tárolóba különítettük el, az összegyűjtött könyvtárakat Nuget-csomagokba csomagoltuk, és a belső Nuget-tárunkba helyeztük el.
Telt-múlt az idő, a projekt fokozatosan töredezett, és felmerült a vágy, hogy új kliensoldali modulokat hozzanak létre egy modern JS keretrendszeren, és futtassák azokat a böngészőben. Megkezdtük az átállást a WCF/SOAP-ról a REST/HTTP-re, ezért új könyvtárakra volt szükségünk az AspNet WebApi alapú szolgáltatások gyors elindításához. Az első verziót a .Net Framework 4.5-re építészünk szabadidejében szinte térden állva készítette el, de a dobozból kikerülve lehetővé tette, hogy a Program.cs-ben háromsoros, jogosultságot (NTLM) tartalmazó szolgáltatás induljon el, naplózás, Swagger, IoC/DI a Castle Windsoron alapuló testreszabott HTTP-kliensek, amelyek különféle fejléceket továbbítanak, hogy végpontok közötti naplózást biztosítsanak a teljes projekt során. És ez az egész tovább konfigurálható közvetlenül a szolgáltatás konfigurációs fájljában.
Azonban nem minden volt zökkenőmentes: ez a könyvtár rendkívül rugalmatlannak bizonyult az új modulok bevezetése szempontjából. Például, ha valamilyen speciális köztes szoftvert kellett hozzáadni, akkor létre kellett hozni egy új összeállítást, és örökölni a szolgáltatást futtató alaposztályból, ami rendkívül kényelmetlen volt. Szerencsére nem nagyon volt ilyen eset.
Docker és Kubernetes korszaka
Eljött az idő, amikor elért minket a Docker és a Kubernetes hulláma, amit nagyon figyeltünk: elvégre ez egy remek lehetőség volt arra, hogy a technológiák mentén, a .Net Core-ban tovább haladjunk. Ez azt jelenti, hogy a szolgáltatások működtetéséhez új infrastruktúrára lesz szükségünk: néhány könyvtár gyakorlatilag változtatás nélkül, néhány kisebb fejlesztéssel átállt a .Net Framework-ről a .Net Standard és a .Net Core-ra. De leginkább a szolgáltatások AspNet Core-on való elindításához kapcsolódó funkcionalitást szerettem volna átdolgozni.
Az első dolog, amit fontolóra vettünk, egy olyan koncepció volt, amely megszünteti az előző verzió fő hátrányát: a rugalmasság hiányát. Ezért úgy döntöttek, hogy a teljes könyvtári rendszert a lehető legfüggetlenebbé, modulárisabbá tegyék, és konstruktorként összegyűjtik a funkcionalitáshoz szükséges szolgáltatásokat.
A fő cél egy olyan egységes megközelítés létrehozása, amely leírja, hogyan kell interakciót folytatni adatbázisokkal, buszokkal és egyéb szolgáltatásokkal. Arra törekedtünk, hogy az integráció gyors és fájdalommentes legyen, a fejlesztők pedig inkább az üzleti logika írására koncentrálhattak, mint az infrastruktúrára – már készen is van. A közös adattár segít javítani a csapaton belüli interakció élményét: ha nagyon hasonló belső infrastruktúrát használnak, könnyebb csatlakozni egy másik csapat fejlesztési folyamatához, és kicserélni a szakértelmet.
És miért van szükségünk nyílt forráskódra?
Szeretnénk megmutatni szakértelmünk kiforrottságát, és minőségi visszajelzéseket kapni: a bankon kívüli ember hozhat valamit magából. Érdekelnek bennünket a mikroszolgáltatásokkal és a DDD-vel való munkavégzés gyakorlatának fejlesztése is a .NET-en az iparágban, talán valaki át akarja venni a keretrendszer bizonyos részeit.
Tulajdonképpen ViennaNET
Most nézzük meg közelebbről. .
ViennaNET.WebApi.*
Ez a könyvtárkészlet a „root” ViennaNET.WebApi-ból áll, amely tartalmazza a CompanyHostBuilder szolgáltatás builder osztályát, és egy konfigurátorkészletet ViennaNET.WebApi.Configurators.*, amelyek mindegyike lehetővé teszi bizonyos funkciók hozzáadását és konfigurálását a létrehozott termékhez. szolgáltatás. A konfigurátorok között találhatunk kapcsolatokat naplózáshoz, diagnosztikához, hitelesítési és engedélyezési típusokhoz, swaggerhez stb.
A ViennaNET.WebApi.Runners.* előre konfigurált szolgáltatásépítőket is tartalmaz. Ezek a csomagok lehetővé teszik, hogy ne emlékezzen minden alkalommal, amikor új szolgáltatást hoz létre, mely konfigurátorokat kell csatlakoztatni. Ezek azonban semmilyen módon nem korlátozzák a szolgáltatásépítő funkcionalitását.
ViennaNET.Mediator.*
Könyvtárak, amelyek lehetővé teszik belső közvetítő busz létrehozását a szolgáltatáson belüli parancsokhoz és kérésekhez. Ez a megközelítés lehetővé teszi a DI befecskendezések számának egyre csökkentését, például a vezérlőkben. Ennek köszönhetően a kérésekhez különféle dekorátorokat adhat hozzá, ami egységesíti azok feldolgozását és csökkenti a kód mennyiségét.
ViennaNET.Érvényesítés
Osztályokat tartalmazó összeállítás az érvényesítési szabályok és sorozatok létrehozásához. Nagyon kényelmes a tartományérvényesítés megvalósításához, mivel lehetővé teszi az egyes üzleti feltételek egyszerű és külön szabály formájában történő leírását.
ViennaNET.Redis
Egy könyvtár csomagolóanyagokkal a kényelmes munkavégzéshez a Redis-sel, mint a memórián belüli gyorsítótárral.
ViennaNET.Műszaki adatok
Olyan összeállítás, amely a specifikációs mintát megvalósító osztályokat tartalmazza.
Ez nem minden, ami a készletünkben található. A többit láthatod . Hamarosan azt tervezzük, hogy az adatbázisokkal való együttműködésre alkalmas könyvtárainkat OpenSource-ra is kiadjuk.
Köszönjük a figyelmet, várjuk észrevételeiket, kéréseiteket.
Forrás: will.com