Tìm hiểu về Microservices - Phần 2: Giao tiếp giữ các services

Phần trước mình đã có bài viết tổng quát về Microservices. Trong bài viết này, chings ta se đi đến một bài toán cụ thể hơn, đó là vấn đề Communication trong microservices.

Một trong những khó khăn lớn nhất khi chuyển đổi hệ thống từ monolithic qua microservice là sự thay đổi cách thức giao tiếp.

Phụ thuộc vào tnhs chất service, người ta thường dùng 3 communication styles chính:

  • Remote Procedure Invocation

  • Mesaging

  • Domain-specific protocol

1. Remote Procedure Invocation (RPI)

Sử dụng RPI để liên lạc giữa các service, client sử dụng một request/reply-based protocol để tạo các request đến service.

Service Order và Payment exposed các API để client hoặc các service kkhacs gọi đến nó. khi client call REST API request để thực hiện một Order. Order dervice nhận request xử lý business logic rồi gọi tới maymeny services qua API để thực hiện payment. Mô hình trên là loại mô hình kết nối Point to Point, các service kết nối trực tiếp với nhau thông qua API end-point.

Một vài pattern cho RPI:

Việc sử dụng RPI rất phổ biến vì chúng có những lợi ích:

Tuy nhiên chúng cũng có vài nhược điểm:

2. Messaging

Sử dụng asynchronous mesaging để giao tiếp giữa các services. Các services trao đổi mesage qua các kênh mesage.

Trong mô hình này, các microservice không giao tiếp trực tiếp với nhau mà thông qua kệ thống mesage quêu, giao tiếp bất đồng bộ.

  • Order Microservice publish một message đến Message queue theo một topic nào đó.

  • Payment Microservice và các Microservice sẽ subscribe các message theo một topic cụ thể. Ví dụ Payment Microservice subscribe message topic “ABC” thì chỉ khi Order Microservice gửi message ABC thì nó mới nhận.

Cơ chế này tương tự như cách bạn gửi thử từ A đến B. A sẽ không đem thư đến tận nơi cho B mà gửi qua bưu điện, ghi rõ địa chỉ người nhận. Bưu điện đóng vài như một Mesage broker để phat thư đến người nhận theo địa chỉ đã cho.

Cụ thể chúng ta có một vài patterns về asynchronous mesaging:

  • Apache Kafka

  • RabbitMQ

Sử dụng mesaging patterns có ưu điểm sau:

  • Hỡ trợ nhiều kiểu giao tiếp như request/ reply, notifications, request/async response , publish/subscribe, publish/ async respone.

  • Vì chúng là asynchronous nên tách biệt người gửi và người nhận, và mesage broker sẽ luue tin nhắn đến khi người nhận có thể xử lý.

Nhược điểm:

  • Hệ thống trở nên phức tạp hơn vì cần mesage broker.

3. Domain-specific protocol

Trong một vài trường hợp đặng biệt không thể sử dụng RPI hay mesaging mà thay vào đó cần dùng domain-specific protocol cho việc giao tiếp giữa các services.

  • Email protocols như: SMTP, IMAP

  • Media streaming protocols như: RTMP, HLS và HDS.