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

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

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

ViennaNET.Sagas

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

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

Нашата реализация е направена в основен вид и не е свързана с използването на каквито и да е средства за взаимодействие с другите услуги. Приложението ѝ не е сложно: достатъчно е да се създаде наследник от основния абстрактен клас SagaBase, където T – това е вашият клас контекст, в който могат да се съхраняват изходни данни, необходими за работата на сага, както и някои междинни резултати. Екземплярът на контекста ще бъде предаван на всички стъпки по време на изпълнението. Самата сага е stateless клас, така че екземплярът може да бъде поставен в DI като Singleton, за да получи необходимите зависимости.

Пример за декларация:

public class ExampleSaga : SagaBase
{
  public ExampleSaga()
  {
    Step("Стъпка 1")
      .WithAction(c => ...)
      .WithCompensation(c => ...);
	
    AsyncStep("Стъпка 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": "..."
  }
],

Пример ApplicationContext:

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

Ако идентификаторът на свързването не е указан, ще се ползва свързване с име «default».

Мапирането на обекти към таблици в базата данни се реализира с стандартните средства на NHibernate. Можете да използвате описание както чрез XML файлове, така и чрез класове. За удобно написване на заместители на репозиториите в Unit тестовете, е налична библиотека 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("myQueue");
var queueReactor = queueReactorFactory.CreateQueueReactor("myQueue");
queueReactor.StartProcessing();

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

За получаване на единично съобщение в интерфейса-фабрика IMessagingComponentFactory има метод CreateMessageReceiver, който ще създаде получател, очакващ съобщение от указаната опашка:

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

За изпращане на съобщение е необходимо да се използва същата IMessagingComponentFactory и да се създаде изпращач на съобщения:

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

За сериализация и десериализация на съобщения има три готови варианта: обикновен текст, XML и JSON, но при необходимост спокойно може да се направи свои реализации на интерфейсите IMessageSerializer и IMessageDeserializer.

Опитахме се да запазим уникалните възможности на всеки мениджър на опашки, например, ViennaNET.Messaging.MQSeriesQueue позволява изпращане не само на текстови, но и на байтови съобщения, а ViennaNET.Messaging.RabbitMQQueue поддържа маршрутизиране и създаване на опашки "на летища". В нашата обвивка на адаптера за RabbitMQ също е реализирана аналогия на RPC: изпращаме съобщение и очакваме отговор от специална временна опашка, която се създава само за едно ответно съобщение.

Ето пример за използване на опашки с основни нюанси на свързване.

ViennaNET.CallContext

Използваме опашки не само за интеграция между различни системи, но и за общуване между микросервизи в едно приложение, например, в рамките на сагата. Това доведе до необходимостта от предаване заедно с съобщението на такива помощни данни, като логин на потребителя, идентификатор на заявката за проследяване на логове, IP адрес на източника и данни за авторизация. За реализация на предаване на тези данни разработихме библиотека ViennaNET.CallContext, която позволява съхранение на данни от входящата заявка в услугата. При това начинът, по който е направена заявката, през опашка или през Http, няма значение. След това, преди изпращане на изходяща заявка или съобщение, данните от контекста се извличат и поставят в заглавките. Така следващата услуга получава помощни данни и ги управлява по аналогичен начин.

Благодарим за вниманието, очакваме вашите коментари и pull request-ове!

Източник: habr.com