ViennaNET: набор от библиотеки за бекенда. Част 2

Общността на разработчиците на Райфайзенбанк .NET продължава да прави кратък преглед на съдържанието на ViennaNET. За това как и защо стигнахме до това, можете да прочетете първата част.

В тази статия ще разгледаме все още неразгледани библиотеки за работа с разпределени транзакции, опашки и бази данни, които могат да бъдат намерени в нашето хранилище на GitHub (източниците са тук), и Nuget пакети тук.

ViennaNET.Sagas

Когато даден проект премине към DDD и микросервизна архитектура, тогава когато бизнес логиката се разпределя между различни услуги, възниква проблем, свързан с необходимостта от внедряване на механизъм за разпределени транзакции, тъй като много сценарии често засягат няколко домейна наведнъж. Можете да се запознаете по-подробно с такива механизми, напр. в книгата "Microservices Patterns", Крис Ричардсън.

В нашите проекти сме внедрили прост, но полезен механизъм: сага или по-скоро сага, базирана на оркестрация. Същността му е следната: има определен бизнес сценарий, при който е необходимо последователно да се извършват операции в различни услуги и ако възникнат проблеми на която и да е стъпка, е необходимо да се извика процедурата за връщане назад за всички предишни стъпки, където е предоставени. Така в края на сагата, независимо от успеха, получаваме последователни данни във всички области.

Нашата реализация все още е направена в основната си форма и не е обвързана с използването на никакви методи за взаимодействие с други услуги. Не е трудно да се използва: просто направете потомък на базовия абстрактен клас SagaBase<T>, където T е вашият контекстен клас, в който можете да съхранявате първоначалните данни, необходими за работата на сагата, както и някои междинни резултати. Инстанцията на контекста ще бъде предадена на всички стъпки по време на изпълнение. Самата Saga е клас без състояние, така че екземплярът може да бъде поставен в 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 са основната отправна точка за работа с базата данни, тъй като тук се създават Unit of Work, репозитории за работа с конкретни обекти, както и изпълнители на команди и директни SQL заявки. Понякога е удобно да се ограничат възможностите на даден клас за работа с база данни, например да се предостави възможност само за четене на данни. За такива случаи IEntityFactoryService има предшественик - интерфейс IEntityRepositoryFactory, който само декларира метод за създаване на хранилища.

За директен достъп до базата данни се използва механизмът на доставчика. Всяка СУБД, която използваме в нашите екипи, има своя собствена реализация: ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.

В същото време няколко доставчици могат да бъдат регистрирани в едно приложение едновременно, което позволява например в рамките на една услуга, без никакви разходи за модифициране на инфраструктурата, да се извърши стъпка по стъпка миграция от една СУБД към друга. Механизмът за избор на необходимата връзка и следователно доставчик за конкретен клас обект (за който е написано преобразуване към таблици на база данни) се реализира чрез регистриране на обекта в класа 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");
  }
}

Ако идентификаторът на връзката не е посочен, ще се използва връзката с име „по подразбиране“.

Директното картографиране на обекти към таблици на база данни се реализира с помощта на стандартни инструменти на NHibernate. Можете да използвате описанието както чрез xml файлове, така и чрез класове. За удобно писане на хранилища за мъничета в Unit tests има библиотека ViennaNET.TestUtils.Orm.

Можете да намерите пълни примери за използване на ViennaNET.Orm.* тук.

ViennaNET.Messaging.*

Набор от библиотеки за работа с опашки.

За работа с опашки беше избран същият подход, както при различните СУБД, а именно максимално възможен унифициран подход по отношение на работата с библиотеката, независимо от използвания мениджър на опашки. Библиотека 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