서비스 디자인 패턴

1. API 게이트웨이 패턴 🚪
클라이언트와 마이크로서비스 사이에 중간 계층을 두어 요청을 적절한 서비스로 라우팅하고, 응답을 집계하는 패턴이야. Netflix의 Zuul, Amazon의 API Gateway 등이 대표적인 구현체야. 이 패턴은 클라이언트의 복잡성을 줄이고 인증, 로깅, 모니터링 같은 공통 기능을 중앙화할 수 있어!

API 게이트웨이의 간단한 예시 코드를 보자:

// Node.js와 Express를 사용한 간단한 API 게이트웨이 예시
const express = require('express');
const httpProxy = require('http-proxy');
const app = express();
const proxy = httpProxy.createProxyServer();

// 사용자 서비스로 라우팅
app.use('/users', (req, res) => {
  proxy.web(req, res, { target: 'http://user-service:8080' });
});

// 상품 서비스로 라우팅
app.use('/products', (req, res) => {
  proxy.web(req, res, { target: 'http://product-service:8081' });
});

// 주문 서비스로 라우팅
app.use('/orders', (req, res) => {
  proxy.web(req, res, { target: 'http://order-service:8082' });
});

app.listen(3000, () => {
  console.log('API Gateway running on port 3000');
});

2. 서비스 디스커버리 패턴 🔍
동적으로 변화하는 환경에서 서비스의 위치(IP 주소, 포트)를 자동으로 찾아주는 패턴이야. Netflix Eureka, Consul, etcd 등이 이 패턴을 구현한 도구들이야. 이 패턴은 클라우드 환경에서 서비스가 자주 생성되고 제거되는 상황에서 특히 유용해!

3. 서킷 브레이커 패턴 🔌
서비스 호출이 실패할 경우 연속적인 실패를 방지하기 위해 일시적으로 서비스 호출을 중단하는 패턴이야. Netflix의 Hystrix, Resilience4j 등이 이 패턴을 구현한 라이브러리야. 이 패턴은 장애 전파를 방지하고 시스템의 복원력을 높여줘!

Java와 Spring Boot에서 Resilience4j를 사용한 서킷 브레이커 예시:

@CircuitBreaker(name = "productService", fallbackMethod = "getProductFallback")
public Product getProduct(Long productId) {
    return restTemplate.getForObject(
        "http://product-service/products/" + productId,
        Product.class
    );
}

public Product getProductFallback(Long productId, Exception e) {
    return new Product(productId, "Fallback Product", "This is a fallback product", 0.0);
}

데이터 관리 패턴

4. 데이터베이스 per 서비스 패턴 💾
각 마이크로서비스가 자신만의 데이터베이스를 가지는 패턴이야. 이를 통해 서비스 간 결합도를 낮추고 각 서비스에 최적화된 데이터베이스 기술을 선택할 수 있어. 예를 들어, 사용자 서비스는 관계형 DB를, 로그 서비스는 NoSQL DB를 사용할 수 있지!

5. 이벤트 소싱 패턴 📝
상태 변경을 이벤트 시퀀스로 저장하고, 이 이벤트들을 재생하여 현재 상태를 구성하는 패턴이야. 이 패턴은 데이터 일관성 문제를 해결하고 시스템의 감사 기능을 강화해. Axon Framework, EventStore 등이 이 패턴을 지원하는 도구야!

6. CQRS(Command Query Responsibility Segregation) 패턴 ⚖️
데이터 수정(Command)과 조회(Query)를 분리하는 패턴이야. 이를 통해 각 작업에 최적화된 모델을 사용할 수 있어. 읽기 작업이 많은 서비스에서 성능을 크게 향상시킬 수 있지!

통신 패턴

7. 동기식 통신 (REST, gRPC) ↔️
서비스 간 직접적인 요청-응답 방식의 통신이야. REST API나 gRPC 같은 프로토콜을 사용해. 간단하고 직관적이지만, 서비스 간 결합도가 높아질 수 있어.

gRPC를 사용한 서비스 정의 예시:

// product.proto 파일
syntax = "proto3";

service ProductService {
  rpc GetProduct(ProductRequest) returns (ProductResponse);
  rpc CreateProduct(CreateProductRequest) returns (ProductResponse);
}

message ProductRequest {
  int64 product_id = 1;
}

message CreateProductRequest {
  string name = 1;
  string description = 2;
  double price = 3;
}

message ProductResponse {
  int64 product_id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
}

8. 비동기식 통신 (메시지 큐, 이벤트 버스) 📨
서비스가 메시지를 큐에 발행하고, 다른 서비스가 이를 구독하는 방식의 통신이야. RabbitMQ, Kafka, AWS SQS 등이 이런 메시징 시스템을 제공해. 이 패턴은 서비스 간 결합도를 낮추고 시스템의 확장성을 높여줘!

Spring Boot와 Kafka를 사용한 이벤트 발행 예시:

@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;
    
    public Order createOrder(Order order) {
        // 주문 생성 로직
        Order savedOrder = orderRepository.save(order);
        
        // 주문 생성 이벤트 발행
        OrderCreatedEvent event = new OrderCreatedEvent(
            savedOrder.getId(), 
            savedOrder.getUserId(),
            savedOrder.getItems()
        );
        kafkaTemplate.send("order-events", event);
        
        return savedOrder;
    }
}