Event Sourcing: Implementering af revisionsspor for robuste og sporbar systemer

I nutidens komplekse og sammenkoblede digitale landskab er vedligeholdelse af et robust og omfattende revisionsspor altafgørende. Det er ikke kun ofte et lovkrav, men det er også afgørende for fejlfinding, sikkerhedsanalyse og forståelse af udviklingen af ​​dit system. Event Sourcing, et arkitektonisk mønster, der fanger alle ændringer i en applikations tilstand som en række begivenheder, tilbyder en elegant og kraftfuld løsning til implementering af revisionsspor, der er pålidelige, auditerbare og udvidelige.

Hvad er Event Sourcing?

Traditionelle applikationer gemmer typisk kun den aktuelle tilstand af data i en database. Denne tilgang gør det vanskeligt at rekonstruere tidligere tilstande eller forstå den række af begivenheder, der førte til den aktuelle tilstand. Event Sourcing fokuserer derimod på at fange enhver væsentlig ændring af applikationens tilstand som en uforanderlig begivenhed. Disse begivenheder gemmes i en event store, der kun tillægger, hvilket danner en komplet og kronologisk registrering af alle handlinger inden for systemet.

Tænk på det som en bankkontobog. I stedet for blot at registrere den aktuelle saldo, registreres hver indbetaling, hævning og overførsel som en separat begivenhed. Ved at afspille disse begivenheder kan du rekonstruere kontoens tilstand på ethvert tidspunkt.

Hvorfor bruge Event Sourcing til revisionsspor?

Event Sourcing tilbyder flere overbevisende fordele ved implementering af revisionsspor:

• Komplet og uforanderlig historik: Hver ændring fanges som en begivenhed, der giver en komplet og uforanderlig registrering af systemets udvikling. Dette sikrer, at revisionssporet er nøjagtigt og manipulationssikkert.
• Tidsmæssig forespørgsel: Du kan nemt rekonstruere systemets tilstand på ethvert tidspunkt ved at afspille begivenhederne indtil det tidspunkt. Dette muliggør kraftfulde tidsmæssige forespørgselsfunktioner til revision og analyse.
• Auditerbar og sporbar: Hver begivenhed indeholder typisk metadata som tidsstempel, bruger-id og transaktions-id, hvilket gør det nemt at spore oprindelsen og virkningen af ​​hver ændring.
• Afkobling og skalerbarhed: Event Sourcing fremmer afkobling mellem forskellige dele af systemet. Begivenheder kan forbruges af flere abonnenter, hvilket muliggør skalerbarhed og fleksibilitet.
• Afspilbarhed til fejlfinding og genoprettelse: Begivenheder kan afspilles for at genskabe tidligere tilstande til fejlfindingsformål eller for at gendanne fra fejl.
• Understøttelse af CQRS: Event Sourcing bruges ofte i forbindelse med Command Query Responsibility Segregation (CQRS)-mønsteret, som adskiller læse- og skriveoperationer, hvilket yderligere forbedrer ydeevnen og skalerbarheden.

Implementering af Event Sourcing til revisionsspor: En trin-for-trin-guide

Her er en praktisk guide til implementering af Event Sourcing til revisionsspor:

1. Identificer nøglebegivenheder

Det første trin er at identificere de vigtigste begivenheder, du vil fange i dit revisionsspor. Disse begivenheder skal repræsentere væsentlige ændringer af applikationens tilstand. Overvej handlinger som:

• Brugergodkendelse (login, logout)
• Oprettelse, ændring og sletning af data
• Initiering og afslutning af transaktioner
• Konfigurationsændringer
• Sikkerhedsrelaterede begivenheder (f.eks. ændringer i adgangskontrol)

Eksempel: For en e-handelsplatform kan nøglebegivenheder omfatte "OrderOprettet", "BetalingModtaget", "OrdreForsendt", "ProduktTilføjetTilKurv" og "BrugerProfilOpdateret".

2. Definer begivenhedsstruktur

Hver begivenhed skal have en veldefineret struktur, der indeholder følgende oplysninger:

