Communication Implementation — REST, gRPC & Message Brokers (BMS) | Blog

Phần trước của cuốn "Building Microservices" bàn về kiểu giao tiếp (communication styles) — đồng bộ hay bất đồng bộ. Chương 5 này đi sâu vào mặt triển khai cụ thể: với ý tưởng đó trên giấy, thì thực tế nên dùng công nghệ nào để nối các service lại với nhau? Đây là phần cực kỳ thiết thực với backend engineer, vì sai một lựa chọn công nghệ là phải trả giá bằng cả hệ thống lang thang, khó bảo trì.

Bài viết này tóm tắt quan điểm của Sam Newman về việc chọn và vận hành công nghệ giao tiếp giữa microservices — từ tiêu chí để đánh giá công nghệ, đến REST, gRPC và message broker, rồi vấn đề versioning/schema evolution vốn là "sinh tử" với bất kỳ hệ phân tán nào.

Tiêu chí chọn công nghệ giao tiếp

Ảnh: panumas nikhomkhai — Pexels

Trước khi chọn REST hay gRPC hay message queue, Sam Newman đưa ra một bộ tiêu chí dùng để "thử lửa" mọi công nghệ. Trước tiên là khả năng tương thích ngược — consumer cũ phải tiếp tục hoạt động khi producer đổi, đây là nền tảng của việc triển khai độc lập. Kế đến là giao diện tường minh: càng nhiều ý nghĩa được thể hiện rõ qua schema (như OpenAPI) thì càng giảm hiểu lầm giữa các team.

Một tiêu chí quan trọng khác là công nghệ phải trung lập — không ép chặt service vào một ngôn ngữ hay framework cụ thể. Bạn từng gặp một team muốn viết Go nhưng bị một API văn bản gắn chặt vào Java không? Chính là chuyện này. Cuối cùng, giao diện nên đơn giản với người dùng và che giấu chi tiết nội bộ — service phải giấu cách nó được implement để người dùng không phụ thuộc vào bên trong.

REST và gRPC — hai lựa chọn đồng bộ

Ảnh: Markus Spiske — Pexels

Trong thế giới giao tiếp đồng bộ, REST vẫn là lựa chọn mặc định hợp lý ở hầu hết các tình huống. Lý do nằm ở độ phổ biến: công cụ, thư viện và kiến thức về REST đều rất rộng, dễ dùng cho cả API nội bộ lẫn public, và tận dụng được HTTP caching. Ngược lại, gRPC dùng HTTP/2 với binary protocol, hiệu quả hơn về hiệu năng và có hợp đồng rõ ràng nhờ Protocol Buffers — rất phù hợp khi bạn kiểm soát được phía client lẫn server và cần truyền tải nhị phân tốc độ cao.

Tuy nhiên, cả REST lẫn gRPC đều chia sẻ một điểm yếu chung của giao tiếp đồng bộ: chuỗi call dài. Khi service A gọi B, B gọi C, rồi C gọi D — độ trễ cộng dồn và rủi ro lỗi tăng lên theo từng mắt xích. Đó là lý do Sam Newman khuyến nghị cần cân nhắc nghiêm túc kiểu giao tiếp bất đồng bộ để tránh "tay đua nối đuôi" (chain of blocking calls) nuốt chửng thời gian phản hồi.

Message broker và giao tiếp bất đồng bộ

Ảnh: Abdelrahman Ahmed — Pexels

Khi chọn message broker (như Kafka, RabbitMQ), câu hỏi đầu tiên là "middleware có nên thông minh đến mức nào?". Trường phái điển hình trong hệ sinh thái microservice — đặc biệt với Kafka — là giữ middleware "ngu" và để trí tuệ nằm ở các endpoint. Broker chỉ cần nhận tin, lưu và chuyển tin đáng tin cậy; còn việc xử lý, routing, chuyển đổi dữ liệu nên do consumer quyết định. Điều này giữ cho broker đơn giản, bền và dễ mở rộng.

Khi publish một sự kiện, hãy nhớ châm ngôn của chương: cho vào event những gì bạn sẵn lòng chia sẻ qua API. Producer phải nghĩ đến tương lai — ai có thể là consumer mới của event này? Schema của event chính là một dạng hợp đồng, cần được nuôi dưỡng như hợp đồng API. Chương này cũng cảnh báo về schema evolution: vấn đề phân phối thay đổi schema giữa producer và consumer, và vì một event có thể sống đời - sống dai hơn cả service tạo ra nó, nên cần chiến lược versioning và tương thích ngược rõ ràng để không làm vỡ các consumer đang chạy.

Key Takeaways

Đánh giá công nghệ qua tiêu chí, không qua trend: tương thích ngược, giao diện tường minh, trung lập công nghệ, đơn giản cho consumer và che giấu chi tiết nội bộ.
REST là mặc định hợp lý cho hầu hết trường hợp; gRPC thắng về hiệu năng và hợp đồng chặt chẽ khi kiểm soát được hai đầu.
Giao tiếp đồng bộ dễ dẫn đến chuỗi call dài — cân nhắc bất đồng bộ để giảm độ trễ và tăng độ bền của hệ thống.
Giữ broker "ngu", đưa xử lý về endpoints — trí tuệ nằm ở biên, không nằm ở middleware.
Schema evolution là sống còn: event có thể sống lâu hơn service tạo ra nó, nên cần versioning và tương thích ngược ngay từ đầu.

Glossary

Thuật ngữ	Ý nghĩa
gRPC	Framework RPC của Google dùng HTTP/2 + Protocol Buffers, hiệu năng cao, hợp đồng rõ ràng.
OpenAPI	Tiêu chuẩn mô tả schema API, giúp giao diện tường minh và sinh mã tự động.
Message broker	Middleware trung gian (Kafka, RabbitMQ) vận chuyển message giữa các service bất đồng bộ.
Schema evolution	Quá trình thay đổi schema theo thời gian mà vẫn giữ tương thích cho consumer hiện tại.
Backward compatibility	Khả năng consumer cũ vẫn hoạt động khi producer thay đổi — nền tảng của deploy độc lập.

Kết

Chương 5 "Implementing Microservice Communication" là cầu nối giữa ý tưởng và thực thi: đã biết cần giao tiếp thế nào thì giờ biết dùng gì để giao tiếp. Tinh thần xuyên suốt là không có công nghệ "thần thánh" — mà là chọn đúng theo tiêu chí rõ ràng và giữ gìn hợp đồng (schema, API) cẩn thận như của cải quý nhất. Nếu chưa xem lại các phần về kiểu giao tiếp và workflow, đây là thời điểm tốt để nối lại mạch kiến thức trước khi sang những chương triển khai, giám sát và vận hành phía sau.