Skip to main content

Giao tiếp giữa các services trong microservices

Trong kiến trúc microservices, các dịch vụ thường phải giao tiếp với nhau để trao đổi dữ liệu và thực hiện các nghiệp vụ phức tạp. Việc lựa chọn phương pháp liên lạc giữa các service không chỉ ảnh hưởng đến hiệu năng mà còn tác động đến độ tin cậy, khả năng mở rộng và bảo trì hệ thống. Dưới đây là một số phương pháp liên lạc phổ biến giữa các services trong microservices, kèm theo ví dụ chi tiết:

1. Giao tiếp đồng bộ qua RESTful API​

Mô tả:
REST (Representational State Transfer) là kiến trúc giao tiếp dựa trên giao thức HTTP, sử dụng các phương thức như GET, POST, PUT, DELETE để thực hiện các thao tác trên tài nguyên. Đây là phương pháp phổ biến nhất vì tính đơn giản, khả năng tương thích cao và dễ triển khai.

Ưu điểm:

  • Đơn giản, chuẩn mực và dễ hiểu.
  • Hỗ trợ JSON/XML, dễ dàng tích hợp với các ứng dụng web.
  • Có thể tận dụng hầu hết các framework, thư viện có sẵn.

Nhược điểm:

  • Giao tiếp đồng bộ có thể gây ra độ trễ nếu một service bị nghẽn.
  • Khó xử lý lỗi và tái khởi động trong trường hợp có nhiều service phụ thuộc lẫn nhau.

Ví dụ chi tiết:
Giả sử ta có dịch vụ User Service và Order Service. Khi Order Service cần thông tin của người dùng, nó gửi một HTTP GET request đến User Service theo địa chỉ http://user-service/api/users/{userId} và nhận lại dữ liệu người dùng dưới dạng JSON.

GET http://user-service/api/users/123
Response:
{
  "id": 123,
  "name": "Nguyễn Văn A",
  "email": "nguyenvana@example.com"
}

2. Giao tiếp đồng bộ qua gRPC​

Mô tả:
gRPC là một framework RPC (Remote Procedure Call) mã nguồn mở do Google phát triển, cho phép các service giao tiếp với nhau thông qua giao thức HTTP/2 và định dạng dữ liệu Protobuf. gRPC hỗ trợ các ngôn ngữ lập trình khác nhau và có hiệu năng rất cao nhờ việc truyền dữ liệu nhị phân.

Ưu điểm:

  • Hiệu năng cao với tốc độ truyền tải và xử lý dữ liệu nhanh.
  • Hỗ trợ đa ngôn ngữ và tích hợp dễ dàng.
  • Giao tiếp qua HTTP/2 cho phép truyền tải song song và tối ưu hoá kết nối.

Nhược điểm:

  • Đòi hỏi phải học và làm quen với Protobuf.
  • Ít thân thiện với trình duyệt so với RESTful API.

Ví dụ chi tiết:
Giả sử dịch vụ Payment Service cần xác nhận đơn hàng từ Order Service. Hai service sẽ định nghĩa giao thức bằng file .proto như sau:

syntax = "proto3";

service OrderService {
  rpc GetOrder (OrderRequest) returns (OrderResponse);
}

message OrderRequest {
  int32 order_id = 1;
}

message OrderResponse {
  int32 order_id = 1;
  string status = 2;
  double amount = 3;
}

Khi Payment Service gọi phương thức GetOrder, hệ thống sẽ thực hiện gọi RPC qua HTTP/2, chuyển dữ liệu theo định dạng Protobuf để lấy thông tin đơn hàng.

3. Giao tiếp không đồng bộ qua Message Queue​

Mô tả:
Sử dụng hệ thống hàng đợi (message queue) như RabbitMQ, Apache Kafka, hay ActiveMQ để các service gửi và nhận thông điệp không đồng bộ. Phương pháp này giúp giảm tải cho các service và cho phép xử lý dữ liệu theo luồng bất đồng bộ.

Ưu điểm:

  • Giảm sự phụ thuộc lẫn nhau giữa các service (loose coupling).
  • Hỗ trợ khả năng mở rộng và chịu lỗi cao.
  • Phù hợp cho các tác vụ xử lý theo luồng (asynchronous processing).

Nhược điểm:

  • Độ trễ có thể cao hơn so với giao tiếp đồng bộ.
  • Cần thêm công đoạn quản lý và giám sát hệ thống hàng đợi.

Ví dụ chi tiết:
Khi có một đơn hàng mới được tạo ra, Order Service sẽ gửi một thông điệp (message) vào hàng đợi "order_created". Các service khác như Email Service hoặc Inventory Service sẽ đăng ký (subscribe) và nhận thông điệp này để thực hiện các nghiệp vụ như gửi email xác nhận đơn hàng hay cập nhật số lượng hàng tồn kho.

Message gửi từ Order Service:
{
  "order_id": 456,
  "user_id": 123,
  "items": [
    {"product_id": 789, "quantity": 2},
    {"product_id": 101, "quantity": 1}
  ],
  "total_amount": 1500000
}

4. Giao tiếp theo mô hình Event-Driven​

Mô tả:
Trong kiến trúc hướng sự kiện (event-driven), các service không giao tiếp trực tiếp với nhau mà thay vào đó phát ra các sự kiện khi có thay đổi trạng thái. Các service quan tâm sẽ lắng nghe và xử lý các sự kiện này.

Ưu điểm:

  • Tăng tính mở rộng và khả năng chịu lỗi.
  • Giảm sự phụ thuộc chặt chẽ giữa các service.
  • Hỗ trợ xử lý thời gian thực và phân tán dữ liệu.

Nhược điểm:

  • Phức tạp trong việc theo dõi và gỡ lỗi các luồng sự kiện.
  • Yêu cầu thiết kế hệ thống xử lý sự kiện cẩn thận để tránh mất mát hoặc trùng lặp thông tin.

Ví dụ chi tiết:
Giả sử khi một sản phẩm trong kho được bán hết, Inventory Service phát ra sự kiện ProductOutOfStock. Các service như Notification Service sẽ lắng nghe sự kiện này và gửi thông báo cho các khách hàng đang theo dõi sản phẩm.

Event: ProductOutOfStock
Data:
{
  "product_id": 789,
  "timestamp": "2025-02-22T15:30:00Z"
}

5. Sử dụng Service Mesh​

Mô tả:
Service Mesh là một kiến trúc cung cấp lớp giao tiếp (communication layer) cho các microservices thông qua các proxy sidecar. Ví dụ điển hình là Istio, Linkerd. Service Mesh quản lý các vấn đề như định tuyến, cân bằng tải, bảo mật và giám sát mà không cần thay đổi mã nguồn của từng service.

Ưu điểm:

  • Tách biệt logic giao tiếp ra khỏi business logic, giúp dễ bảo trì.
  • Cung cấp các tính năng như cân bằng tải, theo dõi, mã hoá, xác thực giữa các service.
  • Dễ dàng triển khai và quản lý trên các môi trường phân tán.

Nhược điểm:

  • Phức tạp trong việc cấu hình và triển khai ban đầu.
  • Tăng thêm overhead cho hệ thống do sự can thiệp của các proxy.

Ví dụ chi tiết:
Trong một hệ thống sử dụng Istio, mỗi service sẽ được triển khai kèm theo một sidecar proxy. Khi Order Service cần liên lạc với User Service, proxy của Order Service sẽ gửi yêu cầu thông qua Istio, đảm bảo tính bảo mật và cân bằng tải mà không cần thay đổi cấu trúc của mã nguồn.

Kết luận​

Mỗi phương pháp liên lạc giữa các services trong microservices đều có ưu nhược điểm riêng.

  • RESTful API và gRPC phù hợp cho giao tiếp đồng bộ, cung cấp tốc độ và dễ dàng triển khai.
  • Message Queue và mô hình Event-Driven phù hợp cho giao tiếp không đồng bộ, giúp hệ thống hoạt động linh hoạt, mở rộng tốt hơn.
  • Service Mesh lại giúp quản lý giao tiếp giữa các service một cách hiệu quả, tách riêng loạt các vấn đề về mạng và bảo mật.

Việc lựa chọn phương pháp nào phụ thuộc vào yêu cầu cụ thể của hệ thống, khả năng mở rộng, độ tin cậy và kinh nghiệm của đội ngũ phát triển. Tùy theo từng trường hợp, có thể kết hợp nhiều phương pháp để tạo ra một hệ thống microservices tối ưu, linh hoạt và mạnh mẽ.