Spring Cloud ecosystem

Spring Cloud’ni o‘rganishdan maqsad - bitta Spring Boot app yozish emas, balki bir nechta servislar orasidagi konfiguratsiya, routing, load balancing, kommunikatsiya, tracing va config refresh kabi muammolarni boshqarishni bilishdir.

1. Spring Cloud nima?

Spring Cloud - distributed system, ya’ni microservice arxitekturalarida kerak bo‘ladigan umumiy muammolarni Spring uslubida hal qilish uchun yaratilgan ekotizim.

Oddiy Spring Boot application:

User → Spring Boot App → Database

Microservice ecosystem:

User
  ↓
API Gateway
  ↓
Order Service ─────→ Payment Service
  ↓                   ↓
Inventory Service     Notification Service
  ↓
Config Server / Service Discovery / Tracing / Message Bus

Bu yerda muammolar ko‘payadi:

Spring Cloud rasmiy sahifasida OpenFeign, Contract, Config, Gateway kabi ko‘plab distributed system loyihalari bitta ekotizim sifatida beriladi. (Home)

2. Spring Cloud Gateway

Nima uchun kerak?

Spring Cloud Gateway - bu microservice arxitekturasidagi kirish nuqtasi.

Frontend yoki mobile app har bir service’ni alohida chaqirmaydi. U faqat Gateway’ga request yuboradi.

Client → Gateway → user-service
                → order-service
                → payment-service

Gateway quyidagi ishlarni qiladi:

Spring Cloud Gateway’da rate limiting uchun RequestRateLimiter filter mavjud. Request ruxsat etilmasa, odatda HTTP 429 Too Many Requests qaytariladi. (Home)

Gateway routing misoli

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: http://localhost:8081
          predicates:
            - Path=/api/orders/**

Bu nimani anglatadi?

/api/orders/** → http://localhost:8081

Masalan:

GET /api/orders/15

Gateway buni quyidagiga yuboradi:

GET http://localhost:8081/api/orders/15

Gateway filter nima?

Filter - request yoki response ustida ishlaydigan middleware.

Client Request
   ↓
Gateway Filter
   ↓
Target Service
   ↓
Gateway Filter
   ↓
Client Response

Misol:

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:8082
          predicates:
            - Path=/api/users/**
          filters:
            - AddRequestHeader=X-Gateway, SpringCloudGateway

Bu har bir request’ga yangi header qo‘shadi:

X-Gateway: SpringCloudGateway

3. Spring Cloud Config Server

Muammo

Agar 10 ta microservice bo‘lsa, har birida alohida config bo‘ladi:

user-service/application.yml
order-service/application.yml
payment-service/application.yml
inventory-service/application.yml
...

Bu yomon tomoni:

• Config tarqalib ketadi.

• Production secret’lar noto‘g‘ri joyda saqlanishi mumkin.

• Config o‘zgarsa, har bir service’ni alohida deploy qilish kerak bo‘ladi.

• Environment farqlari ko‘payadi: dev, stage, prod.

Yechim

Spring Cloud Config Server - barcha service config’larini markaziy joydan beradi.

user-service      ┐
order-service     ├──→ Config Server → Git Repository
payment-service   ┘

Spring Cloud Config rasmiy hujjatlarida Config Server distributed system uchun externalized configuration’ni server va client tomondan qo‘llab-quvvatlashi aytiladi. (Cloud Spring)

Config Server qanday ishlaydi?

Config Server odatda Git repository’dan config o‘qiydi.

config-repo/
  user-service.yml
  order-service.yml
  payment-service.yml
  application.yml

Service startup paytida config’ni Config Server’dan oladi.

Spring Cloud Config Client’da Spring Boot 2.4'dan boshlab Config Server’ga ulanishning asosiy usuli spring.config.import orqali bajariladi. (Home)

Misol:

spring:
  application:
    name: order-service

  config:
    import: optional:configserver:http://localhost:8888

Bu service quyidagi config’ni qidiradi:

order-service.yml

Config Server yaratish

Dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

Main class:

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

Config:

server:
  port: 8888

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/company/config-repo

Spring Cloud Config Server @EnableConfigServer orqali oddiy Spring Boot application ichiga joylashtirilishi mumkin. (Home)

4. Spring Cloud LoadBalancer

Muammo

Bitta service’dan bir nechta instance bo‘lishi mumkin:

order-service-1 → localhost:8081
order-service-2 → localhost:8082
order-service-3 → localhost:8083

Payment service order-service’ni chaqirishi kerak. Lekin qaysi instance’ga?

payment-service → ? → order-service instances

Yechim

Spring Cloud LoadBalancer request’larni instance’lar orasida taqsimlaydi.

payment-service
   ↓
LoadBalancer
   ├── order-service-1
   ├── order-service-2
   └── order-service-3

Oddiy round-robin:

1-request → order-service-1
2-request → order-service-2
3-request → order-service-3
4-request → order-service-1

LoadBalancer qayerda ishlaydi?

Ko‘pincha u quyidagilar bilan birga ishlaydi:

• OpenFeign

• WebClient

• RestClient

• Gateway

• Service Discovery: Eureka, Consul, Kubernetes service discovery

Senior darajada muhim savol:

"Men service URL’ni hardcode qilayapmanmi yoki service name orqali chaqiryapmanmi?"

Yomon:

http://localhost:8081/api/orders

Yaxshi:

http://order-service/api/orders

5. Spring Cloud OpenFeign

Nima uchun kerak?

Microservice ichida boshqa REST service’ni chaqirish ko‘p uchraydi.

Masalan:

order-service → payment-service

Oddiy WebClient yoki RestTemplate bilan har safar URL, request, response mapping yoziladi. OpenFeign esa declarative client beradi.

Spring Cloud OpenFeign rasmiy sahifasida u Spring Boot ilovalari uchun OpenFeign integratsiyasi, autoconfiguration va Spring Environment bilan binding berishi aytiladi. (Home)

OpenFeign misoli

Dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

Main class:

@SpringBootApplication
@EnableFeignClients
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

Feign client:

@FeignClient(name = "payment-service", path = "/api/payments")
public interface PaymentClient {

    @PostMapping
    PaymentResponse createPayment(@RequestBody PaymentRequest request);
}

Service’da ishlatish:

@Service
@RequiredArgsConstructor
public class OrderService {

    private final PaymentClient paymentClient;

    public OrderResponse createOrder(CreateOrderRequest request) {
        PaymentResponse payment = paymentClient.createPayment(
                new PaymentRequest(request.amount())
        );

        return new OrderResponse("Order created", payment.status());
    }
}

Bu yerda payment-service oddiy string emas. Bu service nomi. LoadBalancer yoki service discovery bilan birga ishlaganda real instance tanlanadi.

OpenFeign qachon yaxshi?

6. Spring Cloud Bus

Muammo

Config Server bor. Lekin config o‘zgarganda service’lar qanday biladi?

Masalan, Git’dagi config o‘zgardi:

feature:
  payment-v2-enabled: true

Lekin order-service, payment-service, user-service eski config bilan ishlab turibdi.

Yechim

Spring Cloud Bus config o‘zgarishini message broker orqali service’larga tarqatadi.

Git Config Changed
      ↓
Config Server
      ↓
Spring Cloud Bus
      ↓
RabbitMQ / Kafka
      ↓
All services refresh config

Spring Cloud Config Client imkoniyatlari ichida @RefreshScope va management endpoint’lar orqali environment/config qayta yuklash imkoniyati mavjud. (GitHub)

@RefreshScope nima?

@RefreshScope
@Component
@ConfigurationProperties(prefix = "feature")
public class FeatureProperties {
    private boolean paymentV2Enabled;

    public boolean isPaymentV2Enabled() {
        return paymentV2Enabled;
    }

    public void setPaymentV2Enabled(boolean paymentV2Enabled) {
        this.paymentV2Enabled = paymentV2Enabled;
    }
}

Config refresh bo‘lganda bu bean qayta yaratiladi.

7. Sleuth → Micrometer Tracing migration

Muhim holat

Oldin distributed tracing uchun ko‘p Spring loyihalarda Spring Cloud Sleuth ishlatilgan.

Hozirgi zamonaviy Spring Boot/Spring Cloud ekotizimida tracing odatda:

Micrometer Tracing + Brave/OpenTelemetry + Zipkin/Tempo/Jaeger

orqali qilinadi.

Spring Cloud 2025.0 release train’da ham Micrometer/Tracing bilan bog‘liq komponentlar va Spring Cloud ekotizimidagi yangilanishlar davom etayotganini ko‘rish mumkin. (GitHub)

Distributed tracing nimani hal qiladi?

Microservice arxitekturada bitta request bir nechta service’dan o‘tadi:

Client
  ↓ traceId=abc123
Gateway
  ↓ traceId=abc123
Order Service
  ↓ traceId=abc123
Payment Service
  ↓ traceId=abc123
Notification Service

Agar xatolik bo‘lsa:

Payment Service timeout

Tracing orqali ko‘rasiz:

Gateway → Order Service → Payment Service
                          ↑
                       timeout here

Loglarda traceId

Yaxshi production log:

2026-05-21 10:30:15 INFO [order-service,traceId=abc123,spanId=def456] Creating order
2026-05-21 10:30:16 ERROR [payment-service,traceId=abc123,spanId=xyz999] Payment timeout

Bu Senior darajadagi debugging uchun juda muhim.

8. Spring Cloud ecosystem umumiy arxitekturasi

Senior developer quyidagi flow’ni tushunishi kerak:

                 ┌────────────────────┐
                 │      Client        │
                 └─────────┬──────────┘
                           ↓
                 ┌────────────────────┐
                 │ Spring Cloud       │
                 │ Gateway            │
                 └─────────┬──────────┘
                           ↓
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
 ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
 │ user-service   │ │ order-service  │ │ payment-service│
 └───────┬────────┘ └───────┬────────┘ └───────┬────────┘
         ↓                  ↓                  ↓
 ┌──────────────────────────────────────────────────────┐
 │ Config Server / LoadBalancer / OpenFeign / Tracing   │
 └──────────────────────────────────────────────────────┘
                           ↓
                 ┌────────────────────┐
                 │ Kafka / RabbitMQ   │
                 │ Spring Cloud Bus   │
                 └────────────────────┘

9. Minimal Senior-level project structure

spring-cloud-demo/
  config-server/
  api-gateway/
  user-service/
  order-service/
  payment-service/
  config-repo/
    user-service.yml
    order-service.yml
    payment-service.yml
    api-gateway.yml

Har bir modul vazifasi

10. Senior developer bilishi kerak bo‘lgan savollar

Design savollar

1. Gateway’da authentication qilamizmi yoki har bir service’dami?

2. Gateway failure bo‘lsa butun system to‘xtaydimi?

3. Config Server unavailable bo‘lsa service start bo‘ladimi?

4. Feign client’da timeout qancha?

5. Retry qayerda bo‘ladi: Gateway’dami, client’dami yoki message broker’dami?

6. Rate limit user bo‘yichami, IP bo‘yichami yoki API key bo‘yichami?

7. TraceId loglarda ham, response header’da ham bormi?

8. Config refresh production’da xavfsizmi?

9. Service discovery kerakmi yoki Kubernetes service DNS yetarlimi?

10. OpenFeign synchronous coupling kuchaytirib yubormaydimi?

11. Amaliy checklist

Spring Cloud ecosystem’ni o‘rganyotganda quyidagilarni albatta qilib ko‘rish kerak:

[ ] Config Server yaratish
[ ] 2 ta service’ni Config Server’dan config oladigan qilish
[ ] Gateway orqali route qilish
[ ] OpenFeign orqali service-to-service call qilish
[ ] LoadBalancer bilan bir service’ning 2 instance’iga request yuborish
[ ] Gateway filter yozish
[ ] Rate limiting qo‘shish
[ ] Config refresh mexanizmini sinash
[ ] Micrometer Tracing bilan traceId logga chiqarish
[ ] Zipkin yoki Grafana Tempo’da trace ko‘rish

12. Qisqa xulosa

Spring Cloud ecosystem Spring developer uchun microservice’larning "infrastructure glue" qismidir.

Eng asosiy fikr:

Spring Boot → bitta service qurish uchun
Spring Cloud → ko‘p service’li ecosystem boshqarish uchun

Bu mavzuda eng muhim komponentlar: