როგორ აშენებ მიკროსერვისებს Spring Boot-ით: config, discovery, resilience?

Question

IT Interview Practice · Accepted Answer

Spring Boot პლუს Spring Cloud გაძლევს მიკროსერვისების სამშენებლო ბლოკებს. სამი პრობლემა, რომელიც ყოველმა განაწილებულმა სისტემამ უნდა გადაწყვიტოს, არის **ცენტრალიზებული კონფიგურაცია**, **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-დან აწვდის, ისე რომ კონფიგს redeploy-ის გარეშე ცვლი. სერვისები მას გაშვებისას იტვირთავენ (და `/actuator/refresh`-ით ანახლებენ). - **service discovery** (Eureka, Consul ან Kubernetes DNS) Service A-ს Service B-ის *სახელით* პოვნის საშუალებას აძლევს ჩაკოდილი ჰოსტის ნაცვლად, ისე რომ ინსტანციები თავისუფლად სკალირდება და მოძრაობს. - **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** განმეორებითი ჩავარდნების შემდეგ იღება, ისე რომ გამოძახებები სწრაფად ჩავარდება იმის ნაცვლად, რომ thread-ები მკვდარ dependency-ს დაელოდონ. ## რატომ არის ეს მნიშვნელოვანი senior ინტერვიუები განაწილებული სისტემების სიმწიფეს ამოწმებენ. discovery-სა და config-ის დასახელება საბაზისოა; განმასხვავებელი კი **ჩავარდნაზე** საუბარია: circuit breaker-ები, timeout-ები, idempotency და observability (განაწილებული tracing Micrometer/Zipkin-ით). ძლიერი კანდიდატები ასევე უკან იხევენ — აღნიშნავენ, რომ მიკროსერვისები საოპერაციო ხარჯს ამატებენ და მონოლითი ხშირად სწორი არჩევანია, სანამ მასშტაბი სხვას არ მოითხოვს.

მოძრავი ნაწილები

Resilience — ნაწილი, რომელსაც junior-ები ტოვებენ

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები