System DesignVấn đề: instance của service lên xuống liên tục (autoscale, deploy, container chết và được tạo lại) nên IP/port không cố định. Không thể hardcode địa chỉ trong config.
Cơ chế chung: mọi instance đăng ký vào một service registry khi khởi động và gửi heartbeat; registry loại bỏ instance chết. Bên gọi tra registry để biết địa chỉ khả dụng.
- Client-side discovery: client hỏi registry, tự chọn instance và tự cân bằng tải. Ít một chặng mạng, nhưng logic discovery nằm trong mọi client (thư viện riêng cho mỗi ngôn ngữ). Điển hình: Eureka + Ribbon.
- Server-side discovery: client chỉ gọi một địa chỉ ổn định (load balancer / router); thành phần đó tra registry và chuyển tiếp. Client đơn giản, độc lập ngôn ngữ; đổi lại thêm một chặng và bản thân router phải sẵn sàng cao.
Trên Kubernetes: phần lớn trường hợp không cần Eureka/Consul riêng. K8s đã có sẵn server-side discovery: Service cho một tên DNS ổn định và một virtual IP, kube-proxy phân phối tới các Pod đang Ready; readiness probe đóng vai trò heartbeat. Gọi http://order-service là đủ.
Khi nào vẫn cần thêm: hệ thống lai (một phần còn chạy VM ngoài cluster), nhiều cluster/nhiều datacenter cần một registry chung, hoặc cần cân bằng tải tinh vi hơn mức round-robin của kube-proxy — lúc đó thường dùng service mesh thay vì tự dựng registry.