ViennaNET: 백엔드용 라이브러리 세트입니다. 2 부

Raiffeisenbank .NET 개발자 커뮤니티에서는 ViennaNET의 콘텐츠를 계속해서 간략하게 검토하고 있습니다. 우리가 여기까지 온 방법과 이유에 대해, 첫 번째 부분을 읽을 수 있습니다.

이 기사에서는 GitHub 저장소(출처는 여기에 있습니다), 너겟 패키지는 여기.

비엔나NET.사가

프로젝트가 DDD 및 마이크로서비스 아키텍처로 전환되면 비즈니스 논리가 여러 서비스에 분산되면 분산 트랜잭션 메커니즘을 구현해야 하는 것과 관련된 문제가 발생합니다. 많은 시나리오가 동시에 여러 도메인에 영향을 미치는 경우가 많기 때문입니다. 예를 들어 이러한 메커니즘에 대해 더 자세히 알아볼 수 있습니다. Chris Richardson은 "마이크로서비스 패턴"이라는 책에서.

우리 프로젝트에서는 간단하지만 유용한 메커니즘, 즉 오케스트레이션 기반 사가를 구현했습니다. 그 본질은 다음과 같습니다. 다양한 서비스에서 작업을 순차적으로 수행해야 하는 특정 비즈니스 시나리오가 있으며, 어떤 단계에서 문제가 발생하면 모든 이전 단계에 대해 롤백 절차를 호출해야 합니다. 제공됩니다. 따라서 이야기가 끝나면 성공 여부에 관계없이 모든 영역에서 일관된 데이터를 받게 됩니다.

우리의 구현은 여전히 ​​기본 형태로 이루어지며 다른 서비스와의 상호 작용 방법 사용과 연결되지 않습니다. 사용하는 것은 어렵지 않습니다. 기본 추상 클래스 SagaBase<T>의 자손을 만드세요. 여기서 T는 사가가 작동하는 데 필요한 초기 데이터와 일부 중간 결과를 저장할 수 있는 컨텍스트 클래스입니다. 컨텍스트 인스턴스는 실행 중에 모든 단계에 전달됩니다. Saga 자체는 상태 비저장 클래스이므로 인스턴스를 DI에 싱글톤으로 배치하여 필요한 종속성을 얻을 수 있습니다.

광고 예시:

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를 통해 다양한 데이터베이스로 작업하기 위한 라이브러리 세트입니다. 우리는 Liquibase를 사용하여 DB-First 접근 방식을 사용하므로 기성 데이터베이스의 데이터로 작업하는 기능만 있습니다.

ViennaNET.Orm.Seedwork и ViennaNET.Orm – 기본 인터페이스와 그 구현을 각각 포함하는 주요 어셈블리. 그 내용을 좀 더 자세히 살펴보자.

인터페이스 IEntityFactoryService 그리고 그 구현 EntityFactoryService 작업 단위, 특정 엔터티 작업을 위한 리포지토리, 명령 실행자 및 직접 SQL 쿼리가 여기에서 생성되므로 데이터베이스 작업의 주요 시작점이 됩니다. 예를 들어 데이터를 읽는 기능만 제공하는 등 데이터베이스 작업을 위해 클래스의 기능을 제한하는 것이 편리한 경우도 있습니다. 그러한 경우 IEntityFactoryService 조상이 있습니다 - 인터페이스 IEntityRepositoryFactory, 리포지토리 생성 방법만 선언합니다.

데이터베이스에 직접 액세스하기 위해 공급자 메커니즘이 사용됩니다. 우리 팀에서 사용하는 각 DBMS에는 자체 구현이 있습니다. ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.

동시에 여러 공급자를 하나의 애플리케이션에 동시에 등록할 수 있습니다. 이를 통해 예를 들어 하나의 서비스 프레임워크 내에서 인프라 수정 비용 없이 단계별 마이그레이션을 수행할 수 있습니다. 하나의 DBMS에서 다른 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 파일과 클래스를 통해 설명을 사용할 수 있습니다. 단위 테스트에서 스텁 저장소를 편리하게 작성하기 위해 라이브러리가 있습니다. ViennaNET.TestUtils.Orm.

ViennaNET.Orm.* 사용의 전체 예를 찾을 수 있습니다. 여기에.

ViennaNET.Messaging.*

대기열 작업을 위한 라이브러리 세트입니다.

큐 작업을 위해 다양한 DBMS와 동일한 접근 방식, 즉 사용된 큐 관리자에 관계없이 라이브러리 작업 측면에서 가능한 최대 통합 접근 방식이 선택되었습니다. 도서관 ViennaNET.Messaging 이번 통일의 책임은 바로 그분에게 있으며, ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue и ViennaNET.Messaging.KafkaQueue 각각 IBM MQ, RabbitMQ 및 Kafka에 대한 어댑터 구현을 포함합니다.

대기열 작업에는 메시지 수신과 전송이라는 두 가지 프로세스가 있습니다.

받는 것을 고려해 보세요. 여기에는 연속 청취와 단일 메시지 수신이라는 두 가지 옵션이 있습니다. 큐를 지속적으로 수신하려면 먼저 다음에서 상속된 프로세서 클래스를 설명해야 합니다. 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를 통해 요청이 이루어진 방식은 중요하지 않습니다. 그런 다음 나가는 요청이나 메시지를 보내기 전에 컨텍스트에서 데이터를 가져와 헤더에 배치합니다. 따라서 다음 서비스에서도 같은 방법으로 보조데이터를 받아 관리하게 된다.

관심을 가져주셔서 감사합니다. 여러분의 의견과 끌어오기 요청을 기다리겠습니다!

출처 : habr.com