• Begivenhedstype: En unik identifikator for typen af ​​begivenhed (f.eks. "OrderOprettet").
• Begivenhedsdata: De data, der er knyttet til begivenheden, såsom ordre-id, produkt-id, kunde-id og betalingsbeløb.
• Tidsstempel: Dato og klokkeslæt, hvor begivenheden fandt sted. Overvej at bruge UTC for konsistens på tværs af forskellige tidszoner.
• Bruger-id: Id'et for den bruger, der startede begivenheden.
• Transaktions-id: En unik identifikator for den transaktion, som begivenheden tilhører. Dette er afgørende for at sikre atomicitet og konsistens på tværs af flere begivenheder.
• Korrelations-id: En identifikator, der bruges til at spore relaterede begivenheder på tværs af forskellige tjenester eller komponenter. Dette er især nyttigt i mikrotjenestearkitekturer.
• Årsags-id: (Valgfrit) Id'et for den begivenhed, der forårsagede denne begivenhed. Dette hjælper med at spore den årsagsmæssige kæde af begivenheder.
• Metadata: Yderligere kontekstuelle oplysninger, såsom brugerens IP-adresse, browsertype eller geografiske placering. Vær opmærksom på databeskyttelsesforordninger som GDPR, når du indsamler og gemmer metadata.

Eksempel: "OrderOprettet"-begivenheden kan have følgende struktur:

{
  "eventType": "OrderCreated",
  "eventData": {
    "orderId": "12345",
    "customerId": "67890",
    "orderDate": "2023-10-27T10:00:00Z",
    "totalAmount": 100.00,
    "currency": "USD",
    "shippingAddress": {
      "street": "123 Main St",
      "city": "Anytown",
      "state": "CA",
      "zipCode": "91234",
      "country": "USA"
    }
  },
  "timestamp": "2023-10-27T10:00:00Z",
  "userId": "user123",
  "transactionId": "tx12345",
  "correlationId": "corr123",
  "metadata": {
    "ipAddress": "192.168.1.1",
    "browser": "Chrome",
    "location": {
       "latitude": 34.0522,
       "longitude": -118.2437
    }
  }
}

3. Vælg en Event Store

Event store er det centrale depot til lagring af begivenheder. Det skal være en database, der kun tillægger, og som er optimeret til at skrive og læse sekvenser af begivenheder. Der er flere muligheder:

• Dedikerede Event Store-databaser: Dette er databaser, der er specielt designet til Event Sourcing, såsom EventStoreDB og AxonDB. De tilbyder funktioner som event streams, projektioner og abonnementer.
• Relationale databaser: Du kan bruge en relationel database som PostgreSQL eller MySQL som en event store. Du skal dog selv implementere semantikken for kun at tillægge og event stream-styring. Overvej at bruge en dedikeret tabel til begivenheder med kolonner til event-id, eventtype, eventdata, tidsstempel og metadata.
• NoSQL-databaser: NoSQL-databaser som MongoDB eller Cassandra kan også bruges som event stores. De tilbyder fleksibilitet og skalerbarhed, men kan kræve mere indsats for at implementere de nødvendige funktioner.
• Cloud-baserede løsninger: Cloud-udbydere som AWS, Azure og Google Cloud tilbyder administrerede event streaming-tjenester som Kafka, Kinesis og Pub/Sub, som kan bruges som event stores. Disse tjenester giver skalerbarhed, pålidelighed og integration med andre cloud-tjenester.

Når du vælger en event store, skal du overveje faktorer som:

• Skalerbarhed: Kan event store håndtere den forventede mængde af begivenheder?
• Holdbarhed: Hvor pålidelig er event store med hensyn til forebyggelse af datatab?
• Forespørgselsfunktioner: Understøtter event store de typer af forespørgsler, du har brug for til revision og analyse?
• Transaktionssupport: Understøtter event store ACID-transaktioner for at sikre datakonsistens?
• Integration: Integreres event store godt med din eksisterende infrastruktur og værktøjer?
• Omkostninger: Hvad er omkostningerne ved at bruge event store, inklusive lager-, beregnings- og netværksomkostninger?

4. Implementer begivenhedspublicering

Når en begivenhed opstår, skal din applikation offentliggøre den til event store. Dette involverer typisk følgende trin:

• Opret et begivenhedsobjekt: Opret et begivenhedsobjekt, der indeholder begivenhedstypen, begivenhedsdata, tidsstempel, bruger-id og andre relevante metadata.
• Serialiser begivenheden: Serialiser begivenhedsobjektet til et format, der kan gemmes i event store, såsom JSON eller Avro.
• Tillæg begivenheden til Event Store: Tillæg den serialiserede begivenhed til event store. Sørg for, at denne handling er atomisk for at forhindre datakorruption.
• Publicer begivenheden til abonnenter: (Valgfrit) Publicer begivenheden til alle abonnenter, der er interesserede i at modtage den. Dette kan gøres ved hjælp af en meddelelseskø eller et publicer-abonner-mønster.

Eksempel (ved hjælp af en hypotetisk EventStoreService):

public class OrderService {

  private final EventStoreService eventStoreService;

  public OrderService(EventStoreService eventStoreService) {
    this.eventStoreService = eventStoreService;
  }

  public void createOrder(Order order, String userId) {
    // ... business logic to create the order ...

    OrderCreatedEvent event = new OrderCreatedEvent(
        order.getOrderId(),
        order.getCustomerId(),
        order.getOrderDate(),
        order.getTotalAmount(),
        order.getCurrency(),
        order.getShippingAddress()
    );

    eventStoreService.appendEvent("order", order.getOrderId(), event, userId);
  }
}

public class EventStoreService {

  public void appendEvent(String streamName, String entityId, Object event, String userId) {
    // Create an event object
    EventRecord eventRecord = new EventRecord(
        UUID.randomUUID(), // eventId
        streamName,  // streamName
        entityId,   // entityId
        event.getClass().getName(), // eventType
        toJson(event),  // eventData
        Instant.now().toString(), // timestamp
        userId  // userId
    );

    // Serialize the event
    String serializedEvent = toJson(eventRecord);

    // Append the event to the event store (implementation specific to the chosen event store)
    storeEventInDatabase(serializedEvent);

    // Publish the event to subscribers (optional)
    publishEventToMessageQueue(serializedEvent);
  }

  // Placeholder methods for database and message queue interaction
  private void storeEventInDatabase(String serializedEvent) {
    // Implementation to store the event in the database
    System.out.println("Storing event in database: " + serializedEvent);
  }

  private void publishEventToMessageQueue(String serializedEvent) {
    // Implementation to publish the event to a message queue
    System.out.println("Publishing event to message queue: " + serializedEvent);
  }

  private String toJson(Object obj) {
    // Implementation to serialize the event to JSON
    try {
      ObjectMapper mapper = new ObjectMapper();
      return mapper.writeValueAsString(obj);
    } catch (Exception e) {
      throw new RuntimeException("Error serializing event to JSON", e);
    }
  }
}


class EventRecord {
  private final UUID eventId;
  private final String streamName;
  private final String entityId;
  private final String eventType;
  private final String eventData;
  private final String timestamp;
  private final String userId;

  public EventRecord(UUID eventId, String streamName, String entityId, String eventType, String eventData, String timestamp, String userId) {
    this.eventId = eventId;
    this.streamName = streamName;
    this.entityId = entityId;
    this.eventType = eventType;
    this.eventData = eventData;
    this.timestamp = timestamp;
    this.userId = userId;
  }

  // Getters

  @Override
  public String toString() {
    return "EventRecord{" +
        "eventId=" + eventId +
        ", streamName='" + streamName + '\'' +
        ", entityId='" + entityId + '\'' +
        ", eventType='" + eventType + '\'' +
        ", eventData='" + eventData + '\'' +
        ", timestamp='" + timestamp + '\'' +
        ", userId='" + userId + '\'' +
        '}';
  }
}

class OrderCreatedEvent {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;
    private final String shippingAddress;

    public OrderCreatedEvent(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Getters for all fields

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "OrderCreatedEvent{" +
                "orderId='" + orderId + '\'' +
                ", customerId='" + customerId + '\'' +
                ", orderDate='" + orderDate + '\'' +
                ", totalAmount=" + totalAmount +
                ", currency='" + currency + '\'' +
                ", shippingAddress='" + shippingAddress + '\'' +
                '}';
    }
}

class Order {
  private final String orderId;
  private final String customerId;
  private final String orderDate;
  private final double totalAmount;
  private final String currency;
  private final String shippingAddress;

  public Order(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Getters for all fields

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "Order{" +
                "orderId='" + orderId + '\'' +
                ", customerId='" + customerId + '\'' +
                ", orderDate='" + orderDate + '\'' +
                ", totalAmount=" + totalAmount +
                ", currency='" + currency + '\'' +
                ", shippingAddress='" + shippingAddress + '\'' +
                '}';
    }
}

5. Byg læsemodeller (projektioner)

Mens event store giver en komplet historik over alle ændringer, er det ofte ikke effektivt at spørge den direkte efter læseoperationer. I stedet kan du bygge læsemodeller, også kendt som projektioner, der er optimeret til specifikke forespørgselsmønstre. Disse læsemodeller er afledt af event streamen og opdateres asynkront, når nye begivenheder publiceres.

Eksempel: Du kan oprette en læsemodel, der indeholder en liste over alle ordrer for en bestemt kunde, eller en læsemodel, der opsummerer salgsdataene for et bestemt produkt.

For at opbygge en læsemodel abonnerer du på event streamen og behandler hver begivenhed. For hver begivenhed opdaterer du læsemodellen i overensstemmelse hermed.

Eksempel:

public class OrderSummaryReadModelUpdater {

    private final OrderSummaryRepository orderSummaryRepository;

    public OrderSummaryReadModelUpdater(OrderSummaryRepository orderSummaryRepository) {
        this.orderSummaryRepository = orderSummaryRepository;
    }

    public void handle(OrderCreatedEvent event) {
        OrderSummary orderSummary = new OrderSummary(
                event.getOrderId(),
                event.getCustomerId(),
                event.getOrderDate(),
                event.getTotalAmount(),
                event.getCurrency()
        );

        orderSummaryRepository.save(orderSummary);
    }

    // Other event handlers for PaymentReceivedEvent, OrderShippedEvent, etc.
}

interface OrderSummaryRepository {
    void save(OrderSummary orderSummary);
}

class OrderSummary {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;

    public OrderSummary(String orderId, String customerId, String orderDate, double totalAmount, String currency) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
    }
    //Getters
}

6. Sikre event store

Event store indeholder følsomme data, så det er afgørende at sikre det korrekt. Overvej følgende sikkerhedsforanstaltninger:

• Adgangskontrol: Begræns adgangen til event store til kun autoriserede brugere og applikationer. Brug stærke godkendelses- og autorisationsmekanismer.
• Kryptering: Krypter dataene i event store i hvile og under transport for at beskytte dem mod uautoriseret adgang. Overvej at bruge krypteringsnøgler, der administreres af et Hardware Security Module (HSM), for øget sikkerhed.
• Revision: Revisor alle adgang til event store for at opdage og forhindre uautoriseret aktivitet.
• Datamaskering: Maskér følsomme data i event store for at beskytte den mod uautoriseret videregivelse. Du kan for eksempel maskere personligt identificerbare oplysninger (PII) som kreditkortnumre eller personnumre.
• Regelmæssige sikkerhedskopier: Sikkerhedskopier event store regelmæssigt for at beskytte mod datatab. Opbevar sikkerhedskopier på et sikkert sted.
• Katastrofegendannelse: Implementer en katastrofegendannelsesplan for at sikre, at du kan gendanne event store i tilfælde af en katastrofe.

7. Implementer revision og rapportering

Når du har implementeret Event Sourcing, kan du bruge event stream til at generere revisionsrapporter og udføre sikkerhedsanalyse. Du kan forespørge event store for at finde alle begivenheder relateret til en specifik bruger, transaktion eller enhed. Du kan også bruge event streamen til at rekonstruere systemets tilstand på ethvert tidspunkt.

Eksempel: Du kan generere en rapport, der viser alle de ændringer, der er foretaget i en bestemt brugerprofil over en periode, eller en rapport, der viser alle de transaktioner, der er startet af en bestemt bruger.

Overvej følgende rapporteringsfunktioner:

• Brugeraktivitetsrapporter: Spor brugerlogin, logout og andre aktiviteter.
• Dataændringsrapporter: Overvåg ændringer i kritiske dataenheder.
• Sikkerhedsbegivenhedsrapporter: Advar om mistænkelig aktivitet, såsom mislykkede login-forsøg eller uautoriserede adgangsforsøg.
• Overensstemmelsesrapporter: Generer rapporter, der kræves til overholdelse af lovgivningen (f.eks. GDPR, HIPAA).

Udfordringer ved Event Sourcing

Selvom Event Sourcing tilbyder mange fordele, præsenterer det også nogle udfordringer:

• Kompleksitet: Event Sourcing tilføjer kompleksitet til systemarkitekturen. Du skal designe begivenhedsstrukturen, vælge en event store og implementere begivenhedspublicering og -forbrug.
• Eventuel konsistens: Læsemodeller er i sidste ende konsistente med event stream. Det betyder, at der kan være en forsinkelse mellem, hvornår en begivenhed opstår, og hvornår læsemodellen opdateres. Dette kan føre til inkonsistenser i brugergrænsefladen.
• Begivenhedsversionering: Efterhånden som din applikation udvikler sig, skal du muligvis ændre strukturen af ​​dine begivenheder. Dette kan være udfordrende, da du skal sikre, at eksisterende begivenheder stadig kan behandles korrekt. Overvej at bruge teknikker som event upcasting til at håndtere forskellige begivenhedsversioner.
• Eventuel konsistens og distribuerede transaktioner: Implementering af distribuerede transaktioner med Event Sourcing kan være kompleks. Du skal sikre, at begivenheder publiceres og forbruges på en ensartet måde på tværs af flere tjenester.
• Operationelle omkostninger: Administration af en event store og dens tilknyttede infrastruktur kan tilføje operationelle omkostninger. Du skal overvåge event store, sikkerhedskopiere den og sikre, at den kører problemfrit.

Bedste praksis for Event Sourcing

For at afbøde udfordringerne ved Event Sourcing skal du følge disse bedste fremgangsmåder:

• Start småt: Begynd med at implementere Event Sourcing i en lille del af din applikation. Dette giver dig mulighed for at lære koncepterne og få erfaring, før du anvender det på mere komplekse områder.
• Brug en ramme: Brug en ramme som Axon Framework eller Spring Cloud Stream til at forenkle implementeringen af ​​Event Sourcing. Disse rammer giver abstraktioner og værktøjer, der kan hjælpe dig med at administrere begivenheder, projektioner og abonnementer.
• Design begivenheder omhyggeligt: Design dine begivenheder omhyggeligt for at sikre, at de fanger alle de oplysninger, du har brug for. Undgå at inkludere for mange oplysninger i begivenhederne, da dette kan gøre dem vanskelige at behandle.
• Implementer Event Upcasting: Implementer event upcasting for at håndtere ændringer af strukturen af ​​dine begivenheder. Dette giver dig mulighed for at behandle eksisterende begivenheder, selv efter at begivenhedsstrukturen er ændret.
• Overvåg systemet: Overvåg systemet tæt for at opdage og forhindre fejl. Overvåg event store, begivenhedspubliceringsprocessen og læsemodelopdateringerne.
• Håndter idempotens: Sørg for, at dine begivenhedshåndterere er idempotente. Det betyder, at de kan behandle den samme begivenhed flere gange uden at forårsage skade. Dette er vigtigt, fordi begivenheder kan leveres mere end én gang i et distribueret system.
• Overvej kompenserende transaktioner: Hvis en operation mislykkes, efter at en begivenhed er blevet publiceret, skal du muligvis udføre en kompenserende transaktion for at fortryde ændringerne. For eksempel, hvis en ordre oprettes, men betalingen mislykkes, skal du muligvis annullere ordren.

Reelle eksempler på Event Sourcing

Event Sourcing bruges i en række brancher og applikationer, herunder:

• Finansielle tjenester: Banker og finansielle institutioner bruger Event Sourcing til at spore transaktioner, administrere konti og opdage svindel.
• E-handel: E-handelsvirksomheder bruger Event Sourcing til at administrere ordrer, spore lagerbeholdning og personalisere kundeoplevelsen.
• Spil: Spiludviklere bruger Event Sourcing til at spore spiltilstand, administrere spilleres fremskridt og implementere multiplayer-funktioner.
• Supply Chain Management: Supply chain-virksomheder bruger Event Sourcing til at spore varer, administrere lagerbeholdning og optimere logistik.
• Sundhedspleje: Sundhedsudbydere bruger Event Sourcing til at spore patientjournaler, administrere aftaler og forbedre patientplejen.
• Global logistik: Virksomheder som Maersk eller DHL kan bruge event sourcing til at spore forsendelser over hele kloden og fange begivenheder som "ForsendelseForlodHavn", "ForsendelseAnkomHavn", "ToldbehandlingStartet" og "ForsendelseLeveret". Dette skaber et komplet revisionsspor for hver forsendelse.
• International bankvirksomhed: Banker som HSBC eller Standard Chartered kan bruge event sourcing til at spore internationale pengeoverførsler og fange begivenheder som "OverførselInitieret", "ValutavekslingUdført", "MidlerSendtTilModtagerbank" og "MidlerModtagetAfModtager". Dette hjælper med at sikre overholdelse af lovgivningen og letter svindeldetektion.

Konklusion

Event Sourcing er et kraftfuldt arkitektonisk mønster, der kan revolutionere din revisionssporimplementering. Det giver uovertruffen sporbarhed, dataintegritet og systemresiliens. Selvom det præsenterer nogle udfordringer, opvejer fordelene ved Event Sourcing ofte omkostningerne, især for komplekse og kritiske systemer. Ved at følge den bedste praksis, der er beskrevet i denne guide, kan du med succes implementere Event Sourcing og bygge robuste og auditerbare systemer.

Yderligere læsning

• Event Sourcing af Martin Fowler
• EventStoreDB
• Axon Framework