Spring MSA 프로젝트에서 단일 책임 원칙을 지키기 위한 리팩토링
·
MSA
Spring MSA 프로젝트에서 단일 책임 원칙을 지키기 위한 리팩토링 우리팀은 MSA프로젝트에서 분산추적을 위해 Zipkin을 적용했다. 여기서 서버간 추적을 공유하기 위해서는 TraceId를 공유해야 한다는 것을 알게되었고 이에 SNS 메시지를 발행할때 snsClient.publish()메서드의 인자로 넣어주는 json 데이터에 TraceId도 포함해서 보내도록 로직을 수정했다. 이렇게 잘 사용하다가 우리는 코드 리뷰를 진행했는데 이때 평양냉면님이 이것은 단일 책임 원칙을 어기는것이 아닌가? 라는 질문을 해서 같이 이에대한 토론을 해본 결과 리팩토링을 진행하는것이 좋겠다고 결론이 나와 리팩토링을 진행했다. 오늘 포스트에서는 그 내용을 소개하고자 한다. Zipkin 설정을 했던 내용이 궁금하다면? ⬇️..
SpringBoot MSA 로깅: Zipkin을 사용한 분산 추적에서 예외상황을 다루는 방법
·
MSA
이번 포스트에서는 저번 포스트에서 설명하지 못했던 서버 간 통신에서 예외가 발생했을 때는 Zipkin 추적을 어떻게 할지 설명한다. 1. Zipkin 예외처리를 위해 @SqsListener 메서드 분석하기 1-1. 레시피 서버의 @SqsListener 메서드를 다시 한번 확인해 보자 이전 포스트부터 기록해둔 SqsListener 코드에는 이미 try-catch-finally가 되어있는데 이건 추적에 대한 예외처리가 완료된 상황의 코드다. 이렇게 포스트를 작성한 이유는 모든 동작에 이상이 없는 것을 확인하고 블로그에 글을 작성했더니 예외처리가 된 채로 코드를 캡처해서 글을 작성하게 되어버렸다. 1-2. Zipkin추적의 예외처리가 적용될 try-resource문법 여기서 중요한 부분은 catch문이다. 만..