오늘의 중요 일정 1:1 면담 후기
다양한 질문들이 오갔는데
si 개발에 같이 공감해 주시고 회사생활 관련 조언도 해주셨다.
TIL은 시행착오 위주로, 어떤 이슈가 발생했고 어떻게 해결해 나갔는지 적는 것이 메리트가 된다고 한다!
알고리즘 문제는 최대한 많이 풀어보기 ㅎ!
스프링 심화 강의가 남아있지만 내배캠 일정에 맞게 MSA 먼저 듣기로 결정했다.
MSA란?
MSA는 프로젝트때 잠깐 경험해 본 적이 있다.
직접 설계를 해 본 것은 아니라 MSA 경험이 있어요!라고 자신 있게 말할 수 있진 않다.
이미 설계된 곳에서 개발을 해 본 정도?
내가 아는 MSA 개념은 서비스별로 프로젝트가 분리되어 있다! 정도 알고 있다
이제 배운 내용을 정리해 보자.
MSA란 Microservices Architecture로 하나의 애플리케이션을 독립적인 여러 개의 서비스로 나누는 아키텍처 스타일이다.
MSA를 사용하면 설계의 복잡성이 증가하지만 독립적인 배포가 가능하여 유지보수에 용이하다.
반대되는 개념을 모놀리틱 아키텍처라고 한다.
보통 이 아키텍처 방식을 많이 사용하는 것 같다.
모놀리틱 아키텍처란(Monolithic Architecture, MA) 하나의 통합된 코드 베이스로 구성되어 있으며, 모든 기능이 하나의 애플리케이션에 포함된다. 설계와 배포가 간편하다는 장점이 있지만 새로운 기술을 도입하기 어려워 기술 유연성이 낮다는 단점이 있다.
MSA와 MA의 괜찮은 비교 글이 있어 공유한다.
https://www.inflearn.com/pages/infcon-2023-tech-msa
Spring Cloud란?
우선 Spring Cloud란 MSA를 쉽게 구현하고 운영할 수 있는 스프링 프레임워크의 확장이다.
그림으로 스프링 클라우드 이해하기
새로 배우는 개념이 많아서 열심히 강의 내용을 적어보았다.
Ribbon(로드 밸런싱)
이용자 및 서비스가 활발해져서 상품서비스가 두 개 있다고 가정하자.
주문 -> 상품 확인 순서일 때
order 서비스가 product 서비스를 호출하면
두 product 서비스 중 어디로 가야 할지 결정하는 것이 Ribbon이고 실제 호출은 Feign Client에서 이뤄진다.
Eureka(서비스 등록 및 디스커버리)
각 서비스의 호스트를 관리해 준다.
API 게이트웨이
서로 다른 app을 호출할 때 매번 다른 호스트를 호출해야 하는 번거로움이 있는데
API 게이트웨이가 이 번거로움을 해결해 준다.
api게이트웨이로 엔드포인트를 호출하면 api게이트웨이에서 엔드포인트를 보고 알맞은 서비스 요청이 가능하다.
Zipkin(분산 추적)
Order -> Product -> User
서비스에서 서비스로의 이동이 직관적이지 않은데 이는 분산추적을 통해 알아볼 예정이다.
그 외
진행할 프로젝트의 설계는 그림으로 도식화하는 과정 필요하다.
snapshot - 개발 중인 버전 (안전성에 유의, 웬만하면 사용 x)
ga - 정식 릴리즈 버전 (안정화된 버전)
오늘의 tmi)
내배캠에서 제공해 준 강의 중 msa 강의 강사님의 수업 스타일이 나랑 제일 잘 맞는 거 같다. 귀에 쏙쏙 들어옴
우리 조원들 다들 열심히 한다. 나만 잘하면 될 듯!
'TIL' 카테고리의 다른 글
[TIL] Zipkin이란? | Redis란? (0) | 2024.08.06 |
---|---|
[TIL] QueryDsl 사용방법 (0) | 2024.08.06 |
[TIL] 인증과 인가 | 컨피그 서버 (Spring Cloud Config) (0) | 2024.08.02 |
[TIL] Java 형변환 | Integer.parseInt와 Integer.valueOf의 차이 | Math.sqrt()와 Math.pow() | 클라이언트 사이드 로드 밸런싱 | 서킷 브레이커 (Resilience4j) | Spring Cloud Gateway (1) | 2024.08.01 |
[TIL] @Data vs @Getter, @Setter | Building Result란? | CreatedAt UpdatedAt null 해결 (0) | 2024.07.31 |