ViennaNET: ბიბლიოთეკების კომპლექტი ბექენდისთვის

გაუმარჯოს ყველას!

ჩვენ ვართ .NET დეველოპერების საზოგადოება Raiffeisenbank-ში და გვინდა ვისაუბროთ ინფრასტრუქტურული ბიბლიოთეკების ერთობლიობაზე, რომელიც დაფუძნებულია .NET Core-ზე, რათა სწრაფად შექმნან მიკროსერვისები ერთი ეკოსისტემით. მათ მიიტანეს ღია წყაროზე!

პატარა ისტორიის

ოდესღაც ჩვენ გვქონდა დიდი მონოლითური პროექტი, რომელიც თანდათან გადაიქცა მიკროსერვისების ერთობლიობაში (ამ პროცესის მახასიათებლების შესახებ შეგიძლიათ წაიკითხოთ ეს მუხლი). ამ პროცესში შეგვხვდა პრობლემა, რომ ახალი მიკროსერვისების შექმნისას ხშირად გვიწევდა სხვადასხვა ინფრასტრუქტურული გადაწყვეტილებების კოპირება – როგორიცაა ლოგის დაყენება, მონაცემთა ბაზასთან მუშაობა, WCF და ა.შ. ამ პროექტზე მუშაობდა ერთი გუნდი და ყველა უკვე მიჩვეული იყო ინფრასტრუქტურასთან მუშაობის გარკვეულ მიდგომას. ამიტომ, ჩვენ გამოვყავით საერთო კოდი ცალკე საცავში, შევფუთეთ შეგროვებული ბიბლიოთეკები Nuget პაკეტებში და მოვათავსეთ ისინი ჩვენს შიდა Nuget საცავში.

გავიდა დრო, პროექტი თანდათან დაიშალა და გაჩნდა სურვილი, შეექმნათ ახალი კლიენტური მოდულები თანამედროვე JS ჩარჩოზე და გაუშვათ ისინი ბრაუზერში. ჩვენ დავიწყეთ WCF/SOAP-დან REST/HTTP-ზე გადასვლა, ამიტომ გვჭირდებოდა ახალი ბიბლიოთეკები AspNet WebApi-ზე დაფუძნებული სერვისების სწრაფად დასაწყებად. .Net Framework 4.5-ის პირველი ვერსია ჩვენი არქიტექტორის მიერ თავისუფალ დროს თითქმის მუხლებზე იყო გაკეთებული, მაგრამ გარედან შესაძლებელი გახდა სერვისის გაშვება Program.cs-ში სამი ხაზით, რომელიც შეიცავდა ავტორიზაციას (NTLM). logging, Swagger, IoC/DI Castle Windsor-ზე დაფუძნებული, მორგებული HTTP კლიენტები, რომლებიც აგზავნიან სხვადასხვა სათაურებს, რათა უზრუნველყონ ბოლოდან ბოლომდე ჩაწერა მთელი პროექტის განმავლობაში. და ამ ყველაფრის შემდგომი კონფიგურაცია შესაძლებელია პირდაპირ სერვისის კონფიგურაციის ფაილში.

თუმცა, ყველაფერი არ იყო გლუვი: ეს ბიბლიოთეკა უკიდურესად მოუქნელი აღმოჩნდა ახალი მოდულების დანერგვის თვალსაზრისით. მაგალითად, თუ დაგჭირდათ რაიმე სპეციალური შუა პროგრამის დამატება, უნდა შეგექმნათ ახალი ასამბლეა და მემკვიდრეობა მიეღოთ საბაზო კლასიდან, რომელიც აწარმოებს სერვისს, რაც ძალიან მოუხერხებელი იყო. საბედნიეროდ, ასეთი შემთხვევები არც თუ ისე ბევრი იყო.

დოკერისა და კუბერნეტის ეპოქა

დადგა დრო, როდესაც Docker-ისა და Kubernetes-ის ტალღამ ჩვენამდე მოაღწია, რომელსაც ჩვენ ყურადღებით ვადევნებდით თვალს: ყოველივე ამის შემდეგ, ეს იყო დიდი შანსი, დაგვეწყო წინსვლა ტექნოლოგიების გასწვრივ, .Net Core-ში. ეს ნიშნავს, რომ ჩვენ დაგვჭირდება ახალი ინფრასტრუქტურა სერვისების გასაშვებად: ზოგიერთი ბიბლიოთეკა გადავიდა .Net Framework-დან .Net Standard-ზე და .Net Core-ზე პრაქტიკულად ცვლილებების გარეშე, ზოგიერთი მცირე გაუმჯობესებით. მაგრამ ყველაზე მეტად მინდოდა გადამემუშავებინა AspNet Core სერვისების გაშვებასთან დაკავშირებული ფუნქციები.

პირველი, რაც განვიხილეთ, იყო კონცეფცია, რომელიც მოხსნიდა წინა ვერსიის მთავარ ნაკლს: მოქნილობის ნაკლებობას. ამიტომ, გადაწყდა, რომ მთელი ბიბლიოთეკის სისტემა მაქსიმალურად დამოუკიდებელი და მოდულარული ყოფილიყო და კონსტრუქტორის ფუნქციონირებისთვის საჭირო სერვისების შეგროვება.

