Lần đầu vào một dự án microservices, thứ làm bạn choáng thường không phải là code. Đó là một buổi họp kiểu: “Order service publish event qua outbox, payment consumer phải idempotent, nếu fail thì saga compensate, nhớ gắn correlation ID để trace.” Câu nào cũng có tiếng Việt, mà nghe không hiểu gì.

Glossary thì có rất nhiều. Vấn đề là học từng định nghĩa riêng lẻ thì mau quên. Lý do là bạn không thấy thuật ngữ đó sinh ra để chữa bệnh gì.

Bài này làm ngược lại: đi theo một request đặt hàng, từ lúc user bấm “Đặt hàng” đến khi đơn được xác nhận. Tới chỗ nào có vấn đề, thuật ngữ tương ứng sẽ xuất hiện. Đây là bài mở đầu của series Microservices từ A–Z. Mỗi nhóm thuật ngữ bên dưới sẽ có bài riêng để đi sâu, kèm code .NET.

Hệ thống ví dụ#

Một shop online nhỏ, tách thành 4 service:

• Order Service: tạo và quản lý đơn hàng
• Payment Service: trừ tiền
• Inventory Service: giữ hàng trong kho
• Notification Service: gửi email/SMS

flowchart LR
    C["Client (Web/Mobile)"] --> GW["API Gateway"]
    GW --> O["Order Service"]
    O --> ODB[("Order DB")]
    O -- "OrderCreated" --> MB{{"Message Broker"}}
    MB --> P["Payment Service"]
    MB --> I["Inventory Service"]
    MB --> N["Notification Service"]
    P --> PDB[("Payment DB")]
    I --> IDB[("Inventory DB")]

Cả series dùng lại đúng hệ thống này.

Chặng 0: Vì sao lại tách ra?#

Trước khi có 4 service, hệ thống thường bắt đầu là một khối.

WARNING

Microservices là giải pháp cho vấn đề tổ chức và scale team, trước khi là vấn đề kỹ thuật. Nếu team bạn có 3 người, gần như chắc chắn bạn chưa cần nó. Bài P2 sẽ nói kỹ chuyện này.

Chặng 1: Tách thế nào cho đúng — DDD#

Câu hỏi đầu tiên: ranh giới giữa Order và Payment nằm ở đâu? Tách sai thì sau này hai service phải gọi nhau liên tục, tức là bạn có một distributed monolith: tệ hơn cả monolith gốc.

Chặng 2: Request đi vào — Giao tiếp & API#

User bấm “Đặt hàng”. Request từ mobile app đi vào hệ thống.

Order Service nhận request, lưu đơn trạng thái Pending. Bây giờ nó cần báo cho Payment và Inventory.

Chặng 3: Báo cho service khác — Messaging#

Order có thể gọi thẳng HTTP sang Payment. Nhưng nếu Payment đang chết, đơn hàng cũng chết theo. Cách phổ biến hơn là bắn event rồi đi tiếp.

Chặng 4: Dữ liệu nằm rải rác — Nhất quán#

Đây là chặng khó nhất, và cũng là chỗ phỏng vấn system design hay đào sâu nhất.

Mỗi service giữ database riêng (Database per Service). Vậy “tạo đơn + trừ tiền + giữ hàng” không còn gói gọn trong một transaction nữa. Chuyện gì xảy ra nếu trừ tiền xong mà kho báo hết hàng?

Outbox trong EF Core, ý tưởng cốt lõi chỉ có vậy:

await using var tx = await db.Database.BeginTransactionAsync(ct);

db.Orders.Add(order);
db.OutboxMessages.Add(OutboxMessage.From(new OrderCreated(order.Id, order.Total)));

await db.SaveChangesAsync(ct);   // đơn hàng và message commit cùng lúc
await tx.CommitAsync(ct);
// Background worker đọc OutboxMessages chưa gửi → publish lên broker → đánh dấu đã gửi

Và phía consumer, idempotent bằng cách nhớ message nào đã xử lý:

public async Task Consume(ConsumeContext<OrderCreated> context)
{
    var messageId = context.MessageId!.Value;
    if (await db.ProcessedMessages.AnyAsync(m => m.Id == messageId))
        return; // đã xử lý rồi, bỏ qua

    await paymentService.ChargeAsync(context.Message.OrderId, context.Message.Total);
    db.ProcessedMessages.Add(new ProcessedMessage(messageId));
    await db.SaveChangesAsync();
}

