maven compile (testCompile 포함) 후에 테스트를 진행했더니
context 불러오는 과정에서 어떤 빈을 찾을 수가 없다는 에러가 뜬다.
그래서 context 불러오는 것을 실패하였다.
소스를 보니 빈을 못 찾을 이유가 없었다.
확인해보니 target/test-classes 폴더 안에 test용 resource 파일들이 복사되지 않았다.
spring application context xml 파일이 없으니 어떤 빈도 찾지 못하는 거 였다.
testCompile을 하면 생기는 줄 알았는데 생기지 않는다.
package 해보니 test resource 파일들이 target 폴더 안에 생성되었다.
흠.. 왜그런거지
혹시 아시는 분은 댓글에 적어주시면 고마워요
dependencies {
implementation 'org.springframework.cloud:spring-cloud-stater-netflix-eureka-server'
}
@EnableEurekaServer
@SpringBootApplication
public class DiscoveryApplication {
public static void main(String[] args) {
SpringApplication.run(DiscoveryApplication.class, args);
}
}
server:
port: ${PORT:8761}
eureka:
client:
register-with-eureka: false # 유레카 클라이언트 비활성화
fetch-registry: false
dependencies {
...
implementation 'org.springframework.cloud:spring-cloud-stater-netflix-eureka-server'
...
}
@EnableDiscoveryClient
@SpringBootApplication
public class ClientApplication
spring:
application: name: client-service
server:
port: ${PORT:8081}
eureka:
client: service-url: default-zone: ${EUREKA_URL:http://admin:admin123@localhost:8761/eureka/} # 디스커버리 주소
java -jar -DPORT=8081 client-0.0.1-SNAPSHOT.jar
java -jar -DPORT=8082 client-0.0.1-SNAPSHOT.jar
클라이언트 서비스 종료하기 (actuator/shutdown API 활용)
dependencies {
...
implementation 'org.springframework.boot:spring-boot-starter-actuator'
...
}
사용할 actuator API 설정 후, /shutdown 활성화
management:
endpoints:
web:
exposure:
include: health, info, metrics, shutdown
endpoint:
shutdown:
enabled: true
eureka:
client:
register-with-eureka: false # 유레카 클라이언트 비활성화
fetch-registry: false
server:
enable-self-preservation: false # 자기 보호 모드(네트워크 장애가 발생하여도 서비스 해제를 방지하는 모드) 비활성화
eureka:
client:
service-url:
default-zone: ${EUREKA_URL:localhost:8761/eureka/} # 디스커버리 주소
instance:
lease-renewal-interval-in-seconds: 1 # 디스커버리한테 1초마다 하트비트 전송
lease-expiration-duration-in-seconds: 2 # 디스커버리는 서비스 등록 해제 하기 전에 마지막 하트비트에서부터 2초 기다림
@RestController
public class TestController {
private static final Logger LOGGER = LoggerFactory.getLogger(TestController.class);
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping("/ping")
public List<ServiceInstance> ping() {
List<ServiceInstance> instances = discoveryClient.getInstances("CLIENT-SERVICE");
LOGGER.info("INSTANCES: count = {}", instances.size());
instances.forEach(it -> LOGGER.info("INSTANCE: id={}, prot={}", it.getServiceId(), it.getPort()));
return instances;
}
}
스프링 클라우드 유레카는 다음과 같이 필드를 조합해 식별자를 자동 생성
${spring.cloud.hostname}:${spring.application.name}:${spring.application.instance_id}:${server.port}
기본적으로 인스턴스는 호스트명으로 등록된다. 그러나 DNS가 없는 경우에는 host 파일에 IP를 등록하지 않으면 인스턴스를 찾지 못하게 된다. 이에 대안으로 eureka.instance.prefer-ip-address 속성을 통해서 서비스의 IP 주소를 사용할 수 있다.
서비스의 네트워크 위치를 결정하기 위한 방법으로 IP 주소를 사용하면 문제가 발생할 수 있다. 장비에서 하나 이상의 네트워크 인터페이스가 있을 경우에 발생한다. 이를 위해 컨피규레이션 파일에 무시할 패턴 또는 선호하는 네트워크 주소를 설정할 수 있다.
eh1로 시작하는 인터페이스 무시
spring:
cloud:
inetutils: ignored-interfaces: # 해당 인터페이스 무시
- eth1*
선호하는 IP 주소 설정(필수가 아닌 선호이다.)
spring:
cloud:
inetutils:
preferred-networks:
- 192.168
eureka:
server:
response-cache-update-interval-ms: 3000 # Response 캐싱 주기
eureka:
client:
registry-fetch-interval-seconds: 3 # 서비스 목록 3초마다 캐싱
disable-delta: true #캐싱할 때 변경된 부분만 업데이트
지금까지 유레카 서버는 모든 클라이언트의 연결을 인증하지 않았다. 그러므로 기본 인증을 사용하기 위해 스프링 시큐리티 의존성을 추가하여 최소한의 보안을 적용해보자.
dependencies {
...
implementation 'org.springframework.boot:spring-boot-stater-security'
...
}
그리고 http baisc authentication을 적용하기 위해 설정을 한다.
spring:
security:
user:
name: admin
password: admin123
이제 인증을 위해 클라이언트 application.yml에 아래와 같이 설정하자.
eureka:
client:
service-url:
default-zone: http://admin:admin123@localhost:8761/eureka/ # 디스커버리 주소
이 후에 SSL 연결 등 진보된 보안을 위해 '12장 API 보안 강화하기’에서 다룰 것이다.
클라이언트에 SSL을 적용해보자.
keytool -genkey -alias client -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore.p12 -validity 3650
스프링 클라우드 넷플릭스는 유레카 클라이언트가 JAVA, 스프링 프레임워크를 사용하지 않을 경우 (다른 프로그래밍 언어로 개발됐거나 배포 프로세스에서 등록된 서비스 목록 정보가 필요한 경우) 디스커버리 서버를 이용하기 위해 클라이언트 API를 제공한다.
| HTTP API | 설명 |
|---|---|
| POST /eureka/apps/appID | 레지스트리에 새로운 서비스 인스턴스를 등록 |
| DELETE /eureka/apps/appID/instanceID | 레지스트리에서 서비스 인스턴스를 제거 |
| PUT /eureka/apps/appID/instanceID | 서버에 하트비트를 전송 |
| GET /eureka/apps | 등록된 모든 서비스 인스턴스의 상세 정보를 조회 |
| GET /eureka/apps/appID | 특정 서비스의 모든 인스턴스의 상세 정보를 조회 |
| GET /eureka/apps/appID/instanceID | 특정 서비스의 특정 인스턴스의 상세 정보를 조회 |
| GET /eureka/apps/appID/instanceID/metadata?key=value | 메타 정보 입력값을 갱신 |
| GET /eureka/instances/instanceID | 특정 ID를 사용하는 모든 등록된 인스턴스의 상세 정보를 조회 |
| PUT /eureka/apps/appID/instanceID/status?value=DOWN | 인스턴스의 상태를 갱신 |
넷플릭스 주울 기반의 API 게이트웨이 적용하고 API 게이트웨이를 통해 하나의 서비스에 대해 각기 다른 존(zone)에 등록된 애플리케이션 인스턴스 간의 부하 분산 테스트를 할 수 있다.
다음 다이어그램은 예제 시스템의 아키텍처이다.
| 3장 스프링 클라우드 개요 (0) | 2019.01.23 |
|---|---|
| 2장 마이크로서비스를 위한 스프링 (0) | 2019.01.22 |
| 1장. 마이크로서비스 소개 (0) | 2019.01.22 |
3장의 목적
스프링 클라우드 프로젝트와 관련된 기본을 인지하고, 마이크로서비스 기반 아기텍처에서 가장 중요한 요소가 무엇인지 알고 스프링 클라우드의 자주 사용되는 하위 프로젝트를 나열할 수 있어야 한다.
스프링 클라우드
12-팩터 앱(The Twelve-Factor App)이란? (참조 : https://12factor.net/ko/)
확장이 가능하고 쉽게 클라우드 플랫폼에 배포할 수 있으며 지속 배포 프로세스에 따라 배포되는 Software as a Service(SaaS)를 개발하는 방법론
스프링 부트와 스프링 클라우드는 12팩터룰에 부합하는 기능과 요소를 제공
기본부터 시작하기
(책의 내용이 이해가 되지 않을 때 참조 : https://yaboong.github.io/spring-cloud/2018/11/25/spring-cloud-config/)
스프링 클라우드는 스프링 부트와 달리 원격 서버에서 컨피규레이션을 가지고 옴 (spring-cloud-starter-config를 사용)
부트스트랩 컨텍스트
일반적인 애플리케이션 이름과 스프링 클라우드 컨피그(Srping Cloud Config) 설정 (bootstrap.xml)
1 2 3 4 5 6 | spring : application : name : person-service cloud : config : url : http://192.168.99.100:8888 | cs |
부트스트랩 컨텍스트 설정하기
부트스트랩 컨텍스트를 지원하는 스프링 부트 액추에이터 API
스프링 클라우드 프로젝트는 서비스 디스커버리, 부하 분산, 서킷 브레이커 등의 메커니즘을 위한 공통의 추상 레이어를 제공
넷플릭스(Netflix) OSS(Open Source Software)
마이크로서비스의 선두주자인 회사 넷플릭스가 마이크로서비스 오픈 소스를 공유
스프링 클라우드는 넷플릭스의 유명한 오픈 소스 기능인 유레카(Eureka), 히스트릭스(Hystrix), 리본(Ribbon), 주울(Zuul) 등과 통합
유레카를 이용한 서비스 디스커버리
유레카(Eureka)는 클라이언트와 서버로 구분하여 사용
주울을 사용한 라우팅
주울(Zuul)
리본을 사용한 부하 분산
리본(Ribbon)
자바 HTTP 클라이언트 작성하기
페인(Feign)
히스트릭스를 사용해 대기 시간 및 장애 내성 다루기
히스트릭스(Hystrix)
아카이우스를 사용한 컨피규레이션 관리
아카이우스(Archius)
디스커버리와 분산 컨피규레이션
서비스 디스커버리와 분산 컨피규레이션 관리는 유연한 키-값 저장소 형태로 기술적으로 매우 비슷
서버는 단 하나의 저장소로, 애플리케이션을 위한 모든 외부 속성을 관리
컨피규레이션은 여러 버전과 프로파일로 동시에 유지하며, 깃을 사용
설정 파일은 파일 시스템, 서버 클래스 경로에 있을 수 있으며 또는 백엔드를 볼트(Valut)로 사용 가능
컨피그 서버
또 다른 대안 - 컨설
컨설(Consul)
아파치 주키퍼
주키퍼(Zookeeper)
기타 프로젝트
스프링 클라우드 쿠버네티스(Kubernetes)
스프링 클라우드 에티시디(Etcd)
솔루션을 사용한 분산 추적
스프링 클라우드 슬루스(Sleuth)
스프링 클라우드 슬루스는 지연 분석을 위한 기간 정보도 기록이 가능하며 집킨 도구에 제공할 수 있음
집킨(Zipkin)
모든 데이터를 분석할 필요는 없다
메시징과 통합
스프링 클라우드 버스
스프링 클라우드 스트림
클라우드 플랫폼 지원
피보탈 클라우드 파운드리(PCF, Pivotal Cloud Foundry)
스프링 클라우드는 AWS를 지원하기 위해 유명한 웹 도구와 통합
주요 모듈
스프링 클라우드 커넥터 프로젝트
다른 유용한 라이브러리
보안
스프링 클라우드 시큐리티
테스트 자동화
스프링 클라우드 컨트랙트
스프링 클라우드 태스크
클러스터 기능
스프링 클라우드 클러스터
프로젝트 개요
분산 컨피규레이션
서비스 디스커버리
상호 통신
추적
클라우드 플랫폼 지원
메시징 및 통합
기타
릴리즈 트레인(release trains)
스프링 클라우드 내에 수많은 프로젝트가 있어 의존성 관리가 문제가 되어 모든 프로젝트 버전 간의 관계를 알아야 하는 문제가 발생
이를 위해 릴리즈 트레인 도입
릴리즈를 버전이 아닌 BOM에 기반한 이름으로 구분
BOM(Bill of materials)는 아티팩트 버전을 독립적으로 관리하는 표준 메이븐 개념
최신 릴리즈 목록 : https://project.spring.io/spring-cloud/
릴리즈 트레인 뒤에 붙은 표시
메이븐 또는 그래들로 의존성을 포함할 시 올바른 릴리즈 트레인 이름을 사용해야 함
요약
목적 : 스프링 클라우드 프로젝트와 관련된 기본을 인지하고, 마이크로서비스 기반 아기텍처에서 가장 중요한 요소가 무엇인지 알고 스프링 클라우드의 자주 사용되는 하위 프로젝트를 나열할 수 있어야 한다.
| 4장 서비스 디스커버리 (0) | 2019.02.01 |
|---|---|
| 2장 마이크로서비스를 위한 스프링 (0) | 2019.01.22 |
| 1장. 마이크로서비스 소개 (0) | 2019.01.22 |
1장에서는 마이크로서비스의 개요 및 아키텍처, 클라우드 개념 등에 대해서 알아보았습니다.
그럼 2장에서는 마이크로서비스를 스프링으로 구현하기 위한 스프링 부트에 대한 사전지식을 알아볼시다~
스프링 부트 소개
우선 마이크로서비스에서 표준 스프링 컨피규레이션이 아닌 스프링 부트를 사용하면 좋은 점과 스프링 부트의 장점을 알아보겠습니다.
스프링 부트는 표준 스프링 컨피규레이션과 다르게 독립 실행형 어플리케이션을 java -jar 명령어를 통해 실행합니다.
스프링 부트는 표준 스프링 컨피규레이션과 달리 웹 컨테이너를 애플리케이션에 포함할 수 있습니다.
마이크로서비스에서 표준 스프링 컨피규레이션보다 스프링 부트가 더 적합한 이유는 여기에 있습니다.
마이크로서비스는 다른 마이크로서비스와의 독립성이 중요합니다. 그러므로 데이터베이스와 웹 컨테이너와 같은 공통의 자원을 공유하지 않아야 합니다.
그러나 표준 스프링 컨피규레이션은 애플리케이션에 웹 컨테이너를 포함하는 대신 애플리케이션을 war 형태로 웹 컨테이너에 배포하므로,
하나의 웹 컨테이너에 여러 war 파일을 배포할 수 있기 때문에 마이크로서비스와는 적합하지 않습니다.
스프링 부트의 가장 큰 장점은 표준 스프링에 비해 간단하다는 것입니다.
스프링 부트가 간단할 수 있는 이유는 크게 두 가지인데,
그 두 가지는 스타터와 자동 컨피규레이션(auto-configuration) 입니다.
스타터는 프로젝트 의존성에 포함될 수 있는 아티팩트입니다. (여기서 아티팩트는 빌드로 생성되는 결과물을 이야기합니다.)
스타터는 필요한 의존성을 패키지로 제공해주므로 별도의 설정이 필요 없이 즉시 사용할 수 있어 매우 빠르고 간단합니다.
스타터의 공식적인 명명 패턴은 spring-boot-start-* 입니다.
자동 컨피규레이션은 스타터에 포함된 아티팩트의 기본 설정을 다른 속성이나 다른 유형의 스타터로 쉽게 재정의할 수 있게 해줍니다.
(추가된 의존성의 아티팩트 기반으로 스프링 애플리케이션을 자동적으로 설정해주며 다른 설정으로 변경할 수도 있다는 것을 말합니다.)
스프링 부트를 이용한 애플리케이션 개발
이제 스프링 부트를 이용하여 간단한 애플리케이션을 개발해보겠습니다.
스프링 부트와 메이븐(Maven)과 그래들(Gradle)과 같은 의존성 관리시스템을 활용하면 어떠한 의존성을 포함하는지 간단히 확인할 수 있어 매우 효율적입니다.
의존성 관리 도구를 통해 톰캣을 기본 컨테이너로 내장한 spring-boot-start-web (RESTful, Spring MVC 포함하는 기본 스타터)을 추가합니다.
다음은 메이븐 pom.xml 예제입니다.
1 2 3 4 5 6 7 8 9 10 11 | <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.7 RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies> | cs |
또는 spring-boot-starter-parent POM에서 상속받지 않고 dependencyManagement 태그를 사용할 수도 있습니다.
[dependencyManagement 부연설명 : https://examples.javacodegeeks.com/enterprise-java/maven/use-maven-dependency-management-2/]
1 2 3 4 5 6 7 8 9 10 11 | <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>1.5.7.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> | cs |
그래들 입니다.
1 2 3 4 5 6 7 8 | plugins { id 'org.springframework.boot' version '1.5.7.RELEASE' } dependencies { compile("org.springframework.boot:spring-boot-stater-web:1.5.7.RELEASE") } | cs |
이제 Main 애플리케이션 클래스를 생성하고 @SpringBootApplication 애노테이션을 추가합니다.
@SpringBootApplication은 @Configuration, @EnableAutoConfiguration, @ComponentScan의 세 애노테이션과 같습니다.
1 2 3 4 5 6 7 | @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } | cs |
이제 실행 가능한 애플리케이션이 완성되었습니다.
그리고 모든 의존성을 포함하는 실행 가능한 JAR (팻JAR 또는 JARs)를 생성하기 위해서는
메이븐의 spring-boot-maven-plugin이 필요합니다. pom.xml에 추가해줍니다.
1 2 3 4 5 6 7 8 | <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>srping-boot-maven-plugin</artifactId> </plugin> </plugins> </build> | cs |
이제 기본 스프링 라이브러리를(spring-core, spring-aop, spring-context, spring boot, 내장형 톰캣, 로깅 라이브러리 등) 포함한 팻JAR를 생성할 수 있습니다.
컨피규레이션 파일 사용자 정의하기
스프링 부트는 편리하고 쉽게 설정을 관리할 수 있는 메커니즘을 제공합니다.
가장 간단한 방법은 애플리케이션 JAR에 추가된 컨피규레이션 파일을 이용하는 것입니다.
스프링 부트는 application으로 시작하는 컨피규레이션 파일을 자동으로 찾으며, 지원하는 파일 타입은 .properties와 .yml입니다.
(설정 파일명은 일반적으로 application 또는 application-{profile}이며 이외의 특정한 이름을 부여하려면 환경변수를 통해 등록 가능합니다.)
또한 컨피규레이션 파일을 외부로 뽑아낼 수 있는데, 이 때 파일의 위치는 다음과 같아야 합니다.
일반적으로 application 컨피규레이션 파일은 src/main/resources 디렉토리에 위치하며, 메이븐 빌드 후에는 JAR의 루트에 위치합니다.
컨피규레이션 파일에서 두 종류의 설정을 지정할 수 있습니다. 첫 번째는 주로 spring-boot-autoconfiguration 라이브러리에서 사용되는 공통설정과 미리 정의된 스프링 부트 설정입니다. 두 번째는 사용자 정의 속성을 지정할 수 있으며 @Value 또는 @ConfigurationProperties 애노테이션을 통해 주입될 수 있습니다.
기본 서버 포트, 애플리케이션 이름, 로깅 속성 등을 재정의하는 예제 .yml 컨피규레이션 파일을 작성해봅시다.
1 2 3 4 5 6 7 8 9 10 11 12 | server : port : ${port:2222} spring : application : name : first-service logging : pattern : console : "%d{HH:mm:ss.SSS} %-5level %logger{36} - %msg%n" file : "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" level : org.springframework.web : DEBUG file : app.log | cs |
외부 컨피규레이션 파일을 지정할 필요 없이 간단하게 설정을 할 수 있습니다. 로깅 컨피규레이션을 위해 log4j.xml 또는 logback.xml 등을 설정할 필요가 없다는 말입니다. 기본 로그 레벨을 DEBUG로 변경하고 로그 패턴을 수정하고 app.log 파일을 생성했으며, 기본 HTTP 포트는 2222라는 설정을 간단하게 하였습니다.
사용자 컨피규레이션도 같은 파일에 위치해야 한다. 사용자 정의 속성을 포함하는 예제를 작성해봅시다.
1 2 3 4 5 | name : first-service my : service : -dev.bar.com -foo.bar.com | cs |
위와 같이 설정 후 @Value, @ConfigurationProperties 애노테이션을 활용해 주입할 수 있습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | @Component public class CustomBean { @Value("${name}") private String name; // ... } @ConfigurationProperties(prefix="my") public class Config { private List<String> servers = new ArrayList<>(); public List<String getServers() { return this.servers; } } | cs |
지금까지 간단한 애플리케이션을 설정하고 생성했습니다. 이와 다른 방법으로 웹에서 생성하는 방법도 존재합니다.
스프링 이니셜라이즈 웹사이트(https://start.spring.io)를 통해서도 프로젝트를 생성할 수 있습니다.
RESTful 웹서비스 생성하기
이제 RESTful 웹서비스를 만들어봅시다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | @RestController @RequestMapping("/person") public class PersonController { @GetMapping public List<Person> findAll() { return getPersons(); } @GetMapping("/id") Person findById(@RequestParam("id") Long id) { return getPerson(id); } @PostMapping Person add(@RequestBody Person p) { p.setId(getPersons().size() + 1); addPerson(p); return p; } @DeleteMapping("/{id}") public void delete(@RequestParam("id") Long id) { removePerson(id); } @PutMapping("/{id}") public void update(@RequestBody Person p) { updatePerson(p); } } | cs |
@RestController는 HTTP 요청을 처리하는 컨트롤러 빈 클래스에 설정하면 RESTful 웹서비스를 지원합니다.
@RequestMapping은 컨트롤러 메소드와 HTTP URL 주소를 대응해줍니다.
@GetMapping, @PostMapping, @DeleteMapping, @PutMapping은 특정 HTTP 메서드를 지정해 주며 @RequestMapping(method=RequestMethod.GET)과 동일합니다.
@RequsetParam은 요청의 경로와 입력값을 객체로 바인딩한다.
@RequestBody는 입력 JSON을 잭슨 라이브러리를 사용해 객체로 바인딩한다.
자 이제 우리는 몇 개의 REST API를 제공하는 첫 마이크로서비스를 만들었습니다.
그렇다면 다른 클라이언트가 이 API를 호출하기 위해서는 API 문서가 필요합니다.
여기서 스웨거(Swagger)가 필요합니다. 스웨거는 API문서를 제공하고 자동으로 생성해주는 도구입니다.
API 문서화
스웨거는 RESTful API를 설계하고 빌드하고 문서화하는데 가장 많이 사용되는 도구입니다.
스웨거를 통해 API를 설계하고 소스코드를 생성할 수 있고, 소스코드로 API 문서인 스웨거 파일을 생성할 수 있습니다.
스웨거2를 스프링 부트와 같이 사용하기
스프링 부트와 스웨거2는 스프링폭스(Springfox) 프로젝트에 구현되어 있습니다.
스웨거를 사용하기 위해 의존성을 추가하고 Main 애플리케이션에 @EnableSwagger2 애노테이션과 Docket 빈을 추가합니다.
1 2 3 4 5 6 7 8 9 10 | <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger2</artifactId> <version>2.7.0</version> </dependency> <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger-ui</artifactId> <version>2.7.0</version> </dependency> | cs |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | @Bean public Docket api() throws IOException, XMLPullParserConfiguration { MavneXpp3Reader reader = new MavenXpp3Reader(); Model model = reader.read(new FileReader("pom.xml")); ApiInfoBuilder builder = new ApiInfoBuilder() .title("Person Service Api Documentation") .description("Documentation automatically generated") .version(model.getVersion()) .contact(new Contact("Piotr Minkowski", "piotrminkowski.wordpress.com", "hyyg123@gmail.com")); return new Docket(DocumentationType.SWAGGER_2).select() .apis(RequestHandlerSelectors.basePacakge("pl.pimin.services.boot.controller")) .paths(PathSelectors.any()).build() .apiInfo(builder.build()); } | cs |
애플리케이션이 시작될 때 스웨거에 의해 API 문서가 자동으로 생성됩니다.
API 문서 대시보드는 /swagger-ui.html 에서 확인할 수 있습니다.
이러한 것들은 Main에 등록된 Docket 빈에 의해 처리되며,
APi의 타이틀, 저자, 설명 같은 속성을 설정할 수 있습니다. 또한 패키지 별로 설정이 가능합니다. (예제에서는 pl.pimin.services.boot.controller)
스웨거 UI를 통한 API 테스트
또한 스웨거 UI를 통해서 포스트맨(API 테스트 도구)과 유사하게 API 테스트를 할 수 있습니다. 자세한 내용은 생략하겠습니다.
스프링 부트 액추에이터의 기능
마이크로서비스에서는 애플리케이션의 모니터링과 메트릭 수집이 중요합니다.
이를 위해 스프링 부트에서는 스프링 부트 액추에이터를 지원합니다.
스프링 부트 액추에이터는 모니터링과 상호작요을 하기 위한 내장된 수 많은 API를 제공합니다.
스프링 부트 액추에이터를 사용하기 위해서는 spring-boot=starter-actuator 의존성을 추가해야 합니다.
다음은 몇 개의 API 목록입니다.
비활성화 방법은 application.yml에 다음과 같이 추가합니다.
1 2 3 | management : security : enabled : false | cs |
애플리케이션 정보
/info API를 통해 호출합니다. 기본적으로 어떤 정보도 노출하지 않으므로 InfoContributer 빈을 변경하거나 자신만의 빈을 작성해야 합니다.
EnvironmentInfoContributor는 환경 정보를 노출합니다.
GitInfoContributor는 git.properties를 통해 브랜치 이름이나 커밋ID와 같은 커밋 정보를 노출합니다.
(git-commit-id-plugin을 pom.xml에 추가해야 합니다.)
BuildInfoGontributor는 META-INF/build-info.properties 정보를 통해 API를 노출합니다.
(spring-bood-maven-plugin을 수정해 build-info.properties를 자동 생성하도록 해야 합니다.)
상태 정보
/health API를 통해 호출합니다.
디스크 사용량, 메일 서비스, JMS, 데이터 소스, 몽고디비 또는 카산드라와 같은 NoSQL 등을 모니터링 할 수 있습니다.
매트릭스
/metrics API를 통해 호출합니다.
로딩된 클래스의 개수, 활성화된 스레드의 수, API 메서드의 평균 실행 시간 등을 표시합니다.
CountService와 GaugeService를 통해 자신만의 메트릭을 생성할 수 있습니다.
CountService는 값의 증가와 감소, 초기화를 위한 메서드를 제공합니다.
GaugeService는 단순히 현재의 값을 전달하는 메서드를 제공합니다.
모든 메트릭은 분석하거나 표시할 수 있는 저장소로 전달이 가능합니다.
레디스(Redis), Open TSDB, Statsd, 인플럭스디비 등에 저장하여 활용할 수 있습니다.
이러한 문서화, 메트릭, 상태 점검은 마이크로서비스를 개발하고 유지보수하는데 매우 중요한 역할을 합니다.
개발자 도구
spring-boot-devtools 의존성을 추가하면, 소스 파일 변경사항을 감지하여 자동으로 반영해줍니다. (마치 jrebel과 비슷하게 작동합니다.)
| 4장 서비스 디스커버리 (0) | 2019.02.01 |
|---|---|
| 3장 스프링 클라우드 개요 (0) | 2019.01.23 |
| 1장. 마이크로서비스 소개 (0) | 2019.01.22 |
'마스터링 스프링 클라우드' 책을 통해 배운 것들을 설명하겠습니다.
총 15장의 단원이 있는데 일반적으로 장당 글 하나씩 쓰도록 할 것입니다.
그럼, 1장을 다같이 공부해볼까요~?
| 4장 서비스 디스커버리 (0) | 2019.02.01 |
|---|---|
| 3장 스프링 클라우드 개요 (0) | 2019.01.23 |
| 2장 마이크로서비스를 위한 스프링 (0) | 2019.01.22 |
