Khi xây dựng các Microservices, tại sao việc thiết kế Service Discovery lại đóng vai trò cốt lõi trong môi trường tự động hóa như Kubernetes, và nó giải quyết bài toán gì?

Question

Accepted Answer

Bản chất vấn đề
Trong hệ thống Monolith, các module gọi nhau thông qua hàm nội bộ hoặc cấu hình một địa chỉ IP tĩnh. Trong Microservices, số lượng instance của mỗi service co giãn liên tục (scale up/down) dựa trên tải, dẫn đến việc địa chỉ IP và Port thay đổi liên tục. Hard-code IP trong source code là bất khả thi.
Cơ chế hoạt động
Service Discovery gồm hai thành phần chính:

Registry Server (hoặc cơ chế tích hợp sẵn của Kubernetes): Nơi các service tự đăng ký (Registration) khi khởi động và hủy đăng ký khi tắt.
Client-side Discovery hoặc Server-side Discovery: Khi một service muốn gọi service khác, nó sẽ tra cứu địa chỉ thông qua Service Discovery thay vì gọi trực tiếp IP tĩnh.

Ví dụ thực tế

Khi OrderService muốn gọi PaymentService:
Thay vì gọi http://192.168.1.50:8080/pay, OrderService sẽ gọi thông qua tên định danh dịch vụ nội bộ http://payment-service/pay.
Kubernetes DNS hoặc các công cụ như Consul sẽ tự động phân giải tên này thành IP thực tế của một instance đang hoạt động và thực hiện cân bằng tải (Load Balancing).

Lưu ý thực tế dành cho Junior

Luôn sử dụng tên dịch vụ (Service Name) nội bộ thay vì hard-code IP.
Hiểu rõ cơ chế Health Check tích hợp; nếu một instance bị lỗi, Service Discovery sẽ tự động loại bỏ nó khỏi danh sách định tuyến để tránh gửi request vào vùng đất chết.

Khi xây dựng các Microservices, tại sao việc thiết kế Service Discovery lại đóng vai trò cốt lõi trong môi trường tự động hóa như Kubernetes, và nó giải quyết bài toán gì?

Bản chất vấn đề

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi microservices liên quan cùng chủ đề