მთავარი მიზანია შეიქმნას ერთიანი მიდგომა, რომელიც აღწერს, თუ როგორ უნდა ვიმოქმედოთ მონაცემთა ბაზებთან, ავტობუსებთან და სხვა სერვისებთან. ჩვენ ვცდილობდით, რომ ინტეგრაცია სწრაფი და უმტკივნეულო გაგვეკეთებინა და დეველოპერებს შეეძლოთ კონცენტრირება მოახდინონ ბიზნეს ლოგიკის დაწერაზე და არა ინფრასტრუქტურაზე - ის უკვე მზად არის. საერთო საცავი ხელს უწყობს გუნდებში ურთიერთქმედების გამოცდილების გაუმჯობესებას: როდესაც ძალიან მსგავსი შიდა ინფრასტრუქტურა გამოიყენება, უფრო ადვილია სხვა გუნდის განვითარების პროცესში შეერთება და გამოცდილების გაცვლა.

და რატომ გვჭირდება ღია წყარო?

ჩვენ გვინდა ვაჩვენოთ ჩვენი ექსპერტიზის სიმწიფე და მივიღოთ მაღალი ხარისხის გამოხმაურება: ბანკის გარეთ მყოფი პირი შეძლებს საკუთარი თავის მოტანას. ჩვენ ასევე დაინტერესებული ვართ ინდუსტრიაში მიკროსერვისებთან და DDD-თან მუშაობის პრაქტიკის შემუშავებით.

სინამდვილეში, ViennaNET

ახლა მოდით უფრო ახლოს მივხედოთ. სრული წყაროს კოდი განთავსებულია აქ.

ViennaNET.WebApi.*

ბიბლიოთეკების ეს ნაკრები შედგება „ძირითადი“ ViennaNET.WebApi-სგან, რომელიც შეიცავს CompanyHostBuilder სერვისის მშენებლის კლასს და ViennaNET.WebApi.Configurators.* კონფიგურატორების კომპლექტს, რომელთაგან თითოეული საშუალებას გაძლევთ დაამატოთ და დააკონფიგურიროთ გარკვეული ფუნქციები შექმნილში. სერვისი. კონფიგურატორებს შორის შეგიძლიათ იპოვოთ კავშირები შესვლის, დიაგნოსტიკის, ავთენტიფიკაციისა და ავტორიზაციის ტიპებისთვის, swagger და ა.შ.

ViennaNET.WebApi.Runners.* ასევე შეიცავს წინასწარ კონფიგურირებულ სერვისის შემქმნელებს. ეს პაკეტები საშუალებას გაძლევთ არ დაიმახსოვროთ ყოველ ჯერზე, როდესაც შექმნით ახალ სერვისს, რომელსაც კონფიგურატორები უნდა დაუკავშირდეს. ამასთან, ისინი არანაირად არ ზღუდავენ სერვისის შემქმნელის ფუნქციონირებას.

ViennaNET.Mediator.*

ბიბლიოთეკები, რომლებიც საშუალებას გაძლევთ შექმნათ შიდა შუამავალი ავტობუსი ბრძანებებისა და მოთხოვნებისთვის სერვისში. ეს მიდგომა საშუალებას გაძლევთ შეამციროთ DI ინექციების რაოდენობა ერთამდე, მაგალითად, კონტროლერებში. ამის გამო, თქვენ შეგიძლიათ დაამატოთ სხვადასხვა დეკორატორები თხოვნებში, რაც აერთიანებს მათ დამუშავებას და ამცირებს კოდის რაოდენობას.

ViennaNET.Validation

ასამბლეა, რომელიც შეიცავს კლასების კომპლექტს მათგან ვალიდაციის წესებისა და თანმიმდევრობის შესაქმნელად. ის ძალიან მოსახერხებელია დომენის ვალიდაციის განსახორციელებლად, რადგან ის საშუალებას გაძლევთ აღწეროთ თითოეული ბიზნეს მდგომარეობა მარტივი და ცალკე წესის სახით.

ViennaNET.Redis

ბიბლიოთეკა შეფუთვით მოსახერხებელი მუშაობისთვის Redis-თან, როგორც მეხსიერების ქეში.

ViennaNET.Specifications

ასამბლეა, რომელიც შეიცავს კლასებს, რომლებიც ახორციელებენ სპეციფიკაციის შაბლონს.

ეს არ არის ყველაფერი, რაც ჩვენს კომპლექტშია. დანარჩენი შეგიძლიათ ნახოთ GitHub საცავში. ჩვენ ვგეგმავთ მალე გამოვაქვეყნოთ ჩვენი ბიბლიოთეკები მონაცემთა ბაზებთან მუშაობისთვის OpenSource-ში.

გმადლობთ ყურადღებისთვის, ჩვენ მოუთმენლად ველით თქვენს კომენტარს და თხოვნებს.

წყარო: www.habr.com