티스토리 뷰
이제 본격적으로 Spring Cloud Bus를 활용하기에 앞서 몇가지 설정을 해주려 합니다.
바로 시작하겠습니다.
#BootStrap.yml( User,Config,Gateway )
먼저 저번시간에 진행했던 Native Profile로 세가지 서비스를 모두 맞춰줍니다.
profiles를 active 시켜주세요!
spring:
cloud:
config:
uri: http://127.0.0.1:8888
name: config-service
profiles:
active: native
#pom.xml(Config-Service)
먼저 Config-Service의 pom.xml 파일에 Dependency를 추가합니다.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
#pom.xml(User-Service,ApiGateway-Service)
마찬가지로 User-Service와 ApiGatewayService에서도 종속성을 추가해줍니다.
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
#application.yml(Config-Service)
그리고 application.yml파일을 수정합니다. 추가해야하는 부분은 RabbitMQ와 Management에서 End 포인트를 설정해줘야한다.
server:
port: 8888
spring:
application:
name: config-server
rabbitmq:
host: 127.0.0.1
port: 5672
username: guest
password: guest
cloud:
config:
server:
git:
uri: https://github.com/ggpark9703/spring-cloud-config.git
# uri: D:\git-local-repo
# username:
# password:
management:
endpoints:
web:
exposure:
include: health, busrefresh
#application.yml(User-Service,ApiGateway-Service)
마찬가지로 위에서 추가한 내용을 User-Service와 ApiGateway-Service에도 추가해줍니다.
rabbitmq:
host: 127.0.0.1
port: 5672
username: guest
password: guest
User-Service와 ApiGateway-Service에는 endpoint가 셋팅이 되어있기 때문에 busrefresh만 추가해줍니다.
#연동 Test
자 이제 잘 만들었다면, 테스트를 해야합니다. 프로젝트 실행 후 ( Rabbit MQ와 관련이 있는 프로젝트) 콘솔창을 보면 다음과 같이 RabbitMQ와 관련된 정보가 잘 출력된다면, 성공 입니다.
#Spring Cloud Bus Test
다음으로는 이어서 바로 Spring Cloud Bus를 테스트 해보려 합니다. 일단 관련된 프로젝트를 모두 실행시켜 줄게요.
Eureka-Server( Ecommerce ) Service( Gateway,User,Config ) 를 실행 시켜주 준 뒤 회원 등록부터 진행해줍니다.
등록이 성공적으로 완료가 됐다면, 로그인을 진행해줍니다.
토큰 값을 복사해주세요! 이제 Health_Check를 해줍니다.
Native Token을 잘 참조하는 걸 알 수 있네요. 그럼 해당 토큰값을 조금만 수정해줄까요?
#application.yml(NATIVE-FILE-REPO)
token:
expiration_time: 864000000
secret: user_token_application_native_changed
gateway:
ip: 0.0.0.0
changed를 붙혀주도록 할게요.
그럼 정상적으로 바뀐게 적용이 됐는지 부터 확인해줄까요?
http://127.0.0.1:8888/config-server/default 로 접속해 token정보가 바뀌었는지 확인해줍니다.
하지만 Health_Check를 다시 입력해 확인해본다면...
값이 그대로 입니다... 서비스에 정보가 갱신이 되지 않아서 그런건데, 기존에는 refresh를 통해서 갱신했던 것 기억나시나요?
이번엔 조금 다릅니다.
http://127.0.0.1:8000/user-service/actuator/busrefresh 로 접속해줍시다. 다음과 같이 204 No Content가 상태코드로 반환된다면 성공입니다.
Console을 확인해보면 User-Service,Gateway-Service 에서 각각 다음과 같은 메시지가 출력되는 것을 볼 수 있습니다.
Refresh가 성공적으로 이루어졌다는 의미입니다!.
DiscoveryClient_USER-SERVICE/user-service:f8fdd95363521674d4ed5eab7a5f2aed - registration status: 204
DiscoveryClient_APIGATEWAY-SERVICE/localhost:apigateway-service:8000 - registration status: 204
이게 어떤 의미인줄 아시나요...? 기존에는 User-Service와 Gateway-Service를 각각 Refresh를 해줘야했던 반면... SpringCloudBus를 활용하면 한번의 Refresh로 관련되어 있는 서비스를 모두 Refresh 시켜줍니다. 편의성이 말도 안되게 증가한거에요. 원래는 서비스가 100개라면 100번 Refresh를 해줘야 했던 반면, Bus를 활용하면 한번에 모든 서비스를 Refresh 해줍니다.
로그인을 다시 진행해주시구, 다시 바뀐 토큰값으로 인증을 통해 Health_Check를 해볼게요
Bearer Token값은 변경됐으니! 반드시 재 로그인 후 새로 발급 받은 토큰으로 인증을 진행해야 합니다!!
token.secret 값이 changed로 바뀐것을 볼 수 있습니다.
사실 오늘 진행한 과정을 보면 Spring Cloud Bus를 왜 쓰는지 단번에 이해돼셨을 거라 생각이 듭니다.
그리고 이건 오피셜은 아니고 제가 생각하는 방식인데, 개발의 속도의 증진을 위해서 Native Repository 와 Spring Cloud Bus방식으로 먼저 1차 개발을 진행하고 본인이 맡은 파트의 개발이 끝나면 Git으로 변경해 Commit 하는 방식을 채용하면, 작업 효율이 증가 할 것 같습니다.
감사합니다.
#AMQP
그전에 사실 AMQP의 개념에 대해서 설명했어야 했는데, 저는 실습위주로 글을 작성하고 있어서 개념같은건 배우면서 느낀다고 생각하는 편이지만 해당 개념은 짚고 넘어 가겠습니다. 이론적인 부분이니 그냥 넘어가도 되시는 부분입니다.
하지만 실제로 Spring Cloud Bus가 어떻게 동작하는 지 알았으니 사실은 이미 몸은 익혀진 상태이기에 조금 더 와닿으실 겁니다.
AMQP란? (Advanced Message Queuing Protocol)의 약자로 쉽게 말하면 큐잉 프로토콜 입니다.
AMQP는 일단 크게 4가지로 나뉩니다. ( Publisher, Exchange, Queue, Consumer )
자 우리가 실습한 내용을 바탕으로 설명해 보자면
Pulisher는 클라이언트 개념입니다. 저희가 Url를 입력해 해당 주소로 이동하는 요청을 Publisher라고 보면 됩니다.그리고 Exchange는 요청을 받는 지점입니다. 그리고 해당 요청을 Queue에 전부 뿌려주는데 생각해보면, BusRefresh를 통해서 업데이트를 했었죠? 그러니 Service를 Queue라고 보면 쉬울거에요. 이런 흐름으로 다시 Consumer ( 응답 값 ) 에 메시지를 전달합니다.
이러한 흐름이기 때문에 한번의 요청으로 모든 서비스가 갱신이 될 수 있었던 겁니다. 사실 이런 개념적인 부분을 잘 몰라도 한번 실습해보셨다면, 느낌을 잡는데는 충분하지 않았나 생각이 듭니다.
'웹 프로그래밍 > MSA 학개론' 카테고리의 다른 글
[MSA Part2] 비대칭키를 이용한 암호화 처리를 통한 고도화 작업 (0) | 2022.04.26 |
---|---|
[MSA Part2] 대칭키를 이용한 암호화 처리를 통한 고도화 작업 (0) | 2022.04.26 |
[MSA] Native File Repository 핥아먹기 (0) | 2022.04.26 |
[MSA]Spring Cloud Bus을 이용한 Configuration 설정 ( Rabbit MQ, Elrang ) -0- (0) | 2022.04.25 |
[MSA] 잠깐 쉬어가는 Remote Git Repository (Config - Service) (0) | 2022.04.25 |
- Total
- Today
- Yesterday
- prometheus
- UserService
- 루틴기록
- Logstash 활용
- rabbitmq
- 빅-오
- 운동
- MariaDB
- consumer
- 오늘저녁 삼겹살
- github
- Kafka Connect
- MSA
- zipkin
- Gateway
- config
- JWT
- 미래의나에게동기부여
- LoadBalancer
- Feign
- Logstash to ElasticSearch
- ACTUATOR
- producer
- elasticSearch
- docker
- 운동일기
- springcloud
- git
- Spring + ELK
- kafka
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 28 | 29 | 30 | 31 |