Mindenkinek szia!
Mi a Raiffeisen Bank .NET-fejlesztő közössége vagyunk, és szeretnénk beszélni egy .NET Core infrastruktúra könyvtárkészletről, amely lehetővé teszi a mikroservices gyors létrehozását egységes ökoszisztémán belül. Megjelentettük nyílt forráskódúként!
Egy kis történelem
Valaha volt egy nagy monolitikus projektünk, amely fokozatosan mikroservices készletté alakult (a folyamatról a ). Útközben azzal a problémával szembesültünk, hogy új mikroservices létrehozásakor gyakran különböző infrastruktúra megoldásokat kellett másolnunk – mint például a naplózás beállítása, az adatbázis kezelése, WCF stb. Ezen a projekten egy csapat dolgozott, és mindenki hozzászokott egy meghatározott infrastruktúra munkamódszerhez. Ezért a közös kódot egy külön tárolóba helyeztük, az összesített könyvtárakat Nuget-csomagokba csomagoltuk, és elhelyeztük a belső Nuget-tárolónkban.
Az idő telt, a projekt fokozatosan felbontásra került, és felmerült az igény új kliensoldali modulok létrehozására modern JS keretrendszeren, amelyeket böngészőben futtathatunk. Elkezdtek áttérni a WCF/SOAP-ról a REST/HTTP-ra, ezért új könyvtárakra volt szükségünk a szolgáltatások gyors indításához az AspNet WebApi alapjain. Az első verzió a .Net Framework 4.5-en kis híján a mérnökünk térdig érő idejében készült el, de már a dobozból lehetővé tette, hogy három sorban a Program.cs fájlban elindítsunk egy szolgáltatást, amely tartalmazta az azonosítást (NTLM), a naplózást, a Swaggert, az IoC/DI-t a Castle Windsor alapjain, megfelelően beállított HTTP-ügyfeleket, amelyek különböző fejlécet továbbítottak a projektben történő átfogó naplózás érdekében. Mindezt pedig lehetett további konfigurálni a szolgáltatás konfigurációs fájljában.
Azonban nem minden ment simán: ez a könyvtár rendkívül rugalmatlan volt új modulok bevezetésében. Például, ha valamilyen speciális middleware-t kellett hozzáadni, akkor új buildet kellett létrehozni és örökölni a szolgáltatást elindító alap osztályból, ami rendkívül kényelmetlen volt. Szerencsére az ilyen esetek száma viszonylag alacsony volt.
A Docker és Kubernetes kora
Elérkezett az idő, amikor a Docker és a Kubernetes hulláma eljutott hozzánk, amit figyelemmel kísértünk: hiszen ez nagyszerű lehetőség volt arra, hogy tovább lépjünk a technológiák terén, a .Net Core felé. Ezért új infrastruktúrára lesz szükségünk a szolgáltatások futtatásához: egyes könyvtárak szinte változtatás nélkül átkonvertálódtak a .Net Framework-ből a .Net Standardba és .Net Core-ba, míg másokat kisebb fejlesztésekkel átdolgoztunk. De leginkább a szolgáltatások AspNet Core-ra való futtatását érintő funkciókat szerettük volna újragondolni.
Első lépésként egy olyan koncepciót vizsgáltunk, amely megszünteti a korábbi verzió legfőbb hátrányát: a rugalmasság hiányát. Ezért úgy döntöttünk, hogy a könyvtárak rendszerét a lehető legfüggetlenebbé és modulárisabbá tesszük, és a szükséges funkciók szerinti szolgáltatásokat egy konstruktor szerint állítjuk össze.
Fő célunk egy egységes megközelítés létrehozása volt, amely leírja, hogyan kapcsolódjunk az adatbázisokhoz, buszokhoz és egyéb szolgáltatásokhoz. Arra törekedtünk, hogy az integrációk gyorsak és fájdalommentesek legyenek, így a fejlesztők a üzleti logika írására koncentrálhattak, nem pedig az infrastruktúrára – ez már készen áll. Az általános tároló segít javítani a csapatok közötti együttműködést: amikor nagyon hasonló belső infrastruktúrákat használnak, könnyebben be lehet kapcsolódni egy másik csapat fejlesztési folyamatába és megosztani a szakértelmet.
És miért van szükségünk nyílt forráskódra?
Azt szeretnénk megmutatni, hogy értenek a szakmához, és minőségi visszajelzést kapni: egy olyan ember, aki kívülálló a bank számára, valami újat hozhat. Emellett érdekel minket a mikroszolgáltatások és a DDD .NET-en való alkalmazásának fejlődése az iparban, lehet, hogy valaki szeretné elvinni a keretrendszer bizonyos részeit.
Egyébként, ViennaNET
Most nézzük meg mindent részletesebben. .
ViennaNET.WebApi.*
Ez a könyvtárkészlet a ViennaNET.WebApi "gyökeréből" áll, amely tartalmazza a CompanyHostBuilder szolgáltatáshoz szükséges építőosztályt, valamint a ViennaNET.WebApi.Configurators.* konfigurálókat, mindegyike lehetővé teszi bizonyos funkcionalitás hozzáadását és konfigurálását a létrehozott szolgáltatásba. A konfigurálók között megtalálhatók a naplózás, diagnosztika, autentikáció és autorizáció típusa, swagger stb. hozzáadásához szükséges elemek.
A ViennaNET.WebApi.Runners.* tartalmazza az előre beállított szolgáltatásépítőket. Ezek a csomagok lehetővé teszik, hogy ne kelljen mindig emlékezni azokra a konfigurálókra, amelyeket új szolgáltatás létrehozásakor csatlakoztatni kell. Ugyanakkor nem korlátozzák a szolgáltatásépítő funkcionalitását.
ViennaNET.Mediator.*
Könyvtárak, amelyek lehetővé teszik egy belső közvetítő busz létrehozását parancsok és lekérdezések számára a szolgáltatáson belül. Ez a megközelítés csökkenti a DI-injekciók számát egyre, például a vezérlőkben. Ennek köszönhetően különféle dekorátorokat lehet hozzáadni a lekérdezésekhez, ami egységesíti azok feldolgozását és csökkenti a kód mennyiségét.
ViennaNET.Validation
Egy összeállítás, amely egy osztályhalmazt tartalmaz érvényesítési szabályok és azok sorrendjeinek létrehozásához. Nagyon praktikus a domain érvényesítés végrehajtásához, mivel lehetővé teszi, hogy minden üzleti feltételt egyszerű és külön szabályként írjunk le.
ViennaNET.Redis
Könyvtár a Redis kényelmes használatához in-memory cache-ként.
ViennaNET.Specifications
Egy összeállítás, amely az 'Specification' mintát megvalósító osztályokat tartalmaz.
Ez még messze van a teljes készletünktől. A többit itt lehet megtekinteni, . Hamarosan nyílt forrásúvá válik az adatbáziskezelői könyvtáraink.
Köszönjük a figyelmet, várjuk a megjegyzéseiket és a pull request-eket.
Forrás: habr.com
