본문 바로가기

프로그래밍/컴퓨터 서적 리뷰 & After Service

스프링 부트 2.0 2/e 마이크로서비스와 리액티브 프로그래밍

다음의 내용은 에이콘출판사의 나온 스프링 부트 2.0 2/e 마이크로서비스와 리액티브 프로그래밍(원서 제목은 Learning Spring Boot 2.0 Second Edition) 책을 일고 실습해가면서 몇몇 수정한 부분들에 대한 기록이다. 이전글인 Mastering Spring 5.0때와 상황이 비슷하다.   

이 책에서 사용한 Spring Boot 버전은 2.0.0.M5 이고 2019년 6월 7일 현재 이 글을 쓰는 시점에서 내가 사용하고 있는 Spring Boot 버전은 2.1.5.RELEASE 이다  

이전 글과 마찬가지로 순서는 책의 순서와는 맞지는 않으며 차후 수정이 계속 이루어질 것이며 수정과정에서 순서가 맞춰질수도 있다. Mastering Spring 5.0 때는 9장 공부하는 시점부터 문제가 생겼지만 이 책은 6장에서부터 문제가 시작되었다(사실 발생된 Chapter는 중요하진 않다. 실습하면서 문제가 생기는 시점은 책에서 Spring Cloud와 관련된 내용을 다루기 시작하는 시점에서부터 생기는거여서..)

 

● Gradle 에서 Spring Cloud Greenwich Dependency 설정

 

이 책의 254 페이지부터 스프링 클라우드 스트림 관련 설정이 소스 코드에 반영이 되어야 한다. 예전 글인 Mastering Spring 5.0 에서는 Maven 기반의 프로젝트로 샘플 코드가 만들어져 있었으나 이 책의 경우는 Gradle 기반의 프로젝트로 샘플 코드가 만들어져 있다. 그래서 단순히 책의 255 페이지에 있는 compile 구문만 추가해도 라이브러리가 추가되지 않는다. Mastering Spring 5.0 때와 마찬가지로 Spring Cloud Greenwich 설정을 Gradle에서 해주어야 라이브러리 다운로드가 가능하다. 다음의 내용을 build.gradle에 추가해주자.

 

buildscript {
    dependencies {
        classpath "io.spring.gradle:dependency-management-plugin:1.0.2.RELEASE"
    }
}

apply plugin: 'io.spring.dependency-management'

dependencyManagement {
    imports {
        mavenBom 'org.springframework.cloud:spring-cloud-dependencies:Greenwich.RELEASE'
    }
}

apply plugin: 'io.spring.dependency-management' 부분은 실습을 위해 Spring Boot Gradle 프로젝트를 만드는 과정에서 기본적으로 추가되어있을수 있다(내경우에는 그러했다) 이미 설정되어 있으면 하지 않아도 된다. buildscript, dependencyManagement 항목이 build.gradle의 어느 위치에 있어야 하는지는 정해져 있는건 없다(자신이 넣고 싶은 위치에 넣으면 된다는 뜻) 위의 내용을 넣고 책의 255 페이지에 있는 compile 부분을 build.gradle 에 추가하면 된다(정상적으로 처리되지 않았을 경우 책에서 실습한 RabbitMQ 관련 코드 부분들이 에러가 발생하기 때문에 정상적으로 라이브러리가 추가되었는지 아닌지 확인이 가능하다) 

 

이 글을 쓴 뒤에 책을 계속 읽어나가니 이 부분에 대한 설명이 책의 256 페이지에 있었다. 그러나 책에서 사용하는 스프링 클라우드 릴리스 트레인인 Finchley의 경우는 Spring Boot 2.0.X에 맞춰져 있어서 Spring Boot 2.1.X에는 맞지가 않다. 책과 같은 방법으로 이를 구현하려 할 경우 buildscript의 springCloudVersion 항목을 'Greenwich.REALEASE' 로 주면 된다.

 

● 257 페이지에 있는 CommentController 클래스 소스 코드의 CounterService 클래스에 대해..

 

CommentController 클래스 소스 코드를 보면 CounterService  클래스 객체를 멤버변수로 사용하고 있는데 CounterService 클래스는 이 샘플 프로젝트에서 실제 존재하는 클래스가 아니다.(github의 프로젝트 소스를 봐도 이 클래스 소스는 존재하지 않는다. github에 올라와 있는 프로젝트 소스에서 CommentController 클래스 소스를 보면 책과는 다르게 나와있다.) CounterService 관련 부분은 실습할때는 코딩하지 않도록 한다.

 

● 299 페이지 서킷 모니터링의 Hystrix

 

책에서는 299 페이지의 서킷 모니터링에서 Hystrix에 대한 설명을 하고 있다. Hystrix 설정에 대해서는 문제점은 없는데 다만 http://localhost:8080  주소를 브라우저로 한번도 접근하지 않은 상태에서 Hystrix Dashboard를 통해 http://localhost:8080/actuator/hystrix.stream 을 통해 모니터링을 시작하면 화면이 loading 만 나오고 아무 반응이 없다. 그래서 http://localhost:8080 주소를 브라우저로 한번 접근해야 hystrix 에서 모니터링 화면이 나오게 된다.

그러나 이 책에서 보면 Hystrix의 인위적인 장애상황을 테스트 하기 위해 CommentSilmulator 클래스를 수정해서 Comment가 자동으로 등록이 되는 작업과 http://localhost:8080 으로 접근한 효과를 나타내기 위해 HomeController의 index 메소드를 호출하고 있다. 그렇기 때문에 CommentSimulator 클래스를 수정한뒤에 simulator profile로 Images MicroService를 실행하게 되면 당연 Hystrix Dashboard 화면에서 브라우저로 http://localhost:8080 을 접근하지 않았어도 모니터링이 되는 화면이 나와야 하는데(CommentSimulator 클래스에서 HomeController의 index 메소드를 호출하고 있기 때문에..) 그러지를 않고 있다. 그래서 중단점을 걸어서 확인을 해보니 CommentSimulator 클래스를 통해 실행이 될 경우 Images MicroService에 있는 CommentHelper 클래스의 getComments 메소드가 실행되지 않는 것으로 확인이 되었다. 이 메소드에 HystixCommand 어노테이션을 걸었기 때문에 이 메소드가 실행이 안되면 Hystix Dashboard에서 모니터링이 되지 않는 것이다. 그러나 브라우저로 http://localhost:8080 으로 접근할 경우 CommentHelper 클래스의 getComments 메소드가 실행되는 것으로는 확인이 되었다. 이 차이가 왜 발생하는지는 현재는 파악하지 못한 상태이다.