시작이 반

각 서비스는 해당 주소와 포트번호가 다를 것이다. 이러한 마이크로 서비스들은 Discovery Service에 저장된다 외부에서 다른 서비스들이 마이크로 서비스를 검색하기 위해 사용되는 개념이며 전화번호 책과 같은 느낌이다. 각각의 마이크로 서비스가 어디에 누가 저장되어있으며 요청정보가 들어왔을때 요청정보에 따라서 필요한 서비스의 위치를 알려주는 역할 등록/검색을 해주는 것을 Discovery Service라고 하며 Eureka를 통해 구현이 가능하다. Eureka Service Discovery - Project 생성 Java는 11버전 Spring boot 버전은 2.4.x 버전을 사용했다. Eureka server 디펜던시 추가 application.yml ( application.propertie..

Spring Cloud? Microservice의 개발, 배포, 운영에 필요한 아키텍처를 구성할 수 있게 도와주는 Spring Boot 기반 Framework이다. Spring Cloud에는 많은 기능이 있지만 이번 실습을 따라하면서 사용할 기술들은 위의 사진과 같다. 실습 개요 Eureka : service discovery역할 유레카 서비스를 유레카 서버에 등록 ( ip, port ) netflix ribbon, zuul, spring cloud gateway : api gateway역할 클라이언트가 api gateway를 통해 필요한 서비스 요청 -> 서비스 라우터에게 어디로 가야할지 질문 -> 필요한 마이크로서비스가 어디있는지 service discovery에 물어봄 -> 서비스가 여러개의 형태로..

Monolith vs Microservice Monolith - 어플리케이션을 개발함에 있어서 모든 요소를 하나의 커다란 소프트웨어에 포함 하나의 큰 건축물(?) 분리를 못한다. Microservice - 어플리케이션을 구성하는 각각의 구성요소를 분리하여 개발하고 운영한는 방식 - 기능들이 독립적이고 최소화 되어있기 때문에 유지보수, 변경사항 적용하는데 유리 - 비지니스기능으로 구축되고 자동화된 배포시스템을 사용 CI/CD 각기능을 하는 레고들이 모여서 하나의 어플리케이션이 되는것이라고 생각하자 amazon 과 NETFLIX의 Microservice 예시 하나의 점이 모두 마이크로 서비스이다. 이러한 서비스들이 모두 연결되어 하나의 어플리케이션을 구성한다. Microservice의 특징 Challenge..

MSA에 대해 포스팅 하기 전에 Cloud Native에 대해 알아보자 Cloud Native Architecture 특징 확장 가능한 아키텍처 시스템의 수평적 확장 시스템 부하 분산, 가용성 보장 서비스 어플리케이션 단위 패키지 (컨테이너 기반 패키지) 모니터링 탄력적 아키텍처 어플리케이션의 각기능을 서비스로 생성 - 통합 - 배포을 CI/CD자동화 파이프라인을 통해 처리, 환경 변화 대응시간 단축 작게 분리된 독립적인 서비스들이 분할된 구조 무상태 통신 프로토콜, 종속성 최소화 서비스 추가와 삭제 자동으로 감지 변경된 서비스 요청에 따라 사용자 요청 처리 (동적 처리) 장애 격리 특정 오류가 나더라도 다른 서비스에 영향을 주지 않는다. Cloud Native Application CI/CD - 지속적..

OSIV ON 최초 데이터베이스 커넥션 시작부터 API응답이 끝날 때 까지 영송성 컨텍스트와 데이터베이스 커넥션 유지 만약 Controller에서 외부 API를 호출하면 API대기 시간만큼 커넥션 리소스 반환 못함 - 자원낭비 OSIV OFF 트랜잭션을 종료할 떄 영송성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환 - 리소스 낭비x 지연로딩을 트랜잭션 안에서 처리해야함 OSIV를 끄면 컨트롤러에 있던 로직들을 서비스로 옮겨서 Transactional(readOnly = true)를 사용하여 로직을 사용한다. ex) OrderService OrderService: 핵심 비즈니스 로직 OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용) 고객 서비스의 실시간 AP..

페치 조인(fetch join)은 엔티티를 한번에 조회하게 최적화를 해준다. x To one 관계에서는 join fetch 를 해도되지만 one To many 에서는 Data 수가 many쪽에 맞춰 지면서 뻥튀기가 된다. public class Order { @Id @GeneratedValue @Column(name = " order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "member_id") private Member member; @OneToMany(mappedBy = "order", cascade = CascadeType.ALL) private List orderItems = new ArrayList(..

Table 정보 orders member delivery 찾을 api 정보 : orders @GetMapping("/api/v2/simple-orders") public List orderV2(){ //ORDER 2개 List orders = orderRepository.findAllByString(new OrderSearch()); List result = orders.stream() .map(o -> new SimpleOrderDto(o)) .collect(Collectors.toList()); return result; } 결과: api정보 @Data static class SimpleOrderDto{ private Long orderId; private String name; private Loc..

생각나는 것 정리... XToOne 일 경우에는 LAZY 설정을 해야 한다.!!!! 꼭 @XToOne (fetch = FetchType.LAZY) 양방향 연관 관계일 때 API로 호출이 된다면 무한루프가 일어날것이다. public class Order { @Id @GeneratedValue @Column(name = " order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "member_id") private Member member; } public class Member { @Id @GeneratedValue @Column(name = "member_id") private Long id; @OneToMany(..