생략상품을 주문하는 프로세스로 가정하고, 일반적인 웹 애플리케이션에서 Controller -> Service -> Repository로 이어지는 흐름을 최대한 단순하게 만들어보자.
어플리케이션이 점점 커질수록 병목이 자주 발생하게 되는데,병목이 어디서 발생하는지 빠르게 알기위해 로그를 남기는 것이 점점 중요해지고 있다.로그를 자동화하는 방법을 알아보자.예시모든 Public 메서드를 출력메서드 호출에 걸린 시간정상과 예외의 구분흐름을 길이로 표현(
애플리케이션의 모든 로직에 직접 로그를 남겨도 되지만, 그것보다는 더 효율적인 개발 방법이 필요하다.특히 트랜잭션ID와 깊이를 표현하는 방법은 기존 정보를 이어 받아야 하기 때문에 단순히 로그만 남긴다고 해결할 수 있는 것은 아니다.요구사항에 맞추어 애플리케이션에 효과
트랜잭션ID와 메서드 호출의 깊이를 표현하는 가장 단순한 방법은 첫 로그에서 사용한 트랜잭션ID와 level을 다음 로그에 넘겨주면 된다.이 기능을 포함한 V2를 개발해보자HelloTraceV1에서 이 메서드만 추가되었다.쉽게 말해 처음 만들때는 new를 이용해 Tra
바로 이전에 했던 로그 추적기에는 문제가 있다.트랜잭션ID를 맞추기 위해 파라미터로 TraceId를 넘겼는데,이렇게 넘기는 방식은 로직에 관여를 해야 하기 때문에 좋지 않은 방법이다.TraceId 를 파라미터로 넘기지 않고 이 문제를 해결할 수 있는 방법이 있을까?Fi
쓰레드 로컬은 해당 쓰레드만 접근할 수 있는 특별한 저장소를 말한다. 쉽게 이야기해서 물건 보관 창구. 여러 사람이 같은 물건 보관 창구를 사용하더라도 직원은 사용자를 인식해서 사용자별로 확실하게 물건을 구분.FieldService에서 밑줄 친 부분만 바꾸고 나머지는
이전에 로그 추적기를 만들었고, 파라미터를 넘기는 불편함을 없애기 위해 쓰레드 로컬을 도입했다.로컬 추적기 도입 전과 후를 비교해보자.도입 전 도입 후try-catch가 붙다보니 양이 엄청 많고 복잡하다.핵심 기능 vs 부가 기능핵심 기능은 해당 객체가 제공하는 고유의
이전 테스트만 그대로 가져왔다.전략 패턴을 통해 해결해보자.전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다. 상속이 아니라 위임으로 문제를 해결하는
ContextV2 는 변하지 않는 템플릿 역할을 한다. 그리고 변하는 부분은 파라미터로 넘어온 Strategy 의 코드를 실행해서 처리한다. 이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백(callback)이라 한다.콜백이란프로그래밍에서 콜백(callba
proxy-start 를 proxy로 변경예제는 크게 3가지 상황으로 만든다.v1 - 인터페이스와 구현 클래스 - 스프링 빈으로 수정 등록v2 - 인터페이스 없는 구체 클래스 - 스프링 빈으로 수동 등록v3 - 컴포넌트 스캔으로 스프링 빈 자동 등록실무에서는 스프링 빈
V1에 LogTrace를 사용해보자.프록시를 사용하면 기존 코드를 전혀 수정하지 않고 로그 추적 기능을 도입할 수 있다.V1 기본 클래스 의존 관계V1 런타임 객체 의존 관계여기에 프록시를 추가한다면,Controller, Service, Repository각각 인터페이
이전에 프록시를 사용해서 코드를 손대지 않고 진행할 수 있게 되었지만, 하나의 코드당 하나의 프록시를 일일이 만들어야 하는 불편함이 존재했다.자바가 기본으로 제공하는 JDK 동적 프록시 기술이나 CGLIB 같은 프록시 생성 오픈소스 기술을 활용하면 프록시 객체를 동적으
이전에서 말했듯이 프록시는 클래스 개수만큼 만들어야 한다는 불편함이 있었다.쉽게 이야기해서 프록시의 로직은 같은데, 적용 대상만 차이가 있는 것이다.이 문제를 해결하는 것이 동적 프록시이다.동적 프록시 기술을 사용하면 개발자가 직접 프록시 클래스를 만들지 않아도 된다.
CGLIB: Code Generator LibraryCGLIB는 바이트코드를 조작해서 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리이다.CGLIB를 사용하면 클래스여도 동적 프록시를 만들어낼 수 있다.참고로 우리가 CGLIB를 직접 사용하는 경우는 거의 없다.나
이전의 경우, 인터페이스를 사용할때는 InvocationHandler,클래스를 사용할때는 MethodInterceptor를 사용하여 프록시를 적용하여 공통 로직 부분을 처리할 수 있었는데,인터페이스와 클래스가 혼합해서 사용하는 경우가 많기 때문에 이를 둘다 사용해야한다
빈 후처리기기 - BeanPostProcessor스프링이 빈 저장소에 등록하기 직전에 조작하고 싶다면 빈 후처리기를 사용하면 된다.후 처리 작업빈 후처리기는 전달된 스프링 빈 객체를 조작하거나 다른 객체로 바꿔치기 할 수 있다.일반적인 스프링 빈 등록 과정을 먼저 봐보
다음을 꼭 추가해줘야 한다.이 라이브러리를 추가하면 aspectjweaver라는 aspectJ 관련 라이브러리를 등록하고, 스프링 부트가 AOP 관련 클래스를 자동으로 스프링 빈에 등록한다.스프링 부트가 없던 시절에는 @EnableAspectJAutoProxy를 직접
스프링 어플리케이션에 프록시를 적용하려면 포인트컷과 어드바이스로 구성되어 있는 어드바이저(Advisor)를 만들어서 스프링 빈으로 등록하면 된다.그러면 나머지는 자동 프록시 생성기가 알아서 해준다.스프링은 @Aspect 어노테이션으로 매우 편리하게 포인트컷과 어드바이스
어플리케이션 로직은 크게 핵심 기능과 부가 기능으로 나눌 수 있다.핵심 기능해당 객체가 제공하는 고유의 기능. 예를 들어서 OrderService의 핵심 기능은 주문 로직이다.부가 기능핵심 기능을 보조하기 위해 제공되는 기능. 예를 들어서 로그 추적 로직, 트래냊ㄱ션
implementation 'org.springframework.boot:spring-boot-starter-aoptestCompileOnly 'org.projectlombok:lombok'testAnnotationProcessor 'org.projectlombok:l
애스펙트J는 포인트컷을 편리하게 표현하기 위한 특별한 표현식을 제공한다.포인트컷 표현식은 execution같은 포인트컷 지시자로 시작한다. 줄여서 PCD라 한다.종류execution: 메서드 실행 조인 포인트를 매칭한다. 스프링 AOP에서 가장 많이 사용하고, 기능도
@Trace 어노테이션으로 로그 출력하기@Retry 어노테이션으로 예외 발생시 재시도 하기5번마다 1번은 예외가 발생하도록 만들었다.@Trace 를 만들어보자.@Retry 어노테이션이 있으면 예외가 발생했을 때 다시 시도해서 문제를 복구한다.value를 설정하지 않으면
스프링은 프록시 방식의 AOP를 사용한다.그렇기 때문에 AOP를 적용하려면 항상 프록시를 통해서 객체를 호출해야한다.만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않는다.AOP를 적용하면 스프링은 대상 객체 대신에 프록시를 스프링 빈으로