Saluton ĉiuj!
Ni estas komunumo de .NET-programistoj ĉe Raiffeisenbank kaj ni volas paroli pri aro de infrastrukturaj bibliotekoj bazitaj sur .NET Kerno por rapide krei mikroservojn kun ununura ekosistemo. Ili alportis ĝin al Malferma Fonto!
Iom da historio
Iam ni havis grandan monolitan projekton, kiu iom post iom fariĝis aro da mikroservoj (vi povas legi pri la trajtoj de ĉi tiu procezo en ). En la procezo, ni renkontis la problemon, ke kreante novajn mikroservojn, ni ofte devis kopii diversajn infrastrukturajn solvojn - kiel agordi protokolojn, labori kun datumbazo, WCF, ktp. Unu teamo laboris pri ĉi tiu projekto, kaj ĉiuj jam kutimis al iu establita aliro labori kun infrastrukturo. Tial ni apartigis la komunan kodon en apartan deponejon, envolvis la kolektitajn bibliotekojn en Nuget-pakaĵojn kaj metis ilin en nian internan Nuget-deponejon.
La tempo pasis, la projekto iom post iom fragmentiĝis, kaj estis deziro krei novajn klientflankajn modulojn sur moderna JS-kadro kaj ruli ilin en la retumilo. Ni komencis moviĝi de WCF/SOAP al REST/HTTP, do ni bezonis novajn bibliotekojn por rapide lanĉi servojn bazitajn sur AspNet WebApi. La unua versio sur la .Net Framework 4.5 estis farita de nia arkitekto preskaŭ surgenue en sia libera tempo, sed el la skatolo ĝi ebligis lanĉi servon kun tri linioj en Program.cs kiu enhavis rajtigon (NTLM), arbodehakado, Swagger, IoC/DI surbaze de Castle Windsor, personecigitaj HTTP-klientoj, kiuj plusendas diversajn kapliniojn por provizi fin-al-finan registradon tra la tuta projekto. Kaj ĉi tiu tuta afero povus esti plue agordita rekte en la servo-agorda dosiero.
Tamen ne ĉio estis glata: ĉi tiu biblioteko montriĝis ege nefleksebla rilate al enkonduko de novaj moduloj. Ekzemple, se vi bezonis aldoni iun specialan mezvaron, vi devis krei novan asembleon kaj heredi de la baza klaso kiu kuras la servon, kio estis ege maloportuna. Feliĉe, ne estis tre multaj tiaj kazoj.
La epoko de Docker kaj Kubernetes
Venis la tempo, kiam la ondo de Docker kaj Kubernetes atingis nin, kiujn ni atente observis: finfine, estis bonega ŝanco ekmoviĝi plu laŭ la teknologioj, en .Net Core. Ĉi tio signifas, ke ni bezonos novan infrastrukturon por funkciigi servojn: iuj bibliotekoj migris de la .Net Framework al .Net Standard kaj .Net Core preskaŭ sen ŝanĝoj, kelkaj kun etaj plibonigoj. Sed ĉefe mi volis reverki la funkciojn asociitajn kun lanĉaj servoj sur AspNet Core.
La unua afero, kiun ni pripensis, estis koncepto, kiu forigus la ĉefan malavantaĝon de la antaŭa versio: manko de fleksebleco. Tial, estis decidite fari la tutan bibliotekan sistemon kiel eble plej sendependa kaj modula kaj kolekti la servojn necesajn por funkcieco kiel konstrukciisto.
La ĉefa celo estas krei unuigitan aliron, kiu priskribas kiel interagi kun datumbazoj, busoj kaj aliaj servoj. Ni provis fari integriĝojn rapidaj kaj sendoloraj, kaj programistoj povus koncentriĝi pri verkado de komerca logiko prefere ol infrastrukturo - ĝi jam estas preta. Ofta deponejo helpas plibonigi la sperton de interagado ene de teamoj: kiam tre similaj internaj infrastrukturoj estas uzataj, estas pli facile aliĝi al la evoluprocezo de alia teamo kaj interŝanĝi kompetentecon.
Kaj kial ni bezonas Malferman Kodon?
Ni volas montri la maturecon de nia kompetenteco kaj ricevi altkvalitajn reagojn: persono ekster la banko povos alporti ion de si mem. Ni ankaŭ interesiĝas pri la disvolviĝo de praktikoj por labori kun mikroservoj kaj DDD sur .NET en la industrio; eble iu volos transpreni iujn partojn de la kadro.
Fakte, ViennaNET
Nun ni rigardu pli detale. .
ViennaNET.WebApi.*
Ĉi tiu aro de bibliotekoj konsistas el la "radiko" ViennaNET.WebApi, enhavanta la konstruan klason por la servo CompanyHostBuilder, kaj aron da agordiloj ViennaNET.WebApi.Configurators.*, ĉiu el kiuj ebligas al vi aldoni kaj agordi iun funkciojn al la kreita. servo. Inter la agordiloj vi povas trovi konektojn por registri, diagnozajn, aŭtentikigajn kaj rajtigajn tipojn, fanfaron, ktp.
ViennaNET.WebApi.Runners.* ankaŭ enhavas antaŭkonfiguritajn servajn konstruantojn. Ĉi tiuj pakoj permesas vin ne memori ĉiun fojon kiam vi kreas novan servon, kiujn agordilojn devas esti konektitaj. Tamen ili neniel limigas la funkciecon de la serva konstruanto.
ViennaNET.Mediator.*
Bibliotekoj, kiuj ebligas al vi krei internan peran buson por komandoj kaj petoj ene de servo. Ĉi tiu aliro permesas redukti la nombron da DI-injektoj al unu, ekzemple, en regiloj. Pro tio, vi povas aldoni diversajn dekoraciistojn al petoj, kio unuigas ilian prilaboradon kaj reduktas la kvanton de kodo.
ViennaNET.Valido
Asembleo enhavanta aron da klasoj por krei validajn regulojn kaj sekvencojn el ili. Ĝi estas tre oportuna por efektivigi domajnan validigon, ĉar ĝi permesas vin priskribi ĉiun komercan kondiĉon en formo de simpla kaj aparta regulo.
ViennaNET.Redis
Biblioteko kun envolvaĵoj por oportuna laboro kun Redis kiel enmemora kaŝmemoro.
ViennaNET.Specigoj
Asembleo enhavanta klasojn kiuj efektivigas la Specifa ŝablono.
Ĉi tio ne estas ĉio, kio estas en nia aro. Vi povas vidi la reston . Ni planas liberigi niajn bibliotekojn por labori kun datumbazoj al OpenSource baldaŭ.
Dankon pro via atento, ni atendas viajn komentojn kaj tiri petojn.
fonto: www.habr.com