事件溯源（Event Sourcing）的数据形态与架构解析——以运车服务为例

Hey there! Let's break down Event Sourcing for your vehicle tracking service step by step—since it sounds like you're close but missing the key piece that ties everything together. Let's start by clearing up your two initial misconceptions, then walk through the actual architecture and data flow tailored to your use case.

纠正你对Event Sourcing的两个认知偏差 #

First, let's address your two understandings:

• Misconception 1: Storing full document snapshots on every change
  You're right—this isn't Event Sourcing. Snapshots are an optimization (we'll get to that later), not the core pattern. Storing full snapshots on every change would defeat the purpose of Event Sourcing's lightweight, immutable change logs.
• Misconception 2: Storing change events + a single "current" document as the source of truth
  This is the big one that's throwing you off. In pure Event Sourcing, the sequence of events is the only source of truth. The "current state" you're used to (your non-relational document) is a derived view (called a "read model"), not the single source. If that read model gets corrupted, you can rebuild it entirely by replaying all the events for that vehicle.

结合运单车辆追踪服务的Event Sourcing核心架构 #

Let's map this directly to your vehicle tracking service. Here's how the pieces fit:

1. Define Your Event Types #

First, you'll model every meaningful change to a vehicle as an immutable event. For your use case, these might include:

• VehicleCreatedEvent: Triggered when a new vehicle is added to the system. Contains vehicleId, origin, destination, parcelType, quantity, timestamp, and initial status (e.g., "idle").
• VehicleStatusUpdatedEvent: Triggered when the vehicle's state changes. Contains vehicleId, newStatus, timestamp, and optionally updatedBy.
• ParcelQuantityAdjustedEvent: If the number of parcels changes mid-trip. Contains vehicleId, newQuantity, timestamp.
• DestinationUpdatedEvent: If the delivery destination is modified. Contains vehicleId, newDestination, timestamp.

Each event is immutable—once written, it never gets edited. If you need to fix a mistake (e.g., a wrong status update), you'd create a compensating event like VehicleStatusCorrectedEvent instead of altering the original event.

2. Event Storage: The Single Source of Truth #

You'll use an event store (this can be a specialized tool like EventStoreDB, or even a relational database with tables optimized for event storage) to persist these events. The key rules for event storage:

• Events are grouped by vehicleId (your "aggregate root"—the core entity being tracked).
• Events are stored in the order they occurred (append-only; no updates or deletes).
• Each event has a unique ID, timestamp, and aggregate root ID.

3. Data Flow: From User Action to Frontend Query #

Let's walk through a full example of updating a vehicle's status, from start to finish:

1. User submits a status change: A user (or system) sends a request to update vehicle truck-123 from "idle" to "in-transit".
2. Validate and generate event: Your service first checks if this change is valid (e.g., can a vehicle go from idle to in-transit? Yes). It then creates a VehicleStatusUpdatedEvent with all relevant details.
3. Persist the event: The event is written to the event store. This is an atomic operation—if it fails, the change doesn't happen.
4. Publish the event: Once the event is safely stored, it's published to a message bus (like Kafka or RabbitMQ) so other parts of the system can react to it.
5. Update the read model: A separate "projection service" (this can be part of your main service or an independent service) subscribes to the message bus. When it receives the VehicleStatusUpdatedEvent, it updates the corresponding read model document (your familiar non-relational document for truck-123) to reflect the new status.
6. Frontend queries the read model: When your frontend needs the current state of truck-123, it queries the read model exactly like it did before. The frontend doesn't need to know anything about Event Sourcing—this keeps the user experience unchanged.

4. How Backtracking to Any Time Point Works #

This is the magic of Event Sourcing. To get a vehicle's state at any past time:

• Fetch all events for that vehicleId that occurred before or at the target timestamp.
• Start with an empty initial state, then apply each event in order (e.g., first apply VehicleCreatedEvent to set up the base state, then apply each subsequent event to modify that state).
• The end result is the exact state of the vehicle at that moment.

Snapshots as an Optimization

If a vehicle has thousands of events, replaying all of them every time you need a historical state can be slow. That's where snapshots come in:

• Periodically (e.g., every 100 events for a vehicle, or daily), generate a snapshot of the vehicle's current state and store it.
• When you need to replay events, start with the latest snapshot that's older than your target time, then only replay events that happened after that snapshot. This drastically reduces the number of events you need to process.

Key Differences From Your Current Setup #

• Immutable history: You can't accidentally overwrite past state—every change is logged forever, which is perfect for auditing or debugging issues (e.g., "Why was this vehicle marked as delivered at 2pm?").
• Read model flexibility: If your frontend needs a new view (e.g., a report of all vehicles' status changes in the last week), you can build a new read model by replaying events without changing your core event store.
• Resilience: If your read model gets corrupted, you can rebuild it from scratch by replaying all events—no data loss.

内容的提问来源于stack exchange，提问作者Crislips