Khi sử dụng giao tiếp không đồng bộ trong hệ thống microservice, phổ biến nhất đó là chúng ta sẽ sử dụng một message broker. Message broker đảm bảo giao tiếp giữa các microservice một cách đáng tin cậy và ổn định, các message được quản lý và theo dõi trong hệ thống. Có một vài message broker chúng ta có thể lựa chọn, điểm khác biệt giữa các loại message broker này là về quy mô và khả năng dữ liệu truyền tải. Bài viết này mình sẽ so sánh ba loại message broker phổ biến nhất đó là: Rabbitmq, Kafka và Redis.
Giao tiếp trong hệ thống Microservices: đồng bộ và không đồng bộ
Có hai cách phổ biến mà các microservice giao tiếp với nhau đó là giao tiếp đồng bộ và không đồng bộ. Trong giao tiếp đồng bộ, người gọi chờ phản hồi trước khi gửi tin nhắn tiếp theo và nó hoạt động như một giao thức REST trên HTTP request.
Ngược lại, đối với giao tiếp không đồng bộ, các tin nhắn được gửi mà không cần chờ phản hồi. Điều này phù hợp với các hệ thống phân tán và thường yêu cầu một message broker để quản lý các tin nhắn. Việc lựa chọn loại giao tiếp nào thì chúng ta nên xem xét các tham số khác nhau, chẳng hạn như cách chúng ta cấu trúc microservice của mình như thế nào, chúng ta có cơ sở hạ tầng như thế nào nào, độ trễ, quy mô, phụ thuộc và mục đích của giao tiếp. Giao tiếp không đồng bộ có thể thiết lập phức tạp hơn nhưng những ưu điểm của việc sử dụng giao tiếp không đồng bộ trong hệ thống microservice vượt trội hơn những nhược điểm.
Ưu điểm của giao tiếp không đồng bộ
Không đồng bộ ở đây có nghĩa là request sẽ không bị chặn (non blocking). Trong trường hợp các microservice gặp sự cố ,cơ chế giao tiếp không đồng bộ cung cấp các kỹ thuật phục hồi khác nhau và thường tốt hơn trong việc xử lý các lỗi liên quan đến sự cố. Ngoài ra, khi sử dụng các message broker thay vì giao thức REST, các service giao tiếp với nhau mà không thực sự cần phải biết nhau, các microservice trở nên độc lập và sự liên kết giữa các microservice trở nên mềm dẻo và linh hoạt hơn. Điều này sẽ cung cấp cho chúng ta khả năng mở rộng tốt hơn và khi cần phát triển lại mã nguồn của một service sẽ gần như không ảnh hưởng đến service khác.
Lựa chọn Message Broker
Giao tiếp không đồng bộ thường được quản lý thông qua một message broker. Khi chọn một message broker để thực hiện xử lý giao tiếp không đồng bộ, chúng ta nên xem xét các khía cạnh như:
- Khả năng mở rông: hay số lượng tin nhắn được xử lý trên mỗi giây.
- Độ bền của dữ liệu (Data Persistancy): khả năng khôi phục tin nhắn.
- Khả năng của bên tiêu thụ tin nhắn: Tức là message broker có khả năng quản lý consumer theo cơ chế một-một (one-to-one) hay một-nhiều (one-to-many) hay không.
one-to-one
one-to-many
So sánh giữa các loại message broker
1. RabbitMQ (AMQP)
- Scale: Dựa trên cấu hình và tài nguyên, khả năng xử lý khoảng 50k message/second.
- Persistance: hỗ trợ cả lưu tin nhắn lâu dài (persistent message) và nhất thời (transient message).
- One-to-one và one-to-many: hỗ trợ cả hai.
RabbitMQ đã được phát hành vào năm 2007 và là một trong những message broker phổ biến đầu tiên được tạo ra. Cung cấp phương thức giao tiếp point-to-point và Pub/Sub bằng cách triển khai giao thức Advanced Message Queuing Protocol (AMQP). RabbitMQ hỗ trợ tất cả các ngôn ngữ phổ biến, bao gồm Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift,....
2. Kafka
- Scale: Có thể xử lý lên đến 1millions message/second.
- Persistance: Có.
- One-to-one và one-to-many: Chỉ hỗ trợ one-to-many. Kafka được tạo bởi LinkedIn vào năm 2011 để xử lý thông lượng cao và độ trễ thấp. Là một nền tảng phát trực tuyến phân tán. Nó cung cấp cơ chế persistent data. Kafka đã cung cấp như một SaaS trên Azure, AWS và Confluent. Nó hỗ trợ tất cả các ngôn ngữ chính, bao gồm Python, Java, C / C ++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift...
3. Redis
- Scale: Có thể xử lý lên đến 1millions message/second.
- Persistance: Về cơ bản, không, nó là một kho dữ liệu trong bộ nhớ (in-memory database).
- One-to-one và one-to-many: hỗ trợ cả hai.
Core của Redis là một in-memory database, được sử dụng như key-value store với hiệu năng cao hoặc là như một message broker. Nó rất thích hợp với xử lý dữ liệu thời gian thực. Từ phiên bản Redis 5.0 đã thêm tính năng gửi nhận tin nhắn theo cơ chế Pub-Sub, vì vậy Redis cũng là một trong số các lựa chọn khi cần dùng một message broker.
Các use case với message broker
Một số đặc điểm của Rabbitmq, Kafka và Redis dẫn tới chúng phù hợp với các use case khác nhau. Dưới đây là khuyến nghị đối với từng message broker để sử dụng phù hợp theo các trường hợp sử dụng khác nhau.
Lưu tin nhắn ngắn hạn thì dùng Redis
Cơ sở dữ liệu trong bộ nhớ của Redis phù hợp với các trường hợp sử dụng các thông điệp ngắn hạn mà việc peristent data không quan trọng, chúng ta có thể chấp nhận được trong trường hợp mất mát dữ liệu.
Xử lý dữ liệu lớn, cần persistent data thì dùng Kafka
Kafka là một distributed queue phù hợp với những trường hợp cần thông lượng cao và cần lưu trữ một lượng lớn dữ liệu trong thời gian dài. (phù hợp với trường hợp cần mô hình pub/sub dạng one-to-may và persistent data)
Định tuyến phức tạp thì dùng RabbitMQ
Phù hợp với những trường hợp cần hỗ trợ định tuyến phức tạp với khả năng khoảng vài chục nghìn message/second).
Tổng kết
Bài viết là cái nhìn chủ quan của tác giả, sẽ có những software engineer dày dặn kinh nghiệm và hiểu biết hơn. Điều quan trọng tác giải muốn nhắn nhủ là mỗi công nghệ đều có ưu và nhược điểm của riêng nó vì vậy chúng ta cần hiểu chúng và chọn đúng công nghệ sao cho phù hợp với tình huống và yêu cầu cụ thể.