ViennaNET: ბიბლიოთეკების კომპლექტი ბექენდისთვის. Მე -2 ნაწილი

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

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

ViennaNET.Sagas

როდესაც პროექტი გადადის DDD-ზე და მიკროსერვისის არქიტექტურაზე, მაშინ როდესაც ბიზნეს ლოგიკა ნაწილდება სხვადასხვა სერვისებზე, ჩნდება პრობლემა, რომელიც დაკავშირებულია განაწილებული ტრანზაქციის მექანიზმის დანერგვის აუცილებლობასთან, რადგან ბევრი სცენარი ხშირად მოქმედებს რამდენიმე დომენზე ერთდროულად. თქვენ შეგიძლიათ გაეცნოთ ასეთ მექანიზმებს უფრო დეტალურად, მაგალითად, წიგნში „Microservices Patterns“, კრის რიჩარდსონი.

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

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

რეკლამის მაგალითი:

public class ExampleSaga : SagaBase<ExampleContext>
{
  public ExampleSaga()
  {
    Step("Step 1")
      .WithAction(c => ...)
      .WithCompensation(c => ...);
	
    AsyncStep("Step 2")
      .WithAction(async c => ...);
  }
}

ზარის მაგალითი:

var saga = new ExampleSaga();
var context = new ExampleContext();
await saga.Execute(context);

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

ViennaNET.Orm.*

ბიბლიოთეკების ნაკრები Nhibernate-ის საშუალებით სხვადასხვა მონაცემთა ბაზებთან მუშაობისთვის. ჩვენ ვიყენებთ DB-First მიდგომას Liquibase-ის გამოყენებით, ამიტომ არის მხოლოდ მზა მონაცემთა ბაზაში მონაცემებთან მუშაობის ფუნქციონირება.

ViennaNET.Orm.Seedwork и ViennaNET.Orm - ძირითადი ასამბლეები, რომლებიც შეიცავს ძირითად ინტერფეისებს და მათ დანერგვას, შესაბამისად. განვიხილოთ მათი შინაარსი უფრო დეტალურად.

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

მონაცემთა ბაზაზე უშუალო წვდომისთვის გამოიყენება პროვაიდერის მექანიზმი. თითოეულ DBMS-ს, რომელსაც ჩვენ ვიყენებთ ჩვენს გუნდებში, აქვს საკუთარი განხორციელება: ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.

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

"db": [
  {
    "nick": "mssql_connection",
    "dbServerType": "MSSQL",
    "ConnectionString": "...",
    "useCallContext": true
  },
  {
    "nick": "oracle_connection",
    "dbServerType": "Oracle",
    "ConnectionString": "..."
  }
],

განაცხადის კონტექსტის მაგალითი:

internal sealed class DbContext : ApplicationContext
{
  public DbContext()
  {
    AddEntity<SomeEntity>("mssql_connection");
    AddEntity<MigratedSomeEntity>("oracle_connection");
    AddEntity<AnotherEntity>("oracle_connection");
  }
}

თუ კავშირის ID არ არის მითითებული, მაშინ გამოყენებული იქნება კავშირი სახელად „default“.

ერთეულების პირდაპირი რუკა მონაცემთა ბაზის ცხრილებზე ხორციელდება სტანდარტული NHibernate ინსტრუმენტების გამოყენებით. თქვენ შეგიძლიათ გამოიყენოთ აღწერა როგორც xml ფაილების, ასევე კლასების საშუალებით. Unit ტესტებში საცობების მოსახერხებელი ჩაწერისთვის არის ბიბლიოთეკა ViennaNET.TestUtils.Orm.

ViennaNET.Orm.* გამოყენების სრული მაგალითები შეგიძლიათ იხილოთ აქ.

ViennaNET. Messaging.*

ბიბლიოთეკების ნაკრები რიგებთან მუშაობისთვის.

