종우의 삶 (전체 공개)

Spring에는 Bean의 동작 원리나, Spring에서의 의존성, IoC, DI등 중요한 사항들이 있다. 면접에서 이러한 것들을 수월하게 대답할 수 있도록 준비해보는 시간을 가져보자.1. IoC프로그램의 제어 흐름을 개발자가 아닌 프레임워크가 관리하는 디자인 패턴이다. (그래서 역전)객체간의 결합도를 낮추고 유연하고 확장성이 큰 프로그램을 만든다.Spring 컨테이너가 애플리케이션의 객체 생성, 관계 설정, 생명주기를 관리함.코드의 재사용성이 증가하고, 객체 간 결합도가 감소하고, 모듈화 되고 테스트가 쉬워진다.@Autowired, @Component같은 어노테이션으로 구현 2. DI의존성 주입객체가 필요로 하는 의존성을 외부에서 주입하는 기술.객체 간의 결합도를 낮추고 코드의 재사용성을 높인다.생성자..

동시성 처리에 사용했던 Redisson에 대해 좀 더 알아보기로 하였다. 어쨌든 내가 사용한 기능을 파악하는 것은 중요하니까.https://github.com/redisson Redisson 깃허브에 위키 파일이 있다. 좋다. 실제 사용하는 방법에 대해 주로 작성되어 있다. RedissonEasy Redis Java client and Real-Time Data Platform - Redissongithub.com Redisson과 Redis애초에 Redisson은 Redis를 위한 Java 클라이언트 라이브러리이다.Redis는 잘 알다시피 인메모리 데이터 구조 저장소로, 분산 캐시, 메시지 브로커, 큐 등 다양한 용도로 사용된다.Redisson은 이러한 Redis의 기능을 Java 어플리케이션에서 쉽게..

기존의 테스트가 로그도 부실하고 쓸모없는 체크과정이 많아서 좀 변경해보았다. Controller에서는 간단한 로깅만 실시하고Service 쪽에서 더 상세한 로그를 나누어 보았다. @Transactionalpublic OrderResponse createTimeOrder(Long customerId, Long productId, Long quantity) { log.info("주문 시작 - CustomerId: {}, ProductId: {}, Quantity: {}", customerId, productId, quantity); if (stockExhausted.get()) { log.warn("재고 소진 - CustomerId: {}, ProductId: {}", customer..

예약 구매 시나리오에 맞게, 특정 시간에 많은 주문이 몰리게되는 테스트를 진행했다.  주어진 상황특정 시간에 상품이 오픈되면 한정된 재고 (eg. 10개) 를 1만명이 구매하려한다.구매, 결제 과정에서 20% 는 이탈하게 되고, 그 재고도 다시 반영하여 구매자들에게 제공되어야한다. 대충 이런 형태인데, 기존에 만들었던 로직과는 좀 다른 느낌이어서 새로운 API로 만들어 보았다.  @Slf4j@Service@RequiredArgsConstructorpublic class TimeOrderService { private final ProductClient productClient; private final PaymentClient paymentClient; private final Order..

프로젝트 진행 과정에 발생한 트러블 슈팅을 정리해본다. 프로젝트 진행 중에 있던 내용으로, 최종 프로젝트 상태와 문제 발생 당시의 상태는 다를 수 있음. 증상 : 회원 가입 로직을 진행할 때, 입력한 메일 주소로 인증 메일을 보낸다.그리고 링크를 클릭하면 회원가입이 정상적으로 완료되는 형태이다. 링크를 클릭한 순간 DB에 정상적으로 회원의 데이터가 저장이 된다. 회원 가입시 필요한 데이터는 다음과 같이 입력한다.{ "customerName": "testname", "password": "1234", "email": "test@email.com", "address": "무명도 무명시 도로명주소", "addressDetail": "0000호"} 링크를 클릭하면, 입력받은 데이터를 ..

MSA로 전환하면서 간단한 아키텍처 다이어그램을 다시 그려보았다. 기본적인 로직은 아래와 같다. 이전 포스트에서 설명했다시피 Eureka로 묶인 서비스들은 API Gatway로 들어온 요청들을 처리하게 된다. 그 과정에서 서로의 서비스를 불러오고, 다른 서비스의  DB를 조회해야 할 필요가 생긴다. Kafka를 고려하기도 했지만, 요청을 보내고 반드시 응답이 돌아와야 다음 로직이 가능하기 때문에 Kafka와 같은 메시지 브로커는 적합하지 않다고 생각했다.이러한 단순한 데이터 전송은 동기적으로 처리되어야 한다. 그래서 간단한 Feign Client를 사용하여 서비스 간 통신을 진행해보았다. 사례 1) 특정 상품을 주문에 추가하려 할 때이러한 상황이 주어졌다고 생각해보자. 주문을 하기 위해서는 우선 상품을 ..

0. 모놀리식으로 개발중인 현재 프로젝트를 어떻게 분리하고 MSA로 변경할 수 있을까?가장 중요한 사안은 서비스 분리가 수월하도록 각 서비스와 계층간 의존성을 낮춰야 한다는 것이다. MSA에 대해 알아보기Monolithic Architecture지금까지 개발해왔던 형태를 모놀리식 아키텍쳐라고 할 수 있겠다. 하나의 프로젝트에 모든 서비스와 기능들이 들어가있다. 모듈 단위로 쪼개지는 것이 아니라 프로젝트 단위로 개발이 진행되는 것.  현재 회원, 주문, 상품 등의 서비스가 존재한다면 계속해서 기능들이 추가 될 때마다 프로젝트 내의 코드의 양이 점점 증가할 것이다. 모놀리식의 장점이자 단점이 필요한 기능이 전부 한 곳에 모여있는 것인데, 초기 개발에 적합하여 빠르게 MVP를 만들 수 있지만 프로젝트의 크기가..

* 따로 정리하던 내용들을 하나씩 블로그로 작성함.* 현재 진행중인 MSA 관련 프로젝트에서, 어떤 것들을 진행하고 있는지 살펴보자. * 모놀리식 구성과 이후  MSA의 형태는 약간 다르다. 각각의 단계에서 어떤 것들을 구현하였는지 정리하였다. MSA를 도입하기 전, 우선 하나의 프로젝트를 구성사실 MSA에 대한 큰 고려를 하지 않고 늘 하던대로 하나의 프로젝트를 구성하였는데, 이후 서비스를 분리하여 구성할 때 분리 자체가 어려운 부분이 있었다. 그건 나중의 이야기이므로 현재의 상황을 살펴보자 Customer, Product, Order 3개의 커다란 서비스를 중심으로 세부적인 내용들을 조정하였다. 주요 서비스 외에도 Security, Redis, Api응답을 위한 일반적인 서비스들도 존재한다. Cust..