คุณสร้าง microservices ด้วย Spring Boot อย่างไร: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot ร่วมกับ Spring Cloud มอบชิ้นส่วนพื้นฐานสำหรับ microservices ปัญหาสามอย่างที่ระบบแบบกระจาย (distributed system) ทุกระบบต้องแก้คือ **การตั้งค่าแบบรวมศูนย์ (centralized configuration)**, **service discovery** และ **resilience** ต่อความล้มเหลวบางส่วน ## ชิ้นส่วนที่ทำงานร่วมกัน ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** เสิร์ฟ properties ของแต่ละบริการจาก git repo กลาง คุณจึงเปลี่ยน config ได้โดยไม่ต้อง deploy ใหม่ บริการต่าง ๆ ดึงค่าตอนเริ่มระบบ (และรีเฟรชผ่าน `/actuator/refresh`) - **Service discovery** (Eureka, Consul หรือ Kubernetes DNS) ให้ Service A ค้นหา Service B ด้วย *ชื่อ* แทน host ที่ฝังตายตัว อินสแตนซ์จึงขยายขนาดและย้ายที่ได้อย่างอิสระ - **API Gateway** (Spring Cloud Gateway) คือจุดเข้าเดียวสำหรับการ routing, auth และ rate limiting ## Resilience — ส่วนที่ junior มักข้าม ในระบบแบบกระจาย ทุกการเรียกผ่านเครือข่าย *จะ* ล้มเหลวในสักวันหนึ่งอย่างแน่นอน ใช้ Resilience4j เพื่อหยุดไม่ให้บริการที่ช้าตัวหนึ่งลุกลามกลายเป็นการล่ม (outage): ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry transient blips @TimeLimiter(name = "inventory") // cap the wait public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Called when the circuit is open or the call fails — degrade gracefully. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` **circuit breaker** จะสะดุดเปิด (trip open) หลังจากล้มเหลวซ้ำ ๆ การเรียกจึงล้มเหลวทันที (fail fast) แทนที่จะสะสม thread รอ dependency ที่ตายไปแล้ว ## ทำไมจึงสำคัญ การสัมภาษณ์ระดับ senior ตรวจสอบวุฒิภาวะด้าน distributed system การเอ่ยถึง discovery และ config เป็นแค่ขั้นพื้นฐาน สิ่งที่สร้างความแตกต่างคือการพูดถึง **ความล้มเหลว**: circuit breaker, timeout, idempotency และ observability (distributed tracing ด้วย Micrometer/Zipkin) ผู้สมัครที่แข็งแกร่งยังโต้แย้งกลับด้วย — โดยชี้ว่า microservices เพิ่มต้นทุนด้านปฏิบัติการ และ monolith มักเป็นทางเลือกที่ถูกต้องจนกว่าการขยายขนาดจะเรียกร้องเป็นอย่างอื่น

ชิ้นส่วนที่ทำงานร่วมกัน

Resilience — ส่วนที่ junior มักข้าม

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง