Hendelsesbasert kilde: Implementering av revisjonsspor for robuste og sporbare systemer

I dagens komplekse og sammenkoblede digitale landskap er det avgjørende å opprettholde et robust og omfattende revisjonsspor. Ikke bare er det ofte et lovkrav, men det er også avgjørende for feilsøking, sikkerhetsanalyse og forståelse av utviklingen av systemet ditt. Hendelsesbasert kilde, et arkitekturmønster som fanger alle endringer i en applikasjons tilstand som en sekvens av hendelser, tilbyr en elegant og kraftig løsning for å implementere revisjonsspor som er pålitelige, reviderbare og utvidbare.

Hva er hendelsesbasert kilde?

Tradisjonelle applikasjoner lagrer vanligvis bare gjeldende datatilstand i en database. Denne tilnærmingen gjør det vanskelig å rekonstruere tidligere tilstander eller forstå serien av hendelser som førte til gjeldende tilstand. Hendelsesbasert kilde fokuserer derimot på å fange hver viktig endring i applikasjonens tilstand som en uforanderlig hendelse. Disse hendelsene lagres i et tilleggsbasert hendelseslager, og danner en komplett og kronologisk oversikt over alle handlinger i systemet.

Tenk på det som en bankkontobok. I stedet for bare å registrere gjeldende saldo, registreres hvert innskudd, uttak og overføring som en separat hendelse. Ved å spille av disse hendelsene kan du rekonstruere kontoens tilstand på et hvilket som helst tidspunkt.

Hvorfor bruke hendelsesbasert kilde for revisjonsspor?

Hendelsesbasert kilde tilbyr flere overbevisende fordeler for implementering av revisjonsspor:

• Komplett og uforanderlig historikk: Hver endring fanges som en hendelse, og gir en komplett og uforanderlig oversikt over systemets utvikling. Dette sikrer at revisjonssporet er nøyaktig og manipuleringssikkert.
• Tidsmessig spørring: Du kan enkelt rekonstruere systemets tilstand på et hvilket som helst tidspunkt ved å spille av hendelsene frem til det tidspunktet. Dette muliggjør kraftige tidsmessige spørremuligheter for revisjon og analyse.
• Reviderbart og sporbar: Hver hendelse inkluderer vanligvis metadata som tidsstempel, bruker-ID og transaksjons-ID, noe som gjør det enkelt å spore opprinnelsen og virkningen av hver endring.
• Frakobling og skalerbarhet: Hendelsesbasert kilde fremmer frakobling mellom forskjellige deler av systemet. Hendelser kan konsumeres av flere abonnenter, noe som muliggjør skalerbarhet og fleksibilitet.
• Replaybarhet for feilsøking og gjenoppretting: Hendelser kan spilles av for å gjenskape tidligere tilstander for feilsøkingsformål eller for å gjenopprette fra feil.
• Støtte for CQRS: Hendelsesbasert kilde brukes ofte i forbindelse med Command Query Responsibility Segregation (CQRS)-mønsteret, som skiller lese- og skriveoperasjoner, og forbedrer ytelsen og skalerbarheten ytterligere.

Implementering av hendelsesbasert kilde for revisjonsspor: En trinnvis guide

Her er en praktisk guide til implementering av hendelsesbasert kilde for revisjonsspor:

1. Identifiser nøkkelhendelser

Det første trinnet er å identifisere de viktigste hendelsene du vil fange i revisjonssporet ditt. Disse hendelsene bør representere betydelige endringer i applikasjonens tilstand. Vurder handlinger som:

• Brukerautentisering (pålogging, utlogging)
• Opprettelse, endring og sletting av data
• Transaksjonsinitiering og fullføring
• Konfigurasjonsendringer
• Sikkerhetsrelaterte hendelser (f.eks. endringer i tilgangskontroll)

