'web/마이크로서비스'에 해당되는 글 11건

web/마이크로서비스

Spring reactor Mono와 Flux 정리

지금까지 Spring5에서 추가되었던 리액트 프로그램을 사용하여 간단한 프로그램을 만들어 봤지만 정확하게 Mono와 Flux에 차이와 정의를 정리하지 못한 것 같다. 이번기회에 두 개의 정확한 차이와 사용방법등을 정리해보자.


리액티브 프로그래밍
비동기 블록킹 프로세스로 동작하는 애플리케이션을 논블록킹 프로세스로 동작하기 위해서 지원하는 프로그래밍. (현재 node.js의 동작방식과 유사)


기존 Spring 블록킹 방식
웹에서 서버에 요청이 왔을때 서버는 요청에 대한 적절한 응답을 보내야 하는데 만약 작업이 오래 걸릴 경우에는 요청에 대한 응답이 모두 종료될 때까지 블록킹된다. Spring에서는 그래서 동시 요청 처리를 위해서 멀티 thread를 지원한다. 그러면 하나의 작업이 thread에서 진행되고 다른 thread가 다른 요청을 할당받아서 처리한다. 하지만 이렇게 결국 thread가 늘어나게 되는 경우에는 thread 할당에 필요한 리소스가 늘어나게 되어 비 효율적이 될 수도 있다.


Spring5의 Non blocking
Spring 5가 도입 되면서 클라이언트에 요청에 별도의 thread를 생성하지 않고 buffer를 사용해서 요청을 받고 뒤에서 처리하는 처리하는 thread는 여러개를 두어서 처리한다. 결국 node.js의 싱글스레드 논블로킹을 따라가는 것 같다.

그럼 왜 블로킹 방식을 지원하던 스프링에서 왜 논블로킹 방식을 생각하게 된걸까? 만약에 수천개의 스트림 데이터가 초당 계속 업데이트 되는 시스템이고 적절하게 응답을 해줘야할 때 기존의 블로킹 방식에 경우 상당한 부담을 받게 된다. 그래서 이런 부담을 효율적으로 처리하기 위해서 도입되었다.


Mono와 Flux
Mono는 0-1개의 결과만을 처리하기 위한 Reactor 객체
Flux는 0-N개의 결과물을 처리하기 위한 Reactor 객체

보통 여러 스트림을 하나의 결과를 모아줄 때 Mono를 쓰고 각각의 Mono를 합쳐서 하나의 여러 개의 값을 여러개의 값을 처리할 떄 Flux를 사용한다.

근데 이 부분에서 의문이 있다. 왜 그럼 Flux를 사용하면 되는거지 한개까지만 데이터를 처리할 수 있는 Mono라는 타입이 있는걸까? Mono와 Flux는 같은 Publisher 인터페이스를 구현해서 만들어졌다. 하지만 어떤 시스템에서는 Multi Result가 아닌 하나의 결과셋만 있는 경우가 있다. 그럴경우에는 Mono를 사용한다. 예를 들어 우리가 보통 자바에서 하나의 결과 또는 결과가 없는경우에 List를 사용해서 결과를 받지 않는다. 그와 동일한 개념이라고 생각하면 좋다.

그럼 Mono와 Flux를 사용해서 리액티브 프로그래밍을 하는 방식을정리해보자.

리액티브 스트림

  • 비동기 스트림 처리를 위한 표준으로써 next는 다음신호를 담고 complete는 신호가 끝난것 그리고 error은 신호보내는 도중 에러가 발생한 것을 의미한다.
  • Publisher가 전송하면 데이터는 sequence 대로 전송한다. 그러면 Subscriber가 데이터를 수신한다.
  • next, complete, error 신호를 발생시킨다.


기본적인 설명

1
2
3
4
5
6
// Integer 값을 발생하는 Flux 생성
Flux<Integer> seq = Flux.just(4, 5, 6); 
 
// 구독
seq.subscribe(System.out::println); 
 
cs


Flux.just(1, 2, 3);
--1-2-3-|→ 이처럼 1, 2, 3 세개의 next신호를 발생하고 마지막에 complete 신호를 발생시켜 시퀀스를 끝낸다.

Flux.just();
아무런 sequence가 없는 경우에는 complete 신호만 발생시킨다.

Mono.just(1);
--1-|→ Mono와 Flux의 차이는 Mono는 최대 발생할 수 있는 값이 1개이다.


구독과 신호 발생
sequence는 바로 신호를 발생하지 않는다. 구독을 하는 시점에 신호를 발생하기 시작한다.

1
2
3
4
Flux.just(1, 2, 3)
 .doOnNext(i -> System.out.println("호출: " + i))
 .subscribe(i -> System.out.println("출력 결과: " + i));
 
cs

-> doOnNext메소드는 consumer로부터 구독이 일어났을때 실행된다. 그래서 위에 메시지에 next 신호가 발생했을때 다음과 같은 결과가 발생한다.

호출: 1
출력 결과: 1
호출: 2
출력 결과: 2
호출: 3
출력 결과: 3


Subscriber 인터페이스 메서드 사용방법 정의
subscriber에서 제공하는 메소드는 다음과 같고 구독이 발생하면 onSubscribe가 호출되고 다음 값을 요청하면 onNext 오류가 발생하면 onError 모든 데이터 요청이 끝나면 onComplete가 호출된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Flux<Integer> seq = Flux.just(1, 2, 3);
 
seq.subscribe(new Subscriber<>() {
    private Subscription subscription;
    @Override
    public void onSubscribe(Subscription s) {
        // 구독 시작
        this.subscription = s;
        this.subscription.request(1);
    }
 
    @Override
    public void onNext(Integer i) {
        System.out.println("Costomer가 Publisher에게 데이터 요청: " + i);
        this.subscription.request(1);
    }
 
    @Override
    public void onError(Throwable t) {
        System.out.println("Subscriber.onError: " + t.getMessage());
    }
 
    @Override
    public void onComplete() {
        System.out.println("Subscriber.onComplete");
    }
});
cs

-> seq.subscribe 메서드에서 전달한 임의 Subscriber 객체를 onSubscribe 메서드에서 인자로 받아서 이를 필드로 저장하여 사용한다. request(1)은 한개의 데이터를 요청한다는 뜻이다. 만약 모든 데이터를 한번에 받고 싶다면 다음과 같이 지정하면 된다

1
2
3
4
5
6
@Override
public void onSubscribe(Subscription s) {
    System.out.println("Subscriber.onSubscribe");
    this.subscription = s;
    this.subscription.request(Long.MAX_VALUE);
}
cs


콜드 시퀀스와 핫 시퀀스
시퀀스는 구독 시점부터 데이터를 새로 생성하는 Cold sequence와 구독하는 customer와 상관 없이 데이터를 생성하는 hot sequence가 존재한다.

앞 예제 Flux.just()로 생성한 시퀀스가 콜드 시퀀스이다.
콜드 시퀀스는 위에 보면 알겠지만 subscribe가 발생하지 않는다.

Flux<Integer> seq = Flux.just(1, 2, 3);
seq.subscribe(v -> System.out.println(“첫번 째 요청: " + v)); // 구독
seq.subscribe(v -> System.out.println("두번 째 요청: " + v)); // 구독

-> 이 코드를 보면 알겠지만 seq 시퀀스는 구독을 두번한다.이 결과를 seq 시퀀스는 각 구독마다 데이터를 새롭게 생성한다. 마치 API에서 호출하는 것 처럼 매 호출마다 새로운 응답을 만들어 낸다.
첫번 째 요청: 1
첫번 째 요청: 2
첫번 째 요청: 3
두번 째 요청: 1
두번 째 요청: 2
두번 째 요청: 3

핫 시퀀스는 구독여부에 상관없이 데이터가 생성된다. 구독을 하면 구독한 시점이후에 발생하는 데이터부터 신호를 받는다.
-> 예전부터 있었던 데이터를 똑같은 응답을 받는게 아니라 구독을 시작한 부분부터 받는다.


다음 시간에는 스프링으로 직접 만들어보자.



Spring reactor
https://ahea.wordpress.com/2017/02/15/spring-reactive/

단계별 설명
http://wiki.sys4u.co.kr/pages/viewpage.action?pageId=8552586


web/마이크로서비스

마이크로서비스 역량 모델

마이크로 서비스 구현에 필요한 역량은 상황에 따라 다를 수 밖에 없다. 그래서 마이크로서비스 설계 시 필요한 역량 모델에 대해 정리해보자.  

마이크로서비스의 역량 모델은 크게 4 개의 영역으로 분류할 수 있다. 
  • 핵심역량
  • 지원역량
  • 인프라스트럭처 역량
  • 프로세스 및 통제 역량




1. 핵심역량 (Core capabilities)
- 핵심 역량은 하나의 마이크로서비스 안에 패키징 되는 컴포넌트이다. 이곳에서 서비스 리스너, 실행 라이브러리, 서비스 구현 코드, 서비스 API와 종단점이 들어있다.


※ 서비스 리스너와 라이브러리
  • 서비스 리스너는 마이크로 서비스로 들어오는 서비스 요청을 접수하는 종단점 리스너이다.
  • 주로 사용 되는 리스너는 AMQP나 JMS 같은 메시지 리스너가 주로 사용된다.

※ 저장 기능
  • 데이터를 저장 하는 RDBMS나 NoSQL에 저장 할 수 있다.

※  서비스 구현 (Service implementation)
  • 실제로 사용 되는 비즈니스 로직 으로 자바, 스칼라 등등으로 어떤 언어로도 구현할 수 있다.

※ 서비스 종단점 (end-point)
  • 외부의 서비스 소비자가 서비스에게 요청을 전송할 수 있게 외부에 공개한 API를 말한다.
  • 종단점은 동기 또는 비동기일 수 있다. 비 동기인 경우에는 AMQP, 스프링 클라우드 스트림과 같은 메시지 리스너를 통해 요청을 받아서 백엔드에 있는 RabbitMq나 다른 메시징 서버 또는 제로엠큐 같은 다른 방식의 메시징 구현체를 통해 처리한다.




2. 인프라스트럭처 역량
- 성공적인 배포를 위해 인프라스트럭처 역량도 필요하다,

※ 클라우드
  • 인프라스트럭처를 프로비저닝하는 데 오랜시간이 소요되는 전통적인 데이터 센터 환경에서는 마이크로서비스를 구현하는데 어렵다.
  • 많은 애플리케이션이 분리되어 실행되는 마이크로서비스에경우 별도의 데이터 센터에서 관리하면 너무 관리 비용이 크기 때문에 클라우드 인프라스트럭처가 더 나은 선택이다.
  • 클라우드 방식의 인프라스트럭처는 컨테이너나 가상머신을 탄력적으로 늘리고 줄이는 오토스케일링이 가능하다.
 
※ 컨테이너 런타임
  • 다수의 마이크로서비스를 대용량 물리 장비에 배포하는 것은 비용이 많이 든다. 그래서 물리적인 장비만으로는 자동화된 장애 대응성을 갖추기 어렵다.

※ 컨테이너 오케스트레이션
  • 컨테이너나 가상머신의 수가 많으면 자동으로 유지 관리하기 어렵다.
  • 컨테이너 오케스트레이션 도구는 컨테이너 런타임 위에서 일관성 있는 운영환경을 제공하며 가용한 자원을 여러 컨테이너에 분배한다. 대표적 도구로 아파치 메소스, 쿠버네티스 등이 컨테이너 오케스트레이션 도구로서 널리 사용된다.
  • 수작업으로 하면 번거롭고 오류 발생도 높다. 그래서 컨테이너 오케스트레이션 도구를 사용하면 애플리케이션 배포, 트래픽 제어, 인스턴스 복제, 무 중단 업그레이드를 자동으로 수행할 수 있다.
  • 컨테이너 오케스트레이션 도구는 가용성확보와 데이터 센터에 걸친 배포 인스턴스 최소 사용 등의 관리 활동에 도움이 된다.




3. 지원역량 (Supporting Capabilities)
지원 역량은 마이크로서비스와 직접적으로 연결되지는 않지만 대규모 마이크로 서비스 배포에 필수적이다.

※ 서비스 게이트웨이
  • 서비스 게이트웨이 또는 API 게이트 웨이는 서비스 종단점에서 프록시 역할과 종단점을 조합하는 역할을 담당한다.
  • 대표적으로는 스프링 클라우드 zual, Mashery, Apigee, Kong, WSO2, 3scale 등 다양한 제품들이 있다.

※ 소프트웨어 정의 로드 밸런서
  • 로드 밸런서는 유동적으로 변형되는 상황에서 적절하게 대처가 가능하도록 설계가 되어야 한다.
  • ribbon, Eureka, zuul등을 사용해서 지능적인 소프트웨어 정의 로드 밸런서를 구현할 수 있다.
  • 컨테이너 오케스트레이션 도구에서도 로드밸런싱 기능을 잘 사용할 수 있도록 제공하는 방법이 있다.

※ 중앙 집중형 로그 관리
  • 로그파일은 분석과 디버깅에 중요한 정보를 제공한다. 로그는 각각의 인스턴스 디스크에 저장된다. 그래서 분산된 로그를 통합 관리해야한다.
  • 그렇게 하기 위해서 마이크로서비스에서 각 애플리케이션에서 발생한 로그를 중앙 로그 저장소에 저장되도록 해야한다.

※ 보안서비스
  • 분산 마이크로서비스 생태계에서 서비스 인증이나 토큰 서비스 같은 서비스 보안을 담당하는 중앙의 서버를 만들어야 한다.
  • 스프링 부트 OAUTH를 사용해서 인증 방식을 추가할 수 있다.

※ 서비스 환경설정
  • 마이크로 서비스를 사용하여 각자 애플리케이션이 배포 되면서 모든 애플리케이션 관련 설정을 따로따로 관리하기가 쉽지 않다.
  • 그래서 각 환경 설정을 외부화 해야한다. 이런 환경설정 관리 서버로 스프링 클라우드 config 서버, Archaius를 사용할 수 있다.
  • 소규모 마이크로 서비스같이 동적으로 설정을 변경할 필요가 없는 경우 Spring Boot의 프로퍼티로 해도 된다.





4. 프로세스 및 통제역량
프로세스 및 통제 역량은 마이크로 서비스 구현에 필요한 프로세스, 도구, 가이드라인등을 의미한다.


 데브옵스
  • 애자일 개발, 지속적 통합, 자동화 QA, 자동화된 전달 파이프라인, 자동배포, 자동화 인프라스트럭처 프로비저닝 등을 도입 해야 한다.

 자동화 도구
  • 테스트 자동과 자동 배포 등과 같은 자동화 도구 관리를 잘해야 한다.

 컨테이너 레지스트리
  • 마이크로서비스의 버전관리를 위한 artifactory 저장소를 사용한다.

 마이크로서비스 문서화
  • 마이크로서비스에서 개발된 종단점에 대한 정보를 어떻게 보여줄것인지를 보관하는 문서를 가지고 있어야한다.
  • 효과적인 마이크로 서비스 문서는 웹 브라우저에서 접근할 수 있어야 하며, API를 쉽게 탐색하고, 샘플 테스트가 가능해야 한다.
  • 가장 많이 사용하는 라이브러리는 Swagger를 사용한다.

 참조 아키텍처 및 라이브러리
  • 마이크로 서비스는 여러 애플리케이션이 독릭접으로 구성되는데 라이브러리를 가지각색으로 사용하면 문제가 된다.
  • 그래서 중앙에서 공용으로 사용할 수 있는 공용 라이브러리를 만들어서 사용해야 한다.


web/마이크로서비스

마이크로서비스 조립성 및 정리

마이크로서비스의 조립성은 서비스 디자인 원칙의 하나이다. 서비스를 어떻게 디자인해서 효율적으로 할 수 있는 원칙을 이야기하며 크게  두 가지 요소로 나뉜다.


1. 오케스트레이션(Orchestration)

- 여러개의 서비스를 모아 하나의 완전한 기능을 만드는 서비스가 마이크로 서비스이다. 그럴 경우 중앙에서 두뇌 역할을 하는 오케이스트레이터가 여러 서비스를 묶어서 조율할 수 있어야 한다. 이 오케스트레이터는 외부에 노출되는 접점이다.

- 예를들어 주문이라는 서비스가 들어오면 고객 서비스, 상품 서비스, 배송 서비스에 역할을 분배하여 요청하는 중재자를 의미한다.


2. 연출 (Choreography)

- 특정한 서비스가 실행되면 메시키큐에 producer가 이벤트를 넣고 그 곳을 바라보면서 대기하던 consumer들이 자신에 맞는 이벤트 동작을 실행하는 것을 말한다. 

- ESB에 메시지가 푸시되면 그 이후에 처리되는 모든 결정은 메시지를 소비하는 서버에 의해 자동으로 결정된다.



마이크로 서비스의 현명한 종단점 개수는 몇 개일까?

- 마이크로 서비스를 만들 때 종단점의 수는 그렇게 중요하지 않다. 필요에 따라 여러개 일수도 있고 하나가 될 수도 있다.

- 하지만 서로 연결돼서 공통의 데이터를 사용하거나 비슷한 업무를 처리하는 부분을 모두 종단점으로 구분하게 된다면 결과적으로 동일한 부분을 잘게 쪼개놓은 꼴이된다. 결국 성능적으로 더 떨어진 시스템이 될 수도 있다.

- 결론적으로 종단점의 개수는 중요한 것이 아니고 마이크로서비스 크기에 적합하게 경계 지어진 컨텍스트를 적절하게 설계하는 것이 중요하다.


가상머신에 여러개의 마이크로서비스 

- 하나의 가성머신에 여러 마이크로서비스를 올려놓을 수 있다. 이는 용량을 포함하는 리소스가 충분하고 별도의 서비스로 동작하고 서비스 요구사항 (OS, JDK 등등)이 서로 충돌하지 않는다면 가능하다.

- 운영하는 서비스의 인프라의 가용성 특징, 배포 등을 잘 따져가며 설계해야한다.


마이크로서비스의 데이터 스토어 공유 

- 마이크로서비스에서 데이터 스토어를 공유하는 것은 처음에는 별로 어려움이 없어보이지만, 서비스가 많아지고 테이블이 많아지고 하다보면 서비스간에 결합이 생기게 된다. 그러면 두 개의 마이크로서비스도 결국 결합이 생기게 된다. 그러면 효율적인 마이크로서비스라고 할 수 없다.

- 데이터베이스 서버를 별도로 두기에 여유가 없다면 데이터베이스 서버의 스키마를 구분해서 사용해도 된다.

- 또 다른 방법으로 하나의 트랜잭션 관리가 필요한 데이터베이스는 별도로 분리해서 마이크로서비스로 관리하는 것이다.


분산 트랜잭션 시나리오

- 마이크로서비스에서 로컬 트랜잭션만을 이용하고 분산 트랜잭션을 피하는 것이 이상적이다.

- 하나의 서비스에서 식사 예약을 한다고 가정해봤을 때 식사 예약을 완료하기전에 픽업 예약 서비스를 해당 마이크로서비스에 요청한다고 했을 때 픽업 예약은 완료되었지만 식사 예약이 실패할 경우 픽업만 예약되는 사태가 발생할ㄹ 수 있다. 이런 문제를 해결하기 위해 픽업 예약을 식사 예약이 성공적으로 끝나고 나면 보내는 방법이 있으나 메시지를 보내고 나서 갑자기 실패하는 경우 등에 대한 문제를 해결하기에는 부족하다.


서비스 종단점 설계 고려사항

- 마이크로서비스에서 서비스 설계는 Contract Design (계약설계), Protocol Selection (프로토콜 선택) 이라는 두 가지 핵심요소로 나뉜다.

1. 계약 설계

- 서비스 설계에서 가장 주요한 원칙은 단순함이다. 서비스는 소비자가 소비할 수 있게 설계되어야한다. 복잡한 서비스 계약은 서비스의 사용성을 떨어트린다.


2. 프로토콜 선택

- 마이크로서비스는 SOA(서비스 지향 아키텍처)와 동일하게 HTTP/SOAP와 메시징 서비스 상호작용을 위한 기본 서비스 프로토콜을 따른다.

- 메시지 방식이나 REST 방식을 사용한다.

- API 문서는 Swagger 등을 사용한다.


공유 라이브러리 처리

- 마이크로서비스의 기본원칙은  자율성과 자기 완비성이다. 그래서 다른 서비스에서 같은 라이브러리가 필요한 경우가 있을 있다.

만약 동일 코드나 라이브러리를 서로 다른 마이크로서비스에서 가지게 된다면 중복 문제가 있지만 그렇지 않으면 한쪽 마이크로서비스에 다른 마이크로서비스가 의존하게 되는 문제가 발생할 있다. 

만약 동일한 코드를 둘다 가지고 있게 된다면 모든 지식은 하나의 시스템 안에서 오직 하나의 모호하지 않은 권위를 가진 표현으로 존재해야 한다는 DRY 원칙을 어긋나게 된다.

하지만 그렇다고 공통 서비스를 또다른 마이크로서비스로써 값을 참조하게 한다면 또다른 복잡도를 가질 있기 때문에 상황에 맞게 선택해서 진행하는것이 좋다.


API 게이트웨이

- 출국관리 애플리케이션에서 체크인, 라운지관리, 탑승수속등의 기능이 필요하다고 가정해보자. 각 서비스들은 별도의 API로 개발되어 있다. 하지만 이는 출국 관리 애플리케이션에서 봤을 때 하나의 웹 애플리케이션에 담아서 관리할 필요성이 있다고 느껴진다. 이럴 경우에 마이크로서비스(API들)를 연결해주는 컨테이너 웹 애플리케이션이나 Placeholder가 필요한데 이 경우 별도의 API 게이트 웨이를 만들어서 사용할 수 있다.

- 요청에 따라 모든 데이터를 한번에 전달하는 API는 쓸데없는 오버헤드를 발생시킬 수 있다. 그래서 필요한 데이터만 필드에 보내줄 수 있다. 하지만 그럴 경우 필요에 따라 전달되는 형식이 바뀌어야한다. 그래서 API 게이트웨이에서 데이터 명세에 따라 필요 데이터만 클라이언트 쪽으로 내보내주도록 만들어서 기존의 API들은 원래 하던대로 동작해도 무관하게 설계할 수 있다.







web/마이크로서비스

마이크로 서비스 통신방식 결정

마이크로서비스 사이의 통신은 요청-응답 형태로 진행되는 동기와 비동기 방식으로 설계할 있다.


동기와 동기는 서비스별로 어울리도록 정책을 가져야 한다.  예를 들어 예약서비스에서 기록이 되는 부분까지는 동기로 진행해서 사용자에게 보여주고 

기타 재고 갱신 서비스, 호텔 알림 서비스 등등 당장 순차적으로 실행돼야 하는 것이 아닌 서비스는 동기로 처리하도록 한다.

 

 

동기 방식

  • 이벤트를 보관하는 메시지 등이 없어 관리할 포인트가 적다.
  • 서로 응답을 주고 받는 형식이기 때문에 인프라 스트럭처상에서의 의존관계가 없어서 관리에 드는 비용이 적다.
  • 순차적으로 단계별로 진행되기 때문에 에러가 발생할 경우 데이터의 일관성을 유지할 있다.
  • 응답을 기다려야 하는 단점은 너무 동기로 묶여 있을 경우에는 마이크로서비스로 구분하는 장점이 사라지기 때문이다.

 

 

비동기 방식

  • 마이크로서비스 사이의 결합을 해소하여 리액티브한 이벤트 루프 방식에 바탕을 둔다.
  • 서비스가 독립적이고 작업을 하는 스레드를 만들어서 부하를 분산할 있어 고수준의 확장성이 가능하다.
  • 동기 방식과 달리 발생한 이벤트를 메시지 큐에 전송하고 이벤트를 별도로 처리하기 때문에 특정 영역에 문제가 발생 되어도 서비스에는 전체에 문제가 발생되지 않는다.
  • 메시지 큐를 사용하는 장점도 있으나 메시지 서버에 부하가 발생되면 모든 구간에 문제가 발생할 있기 때문에 관리가 필요하다.

 

 

 

 

 

 

 


web/마이크로서비스

마이크로서비스에서 애플리케이션에 컨텍스트를 구분하는 기준

마이크로서비스에서 애플리케이션에서 컨텍스트를 구분하는 기준이 생각보다 애매하다. 어디서부터 어디 까지 정의해서 사용해야 하는지에 대한 기준을 정리해보자.

 

자율적인 기능 제공 서비스

  • 암호화 유틸 서비스, 배송 조회 검색 기능 서비스 자율적인 동작이 가능한 서비스의 경우에는 마이크로서비스의 별도 컨텍스트로서 사용이 가능하다.

 

배포 단위의 크기

  • 좋은 마이크로서비스가 있도록 배포 단위의 크기를 관리할 있는 수준 이내로 유지해야한다.

 

분리하기 가장 적합한 기능 또는 서브 도메인

  • 일체형 서비스를 마이크로서비스로 분리하고자 자원 소모량, 소유 비용, 비즈니스 효율성, 유연성 측면에서 분석 기준을 나눠서 생각해야한다.

 

폴리그랏 아키텍쳐

  • 다양한 기능/기능적 요구 사항을 충족시키기위해 컴포넌트 마다 서로 다른 아키텍처 다른 기술 다른 배포 방식을 사용할 있는 것을 말한다.
  • 예를 들어 특정 서비스는 MySql 사용하고 다른 쪽은 검색을 위한 Elasticsearch 등을 사용할 있다.

 

애자일팀과 협력 개발

  • 마이크로서비스는 체중에서 서로 다른 일부를 개발하는데 집중할 있는 작고 집중력 있는 구성을 통해 애자일 방식의 개발을 가능하게 해준다.
  • 마이크로 서비스 세상에서 팀이 서로 다른 마이크로서비스를 만들고 나중에 하나로 조합할 있다.

 

단일 책임

  • 단일 책임의 원칙은 소프트웨어 공학에서 특정 기능을 위해 만들어진 메서드나 클래스가 가지 이상의 역할을 해서는 안되는 원칙이다.
  • 단일 책임 원칙에서 하나의 책임이 여러 마이크로서비스와 공유될 없는 것처럼 하나의 마이크로 서비스는 여러 책임을 담당해서는 안된다.

 

결합과 응집

  • 서비스 경계를 결정 짓는데 가장 중요한 가지 기준은 결합(Coupling) 응집(Cohesion)이다.
  • 마이크로서비스 사이의 의존 관계 높은 결합도가 형성되지 않도록 해야한다.
  • 너무 많은 정보 교환과 동기 요청을 사용한다면 시스템을 망가트리는 원인이 되기도 한다.
  • 트랜잭션 범위가 하나의 마이크로서비스의 범위를 넘어서 여러 마이크로서비스에 걸치지 않게 하는 것도 중요하다.

 

마이크로서비스를 하나의 제품으로 생각하기

  • DDD 경계 지어진 컨텍스트를 하나의 제품과 짝짓는 것을 권장한다.
  • 하나의 Context 하나의 단독 제품으로써 구분되는 것이 가장 이상적이다.
  • 마이크로서비스로 서비스가 구분되는 기준을 이와 비슷한 개념으로 하나의 서비스로써 구분되는 것으로 생각하는 것이 좋다.

 [ 1 ]  [ 2 ]  [ 3 ] 

푸터바

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

  • Today : 0
  • Yesterday : 460
  • Total : 82,691