რიგებთან მუშაობისთვის არჩეული იქნა იგივე მიდგომა, რაც სხვადასხვა DBMS-ებთან, კერძოდ, მაქსიმალურად ერთიანი მიდგომა ბიბლიოთეკასთან მუშაობის თვალსაზრისით, მიუხედავად გამოყენებული რიგის მენეჯერისა. ბიბლიოთეკა ViennaNET.Messaging სწორედ ამ გაერთიანებაზეა პასუხისმგებელი და ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue и ViennaNET.Messaging.KafkaQueue შეიცავს ადაპტერის დანერგვას IBM MQ, RabbitMQ და Kafka-სთვის, შესაბამისად.

რიგებთან მუშაობისას ორი პროცესია: შეტყობინების მიღება და გაგზავნა.

იფიქრეთ მიღებაზე. აქ არის 2 ვარიანტი: უწყვეტი მოსმენისთვის და ერთი შეტყობინების მისაღებად. რიგის მუდმივად მოსასმენად, ჯერ უნდა აღწეროთ მემკვიდრეობით მიღებული პროცესორის კლასი IMessageProcessor, რომელიც პასუხისმგებელი იქნება შემომავალი შეტყობინების დამუშავებაზე. შემდეგი, ის უნდა იყოს "დაკავშირებული" კონკრეტულ რიგში; ეს ხდება რეგისტრაციის გზით IQueueReactorFactory რიგის იდენტიფიკატორის მითითება კონფიგურაციიდან:

"messaging": {
    "ApplicationName": "MyApplication"
},
"rabbitmq": {
    "queues": [
      {
        "id": "myQueue",
        "queuename": "lalala",
        ...
      }
    ]
},

მოსმენის დაწყების მაგალითი:

_queueReactorFactory.Register<MyMessageProcessor>("myQueue");
var queueReactor = queueReactorFactory.CreateQueueReactor("myQueue");
queueReactor.StartProcessing();

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

ქარხნულ ინტერფეისში ერთი შეტყობინების მისაღებად IMessagingComponentFactory არსებობს მეთოდი CreateMessageReceiverრომელიც შექმნის მიმღებს, რომელიც ელოდება შეტყობინებას მასზე მითითებული რიგიდან:

using (var receiver = _messagingComponentFactory.CreateMessageReceiver<TestMessage>("myQueue"))
{
    var message = receiver.Receive();
}

შეტყობინების გასაგზავნად თქვენ უნდა გამოიყენოთ იგივე IMessagingComponentFactory და შექმენით შეტყობინების გამგზავნი:

using (var sender = _messagingComponentFactory.CreateMessageSender<MyMessage>("myQueue"))
{
    sender.SendMessage(new MyMessage { Value = ...});
}

არსებობს სამი მზა ვარიანტი მესიჯის სერიალიზაციისა და დესერიალიზაციისთვის: მხოლოდ ტექსტი, XML და JSON, მაგრამ საჭიროების შემთხვევაში, შეგიძლიათ მარტივად გააკეთოთ თქვენი საკუთარი ინტერფეისის დანერგვა. IMessageSerializer и IMessageDeserializer.

ჩვენ შევეცადეთ შეგვენარჩუნებინა თითოეული რიგის მენეჯერის უნიკალური შესაძლებლობები, მაგ. ViennaNET.Messaging.MQSeriesQueue საშუალებას გაძლევთ გაგზავნოთ არა მხოლოდ ტექსტური, არამედ ბაიტი შეტყობინებები და ViennaNET.Messaging.RabbitMQQueue მხარს უჭერს მარშრუტიზაციას და ფრენის დროს რიგში. RabbitMQ-ისთვის ჩვენი ადაპტერის შეფუთვა ასევე ახორციელებს RPC-ის გარკვეულ მსგავსებას: ჩვენ ვაგზავნით შეტყობინებას და ველოდებით პასუხს სპეციალური დროებითი რიგიდან, რომელიც იქმნება მხოლოდ ერთი საპასუხო შეტყობინებისთვის.

აქ რიგების გამოყენების მაგალითი ძირითადი კავშირის ნიუანსებით.

ViennaNET.CallContext

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

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

წყარო: www.habr.com