Eksempel: For en e-handelsplattform kan nøkkelhendelser inkludere «OrderCreated», «PaymentReceived», «OrderShipped», «ProductAddedToCart» og «UserProfileUpdated».

2. Definer hendelsesstruktur

Hver hendelse bør ha en veldefinert struktur som inkluderer følgende informasjon:

• Hendelsestype: En unik identifikator for typen hendelse (f.eks. «OrderCreated»).
• Hendelsesdata: Dataene knyttet til hendelsen, for eksempel ordre-ID, produkt-ID, kunde-ID og betalingsbeløp.
• Tidsstempel: Dato og klokkeslett da hendelsen inntraff. Vurder å bruke UTC for konsistens på tvers av forskjellige tidssoner.
• Bruker-ID: ID-en til brukeren som initierte hendelsen.
• Transaksjons-ID: En unik identifikator for transaksjonen som hendelsen tilhører. Dette er avgjørende for å sikre atomisitet og konsistens på tvers av flere hendelser.
• Korrelasjons-ID: En identifikator som brukes til å spore relaterte hendelser på tvers av forskjellige tjenester eller komponenter. Dette er spesielt nyttig i mikrotjenestearkitekturer.
• Årsaks-ID: (Valgfritt) ID-en til hendelsen som forårsaket denne hendelsen. Dette hjelper til med å spore hendelsenes årsakskjede.
• Metadata: Ytterligere kontekstuell informasjon, for eksempel brukerens IP-adresse, nettlesertype eller geografiske plassering. Vær oppmerksom på databeskyttelsesforskrifter som GDPR når du samler inn og lagrer metadata.

Eksempel: «OrderCreated»-hendelsen kan ha 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. Velg et hendelseslager

Hendelseslageret er det sentrale repositoriet for lagring av hendelser. Det skal være en tilleggsbasert database som er optimalisert for å skrive og lese sekvenser av hendelser. Flere alternativer er tilgjengelige:

• Dedikerte hendelseslagerdatabaser: Dette er databaser spesielt designet for hendelsesbasert kilde, for eksempel EventStoreDB og AxonDB. De tilbyr funksjoner som hendelsesstrømmer, projeksjoner og abonnementer.
• Relasjonsdatabaser: Du kan bruke en relasjonsdatabase som PostgreSQL eller MySQL som et hendelseslager. Du må imidlertid implementere den tilleggsbaserte semantikken og hendelsesstrømstyringen selv. Vurder å bruke en dedikert tabell for hendelser med kolonner for hendelses-ID, hendelsestype, hendelsesdata, tidsstempel og metadata.
• NoSQL-databaser: NoSQL-databaser som MongoDB eller Cassandra kan også brukes som hendelseslagre. De tilbyr fleksibilitet og skalerbarhet, men kan kreve mer innsats for å implementere de nødvendige funksjonene.
• Skybaserte løsninger: Skyleverandører som AWS, Azure og Google Cloud tilbyr administrerte hendelsesstrømstjenester som Kafka, Kinesis og Pub/Sub, som kan brukes som hendelseslagre. Disse tjenestene gir skalerbarhet, pålitelighet og integrasjon med andre skytjenester.

Når du velger et hendelseslager, bør du vurdere faktorer som:

• Skalerbarhet: Kan hendelseslageret håndtere det forventede volumet av hendelser?
• Holdbarhet: Hvor pålitelig er hendelseslageret når det gjelder å forhindre datatap?
• Spørremuligheter: Støtter hendelseslageret de typene spørsmål du trenger for revisjon og analyse?
• Transaksjonsstøtte: Støtter hendelseslageret ACID-transaksjoner for å sikre datakonsistens?
• Integrasjon: Integreres hendelseslageret godt med din eksisterende infrastruktur og verktøy?
• Kostnad: Hva er kostnadene ved å bruke hendelseslageret, inkludert lagring, beregning og nettverkskostnader?

4. Implementer hendelsespublisering

Når en hendelse inntreffer, må applikasjonen din publisere den til hendelseslageret. Dette involverer vanligvis følgende trinn:

• Opprett et hendelsesobjekt: Opprett et hendelsesobjekt som inneholder hendelsestypen, hendelsesdataene, tidsstempelet, bruker-ID-en og andre relevante metadata.
• Serialiser hendelsen: Serialiser hendelsesobjektet til et format som kan lagres i hendelseslageret, for eksempel JSON eller Avro.
• Legg hendelsen til hendelseslageret: Legg den serialiserte hendelsen til hendelseslageret. Sørg for at denne operasjonen er atomisk for å forhindre datakorrupsjon.
• Publiser hendelsen til abonnenter: (Valgfritt) Publiser hendelsen til alle abonnenter som er interessert i å motta den. Dette kan gjøres ved hjelp av en meldingskø eller et publiser-abonner-mønster.

Eksempel (ved hjelp av en hypotetisk EventStoreService):

public class OrderService {

  private final EventStoreService eventStoreService;

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

  public void createOrder(Order order, String userId) {
    // ... forretningslogikk for å opprette ordren ...

    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) {
    // Opprett et hendelsesobjekt
    EventRecord eventRecord = new EventRecord(
        UUID.randomUUID(), // eventId
        streamName,  // streamName
        entityId,   // entityId
        event.getClass().getName(), // eventType
        toJson(event),  // eventData
        Instant.now().toString(), // timestamp
        userId  // userId
    );

    // Serialiser hendelsen
    String serializedEvent = toJson(eventRecord);

    // Legg hendelsen til hendelseslageret (implementeringsspesifikk for det valgte hendelseslageret)
    storeEventInDatabase(serializedEvent);

    // Publiser hendelsen til abonnenter (valgfritt)
    publishEventToMessageQueue(serializedEvent);
  }

  // Plassholder-metoder for database- og meldingskøinteraksjon
  private void storeEventInDatabase(String serializedEvent) {
    // Implementering for å lagre hendelsen i databasen
    System.out.println("Lagrer hendelse i database: " + serializedEvent);
  }

  private void publishEventToMessageQueue(String serializedEvent) {
    // Implementering for å publisere hendelsen til en meldingskø
    System.out.println("Publiserer hendelse til meldingskø: " + serializedEvent);
  }

  private String toJson(Object obj) {
    // Implementering for å serialisere hendelsen til JSON
    try {
      ObjectMapper mapper = new ObjectMapper();
      return mapper.writeValueAsString(obj);
    } catch (Exception e) {
      throw new RuntimeException("Feil ved serialisering av hendelse til 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. Bygg lesemodeller (projeksjoner)

Mens hendelseslageret gir en komplett historikk over alle endringer, er det ofte ikke effektivt å spørre det direkte for leseoperasjoner. I stedet kan du bygge lesemodeller, også kjent som projeksjoner, som er optimalisert for spesifikke spørremønstre. Disse lesemodellene er avledet fra hendelsesstrømmen og oppdateres asynkront når nye hendelser publiseres.

Eksempel: Du kan opprette en lesemodell som inneholder en liste over alle bestillinger for en bestemt kunde, eller en lesemodell som oppsummerer salgsdataene for et bestemt produkt.

For å bygge en lesemodell, abonnerer du på hendelsesstrømmen og behandler hver hendelse. For hver hendelse oppdaterer du lesemodellen tilsvarende.

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);
    }

    // Andre hendelseshåndterere 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 hendelseslageret

Hendelseslageret inneholder sensitive data, så det er avgjørende å sikre det ordentlig. Vurder følgende sikkerhetstiltak:

• Tilgangskontroll: Begrens tilgangen til hendelseslageret til kun autoriserte brukere og applikasjoner. Bruk sterke autentiserings- og autorisasjonsmekanismer.
• Kryptering: Krypter dataene i hendelseslageret i hvile og under transport for å beskytte dem mot uautorisert tilgang. Vurder å bruke krypteringsnøkler administrert av en maskinvaresikkerhetsmodul (HSM) for økt sikkerhet.
• Revisjon: Revisor all tilgang til hendelseslageret for å oppdage og forhindre uautorisert aktivitet.
• Datamasking: Masker sensitive data i hendelseslageret for å beskytte det mot uautorisert utlevering. Du kan for eksempel maskere personlig identifiserbar informasjon (PII) som kredittkortnumre eller personnummer.
• Regelmessige sikkerhetskopier: Sikkerhetskopier hendelseslageret regelmessig for å beskytte mot datatap. Lagre sikkerhetskopier på et sikkert sted.
• Katastrofegjenoppretting: Implementer en katastrofegjenopprettingsplan for å sikre at du kan gjenopprette hendelseslageret i tilfelle en katastrofe.

7. Implementer revisjon og rapportering

Når du har implementert hendelsesbasert kilde, kan du bruke hendelsesstrømmen til å generere revisjonsrapporter og utføre sikkerhetsanalyse. Du kan spørre hendelseslageret for å finne alle hendelser relatert til en bestemt bruker, transaksjon eller enhet. Du kan også bruke hendelsesstrømmen til å rekonstruere systemets tilstand på et hvilket som helst tidspunkt.

Eksempel: Du kan generere en rapport som viser alle endringene som er gjort i en bestemt brukerprofil over en periode, eller en rapport som viser alle transaksjonene som er initiert av en bestemt bruker.

Vurder følgende rapporteringsmuligheter:

• Brukeraktivitetsrapporter: Spor brukerpålogginger, utlogginger og andre aktiviteter.
• Rapporter om dataendringer: Overvåk endringer i kritiske dataenheter.
• Rapporter om sikkerhetshendelser: Varsle om mistenkelig aktivitet, for eksempel mislykkede påloggingsforsøk eller uautoriserte tilgangsforsøk.
• Overholdelsesrapporter: Generer rapporter som kreves for overholdelse av forskrifter (f.eks. GDPR, HIPAA).

Utfordringer ved hendelsesbasert kilde

Mens hendelsesbasert kilde tilbyr mange fordeler, presenterer den også noen utfordringer:

• Kompleksitet: Hendelsesbasert kilde legger til kompleksitet i systemarkitekturen. Du må designe hendelsesstrukturen, velge et hendelseslager og implementere hendelsespublisering og -forbruk.
• Eventuell konsistens: Lesemodeller er til slutt konsistente med hendelsesstrømmen. Dette betyr at det kan være en forsinkelse mellom når en hendelse inntreffer og når lesemodellen oppdateres. Dette kan føre til inkonsekvenser i brukergrensesnittet.
• Hendelsesversjonering: Etter hvert som applikasjonen utvikler seg, må du kanskje endre strukturen til hendelsene dine. Dette kan være utfordrende, siden du må sikre at eksisterende hendelser fortsatt kan behandles riktig. Vurder å bruke teknikker som hendelsesoppkonvertering for å håndtere forskjellige hendelsesversjoner.
• Eventuell konsistens og distribuerte transaksjoner: Implementering av distribuerte transaksjoner med hendelsesbasert kilde kan være komplekst. Du må sørge for at hendelser publiseres og konsumeres på en konsistent måte på tvers av flere tjenester.
• Driftskostnader: Administrering av et hendelseslager og dets tilknyttede infrastruktur kan legge til driftskostnader. Du må overvåke hendelseslageret, sikkerhetskopiere det og sørge for at det kjører jevnt.

Beste praksis for hendelsesbasert kilde

For å redusere utfordringene ved hendelsesbasert kilde, følg disse beste fremgangsmåtene:

• Start lite: Begynn med å implementere hendelsesbasert kilde i en liten del av applikasjonen din. Dette lar deg lære konseptene og få erfaring før du bruker det på mer komplekse områder.
• Bruk et rammeverk: Bruk et rammeverk som Axon Framework eller Spring Cloud Stream for å forenkle implementeringen av hendelsesbasert kilde. Disse rammene gir abstraksjoner og verktøy som kan hjelpe deg med å administrere hendelser, projeksjoner og abonnementer.
• Design hendelser nøye: Design hendelsene dine nøye for å sikre at de fanger all informasjonen du trenger. Unngå å inkludere for mye informasjon i hendelsene, da dette kan gjøre dem vanskelige å behandle.
• Implementer hendelsesoppkonvertering: Implementer hendelsesoppkonvertering for å håndtere endringer i strukturen til hendelsene dine. Dette lar deg behandle eksisterende hendelser selv etter at hendelsesstrukturen er endret.
• Overvåk systemet: Overvåk systemet nøye for å oppdage og forhindre feil. Overvåk hendelseslageret, hendelsespubliseringsprosessen og oppdateringene av lesemodellen.
• Håndter idempotens: Sørg for at hendelseshåndtererne dine er idempotente. Dette betyr at de kan behandle samme hendelse flere ganger uten å forårsake skade. Dette er viktig fordi hendelser kan leveres mer enn én gang i et distribuert system.
• Vurder kompensasjonstransaksjoner: Hvis en operasjon mislykkes etter at en hendelse er publisert, må du kanskje utføre en kompensasjonstransaksjon for å angre endringene. Hvis for eksempel en bestilling opprettes, men betalingen mislykkes, må du kanskje avbestille bestillingen.

Reelle eksempler på hendelsesbasert kilde

Hendelsesbasert kilde brukes i en rekke bransjer og applikasjoner, inkludert:

• Finanstjenester: Banker og finansinstitusjoner bruker hendelsesbasert kilde for å spore transaksjoner, administrere kontoer og oppdage svindel.
• E-handel: E-handelsselskaper bruker hendelsesbasert kilde for å administrere bestillinger, spore lagerbeholdning og tilpasse kundeopplevelsen.
• Spill: Spillutviklere bruker hendelsesbasert kilde for å spore spillets tilstand, administrere spillerens fremgang og implementere flerspillerfunksjoner.
• Supply Chain Management: Supply chain-selskaper bruker hendelsesbasert kilde for å spore varer, administrere lagerbeholdning og optimalisere logistikken.
• Helsevesen: Helseleverandører bruker hendelsesbasert kilde for å spore pasientjournaler, administrere avtaler og forbedre pasientbehandlingen.
• Global logistikk: Selskaper som Maersk eller DHL kan bruke hendelsesbasert kilde for å spore forsendelser over hele verden, og fange hendelser som «ShipmentDepartedPort», «ShipmentArrivedPort», «CustomsClearanceStarted» og «ShipmentDelivered». Dette skaper et komplett revisjonsspor for hver forsendelse.
• Internasjonal bankvirksomhet: Banker som HSBC eller Standard Chartered kan bruke hendelsesbasert kilde for å spore internasjonale pengeoverføringer, og fange hendelser som «TransferInitiated», «CurrencyExchangeExecuted», «FundsSentToBeneficiaryBank» og «FundsReceivedByBeneficiary». Dette bidrar til å sikre overholdelse av forskrifter og letter svindeloppdagelse.

Konklusjon

Hendelsesbasert kilde er et kraftig arkitekturmønster som kan revolusjonere implementeringen av revisjonssporet ditt. Det gir enestående sporbarhet, dataintegritet og systemmotstandskraft. Selv om det presenterer noen utfordringer, oppveier fordelene ved hendelsesbasert kilde ofte kostnadene, spesielt for komplekse og kritiske systemer. Ved å følge den beste praksisen som er skissert i denne guiden, kan du implementere hendelsesbasert kilde og bygge robuste og reviderbare systemer.

Videre lesning

• Event Sourcing av Martin Fowler
• EventStoreDB
• Axon Framework