TIP

MassTransit và Wolverine đều có sẵn Outbox/Inbox. Trong dự án thật, bạn nên dùng sẵn thay vì tự viết. Các đoạn code trên chỉ để hiểu cơ chế. Đoạn consumer trên còn một lỗ: hai bản sao cùng message đến song song thì cả hai đều qua được bước AnyAsync. Bản thật cần unique constraint trên ProcessedMessages.Id và ghi nó cùng transaction với nghiệp vụ. Bài về Idempotent Consumer sẽ đi vào chi tiết.

Chặng 5: Có service bị chậm — Độ tin cậy#

Payment Service gọi sang cổng thanh toán bên ngoài, và cổng này thỉnh thoảng mất 30 giây mới trả lời. Nếu không làm gì, thread của Payment sẽ bị giữ hết, rồi Payment chết, rồi mọi thứ gọi Payment cũng chết theo. Đó là cascading failure.

Từ .NET 8, package Microsoft.Extensions.Http.Resilience gói sẵn mấy thứ này cho HttpClient:

builder.Services.AddHttpClient<PaymentGatewayClient>()
    .AddStandardResilienceHandler(); // timeout + retry + circuit breaker, dựng trên Polly v8

Chặng 6: Có bug trên production — Observability#

Khách báo: “Tôi bị trừ tiền mà đơn vẫn Pending”. Request đó đã đi qua 4 service và 1 broker. Log nằm ở 4 chỗ khác nhau. Bạn tìm bằng cách nào?

NOTE

Observability không phải “có log là đủ”. Câu hỏi đúng là: khi có sự cố chưa từng gặp, bạn có trả lời được “chuyện gì đang xảy ra” chỉ bằng dữ liệu hệ thống đang phát ra không.

Chặng 7: Deploy và vận hành#

Order Service vừa có bản mới. Làm sao deploy mà không làm gián đoạn 3 service còn lại?

Mình đã viết về Feature Flags trong .NET ở một bài riêng, nếu bạn muốn đọc trước.

Nhìn lại cả hành trình của đơn hàng#

sequenceDiagram
    participant C as Client
    participant GW as API Gateway
    participant O as Order Service
    participant MB as Broker
    participant P as Payment
    participant I as Inventory

    C->>GW: POST /orders (JWT)
    GW->>O: route + Correlation ID
    O->>O: Lưu Order + Outbox (1 transaction)
    O-->>C: 202 Accepted (Pending)
    O->>MB: OrderCreated (outbox worker)
    MB->>P: OrderCreated
    P->>P: Idempotent check → charge (retry, circuit breaker)
    P->>MB: PaymentSucceeded
    MB->>I: PaymentSucceeded
    I-->>MB: InventoryFailed (hết hàng)
    MB->>P: InventoryFailed → Refund (compensate)
    MB->>O: InventoryFailed → Order Cancelled

Đọc lại buổi họp ở đầu bài: “Order service publish event qua outbox, payment consumer phải idempotent, nếu fail thì saga compensate, nhớ gắn correlation ID để trace.” Giờ mỗi cụm từ đều có một chỗ đứng trong hình trên.

Đọc tiếp trong series#

Series này có 22 bài, chia theo đúng các chặng ở trên:

1. Nền tảng: bài này, và P2: Khi nào không nên dùng microservices
2. Phân rã: DDD & Bounded Context, Database per Service, Strangler Fig & ACL
3. Giao tiếp: API Gateway & BFF với YARP, Messaging, Kafka vs RabbitMQ
4. Nhất quán dữ liệu: Saga, Outbox, Idempotent Consumer, CQRS, Event Sourcing
5. Độ tin cậy: Retry, Timeout, Circuit Breaker, Bulkhead với Polly
6. Observability: Logging, Tracing, Health check với OpenTelemetry
7. Triển khai: Service Discovery, Service Mesh, Canary, Contract Testing

NOTE

Tham khảo khi viết series: microservices.vn (bộ thuật ngữ và pattern tiếng Việt rất đầy đủ), microservices.io của Chris Richardson, và Building Microservices (Sam Newman, 2nd edition).