ViennaNET: en samling av bibliotek för backend. Del 2

Gemenskapen av .NET-utvecklare på Raiffeisenbank fortsätter den korta genomgången av innehållet i ViennaNET. Om hur och varför vi kom hit, kan du läsa i första delen.

I denna artikel kommer vi att gå igenom de bibliotek som ännu inte har diskuterats för att arbeta med distribuerade transaktioner, köer och databaser, som du kan hitta i vårt GitHub-repo (källkoden finns här), och Nuget-paketen finns här.

ViennaNET.Sagas

När ett projekt övergår till DDD och mikrotjänstarkitektur, uppstår en fråga gällande implementeringen av mekanismen för distribuerade transaktioner, eftersom många scenarier ofta berör flera domäner. Mer om sådana mekanismer kan du lära dig, till exempel, i boken "Microservices Patterns", Chris Richardson.

I våra projekt har vi implementerat en enkel, men användbar mekanism: en saga, eller mer specifikt en saga baserad på orkestrering. Dess syfte är följande: det finns ett visst affärsscenario där det är nödvändigt att successivt utföra operationer i olika tjänster, och om det uppstår några problem vid något steg, måste en rollback-procedur för alla föregående steg som det är avsett för anropas. Således, i slutet av sagans utförande, oavsett om det har varit framgångsrikt eller inte, får vi konsekventa data i alla domäner.

Vår implementering är hittills gjord i grundläggande form och är inte knuten till användningen av några metoder för interaktion med andra tjänster. Att använda den är enkelt: det räcker att skapa en arvsklass från den grundläggande abstrakta klassen SagaBase, där T är din kontextklass, i vilken du kan lagra ursprungliga data nödvändiga för att arbeta med sagan samt några mellanresultat. En instans av kontexten kommer att matas vidare i alla steg under körningen. Själva sagan är en stateless klass, så instansen kan registreras i DI som Singleton för att få nödvändiga beroenden.

Exempel på deklaration:

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

Exempel på anrop:

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

Fullständiga exempel på olika implementeringar kan ses här och i paket med tester.

ViennaNET.Orm.*

Ett bibliotekspaket för att arbeta med olika databaser via Nhibernate. Vi använder en DB-First-ansats med Liquibase, så här finns endast funktionalitet för att arbeta med data i en färdig databas.

ViennaNET.Orm.Seedwork och ViennaNET.Orm är huvudpaketen som innehåller grundläggande gränssnitt och deras implementationer. Låt oss titta närmare på deras innehåll.

Gränssnitt IEntityFactoryService och dess implementation EntityFactoryService är den huvudsakliga startpunkten för att arbeta med databasen, eftersom här skapas Unit of Work, repositorier för att arbeta med specifika entiteter, samt kommandoförare och direkta SQL-frågor. Ibland är det praktiskt att begränsa klassens möjligheter att arbeta med databasen, till exempel att enbart ge möjlighet att läsa data. För sådana fall har IEntityFactoryService en förälder – gränssnittet IEntityRepositoryFactory, där endast metoden för att skapa repositorier deklareras.

För direkt åtkomst till databasen används ett leverantörsmekanism. För varje DBMS som vi använder i våra team finns det en specifik implementation: ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.

Samtidigt kan flera leverantörer registreras i en applikation, vilket möjliggör att man inom en och samma tjänst utan extra infrastrukturkostnader kan genomföra en stegvis migration från en DBMS till en annan. Mekanismen för att välja rätt anslutning och därmed leverantör för en specifik klass-entity (för vilken mappning till databastabeller skrivs) implementeras genom registrering av en entitet i klassen BoundedContext (innehåller metod för registrering av domänentiteter) eller dess arvtagare ApplicationContext (innehåller metoder för registrering av applikationsentiteter, direkta frågor och kommandon), där anslutningsidentifikatorn från konfigurationen tas som argument:

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

Exempel på ApplicationContext:

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

Om anslutningsidentifikatorn inte anges används anslutningen med namnet «default».

Direkt mappning av entiteter till databas-tabeller implementeras med standardverktyg i NHibernate. Man kan använda beskrivningar antingen genom xml-filer eller genom klasser. För att underlätta för skrivandet av stubbrepositorier i enhetstester finns det ett bibliotek ViennaNET.TestUtils.Orm.

Fullständiga exempel på användning av ViennaNET.Orm.* kan hittas här.

ViennaNET.Messaging.*

Ett bibliotek för att arbeta med köer.

För att arbeta med köer valdes samma angreppssätt som för olika databashanterare, nämligen ett maximalt enhetligt tillvägagångssätt när det gäller arbete med biblioteket, oavsett vilken köhanterare som används. Biblioteket ViennaNET.Messaging tjänar just till denna enhetlighet, och ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue och ViennaNET.Messaging.KafkaQueue innehåller implementeringar av adaptrar för IBM MQ, RabbitMQ och Kafka respektive.

I arbetet med köer finns det två processer: mottagning av meddelande och utskick.

Låt oss titta på mottagningen. Här finns det 2 alternativ: för konstant lyssning och för mottagning av ett enstaka meddelande. För konstant lyssning på kön måste man först beskriva en processor-klass som ärver från IMessageProcessor, som kommer att ansvara för behandlingen av det inkommande meddelandet. Därefter måste den "kopplas" till en viss kö, vilket görs genom registrering i IQueueReactorFactory med angivande av köidentifieraren från konfigurationen:

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

Exempel på start av lyssning:

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

Sedan, när tjänsten startar och metoden för att börja lyssna anropas, kommer alla meddelanden från den angivna kön att nå den motsvarande processorn.

För att ta emot ett enstaka meddelande i fabriksgränssnittet IMessagingComponentFactory finns det en metod CreateMessageReceiver, som skapar en mottagare som väntar på meddelanden från den angivna kön:

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

För att skicka ett meddelande måste man använda samma IMessagingComponentFactory och skapa en meddelandeavsändare:

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

För serialisering och deserialisering av meddelanden finns det tre färdiga alternativ: ren text, XML och JSON, men vid behov kan man enkelt göra sina egna implementationer av gränssnitten. IMessageSerializer och IMessageDeserializer.

Vi har försökt bevara de unika möjligheterna hos varje köhanterare, till exempel ViennaNET.Messaging.MQSeriesQueue kan skicka både text- och byte-meddelanden, medan ViennaNET.Messaging.RabbitMQQueue stöder routing och skapande av köer "on-the-fly". I vår wrapper-adapter för RabbitMQ finns också en form av RPC: vi skickar ett meddelande och väntar på svar från en speciell temporär kö som skapas enbart för ett svarsmeddelande.

Här är ett exempel på användning av köer med viktiga anslutningsfinesser.

ViennaNET.CallContext

Vi använder köer inte bara för integration mellan olika system, utan även för kommunikation mellan mikrotjänster inom en och samma applikation, till exempel inom ramen för en saga. Detta har lett till behovet av att överföra sådana hjälpdata tillsammans med meddelandet som användarnamn, begärnings-ID för spårning av loggar, källans IP-adress och autentiseringsinformation. För att realisera överföringen av dessa data har vi utvecklat ett bibliotek ViennaNET.CallContext, vilket gör det möjligt att lagra data från ingående begärningar till tjänsten. Hur begärningen gjordes, via kö eller via Http, spelar ingen roll. Sedan, innan avsändandet av en utgående begäran eller meddelande, hämtas data från kontexten och placeras i rubriker. På så sätt får nästa tjänst hjälpdata och hanterar dem på liknande sätt.

Tack för er uppmärksamhet, vi ser fram emot era kommentarer och pull requests!

Källa: habr.com