지식 줍줍 🐿️

리액티브 프로그래밍

변화의 전파와 데이터 흐름과 관련된 선언적 프로그래밍 패러다임

• 변화의 전파와 데이터 흐름: 데이터가 변결될 때 마다 이벤트를 발생시켜서 데이터를 계속적으로 전달
• 선언적 프로그래밍: 실행할 동작을 구체적으로 명시하는 명령형 프로그래밍과 달리 선언형 프로그래밍은 단순히 목표를 선언.
• 데이터 발행(Observable), 가공(Operator), 구독(Subscribe) 흐름으로 구성
• 멀티스레딩 환경에서 둘 이상의 스레드가 하나의 변수를 사용하면서 발생하는 이슈를 방지하여 개발이 가능함. (stream..)

참고
https://www.youtube.com/watch?v=2McwNWO8MIw&list=PLr-ObTx8qMl9APSlvIhAah1mq3tyD1AYN

서버간 통신 중 지연 발생시 해결방법

    ‣ 네트워크 타임아웃 설정
    ‣ 대기중 요청수 제한
    ‣ 여러 부하 분산 기법 구현
    ‣ 서킷 브레이커 패턴과 폴백 구현 설정

부하 분산 룰(rule)

스프링 클라우드 넷플릭스에서는 다양한 부하분산 알고리즘을 제공해주는데,
넷플릭스OSS 에서는 해당 알고리즘을 룰이라고 함

종류

    ‣ RoundrobinRule
        → 라운드 로빈 사용, 유입되는 요청은 모든 인스턴스에 순차적으로 분산. 기본!

    ‣ AvailabilityFilteringRule
        → 세번 연결 실패하면 서킷 차단됨.
        → 서킷 차단 및 동시연결이 많은것으로 표시된 서버 제외.
        → RoundrobinRule 을 베이스 클래스로 사용.

    ‣ WeightedReponseTimeRule
        → 인스턴스로 전달되는 트래픽의 규모는 인스턴스의 평균 응답시간에 반비례.
        → 응답시간 길수록 더 작은 가중치 가짐.
        → 부하분산클라이언트는 모든 서비스 인스턴스의 트래픽과 응답시간 기록함.

    ‣ BestAvailableRule
        → 서킷브레이커가 차단된 서버를 제외하고 동시 요청을 가장 적게 받은 서버를 선택.

호버플라이 (Hoverfly)

설명

HTTP 서비스를 스텁하고 시뮬레이션하는 가벼운 시각화 도구.
DSL 정의에서 메서드 하나를 호출해 모든 시뮬레이션중인 서비스의 메서드에 지연을 쉽게 추가 가능.
    → maven or gradle 에 hoverfly-java import 필요, JUnit에 @ClassRule 정의 필요. 

실습

‣‣‣ 실습 코드 링크 🙂

• junit test 실행시 hoverflyRule 을 먼저 실행하고 각 테스트메소드를 실행한다. (ex. test() 실행)
• test() 메소드를 호출한 결과는 아래에 있다. ↓ ↓ ↓ ↓ ↓

※ https://www.baeldung.com/hoverfly 에도 잘 설명되어 있다. (사실 해당기능을 많이 쓰는지는 잘 모르겠다;)

리본(Ribbon)

설명

- Client LoadBalancer 이다.
- 개발자가 로드밸런싱 기능 구현을 가능하도록 한다. (L4 사용없이)
- 클라이언트 서버가 로드밸런싱을 한다! 
- 유레카랑 사용시 강력크하다 👍
- 더이상 업그레이드를 하지 않음.

※ 보통은 물리적으로 L4 switch 을 이용하여 로드밸런싱 처리를 할것이다.
이를 이용시 추가 서버비용 등이 발생할것이다.
이에따른 절차도 필요할것으로 보인다. 

실습 

‣‣‣ 실습 코드 링크 🙂

🔆 서버간 통신하여 로드밸런싱 처리 확인: Ribbon 적용 서버에서 Demo1 서버 호출 (포트를 여러개로 정의하여 서버띄우기)

• Ribbon 적용 서버

# .. gradle 파일 내 아래의 내용을 추가함 

implementation 'org.springframework.cloud:spring-cloud-starter-netflix-ribbon:2.1.4.RELEASE'

→ 빨간박스를 보면, demo1 으로 도메인을 정의해놓았다.
이는 application.yml 의 demo1: ribbon: listOfServers 정보를 호출하도록 한 것이다. (내부적으로 인터셉터 처리를 한다고함)

• Ribbon 적용 서버에서 호출할 서버 실행구성 

...그리고 테스트! (API 호출)
로드밸런싱 처리가 됨! 왔다갔다,, 서버별 API 호출 결과 로그를 확인할 수 있다.

히스트릭스 (Hystrix)

설명

- 분산시스템 내에서 서비스 간의 액세스 지점을 격리하고, 서비스 전반에 걸쳐 계단식 오류를 중지하고, 폴백 옵션을 제공하여 이를 수행
- RxJava 에 의해 만들어짐
- Failure as a First class citizen
   → 분산시스템에서는 실패를 1급 시민으로 간주.
- 더이상 업그레이드를 하지 않음. 

실습

‣‣‣ 실습 코드 링크 🙂

💥 서버(PirServer → Demo1Server 호출)간 통신 중, 에러발생 유도

1️⃣ Hystrix 미적용: 에러 노출 확인

2️⃣ Hystrix 적용: @HystrixCommand 및 fallback 적용

@HystrixCommand
- 메소드 호출시 메소드 실행 성공/실패 결과를 통계냄
- 통계에 따라 서킷 오픈 여부를 판단하고 조치함.

※ 서킷 오픈
주어진 시간동안 호출제한 / 에러반환 함
조기차단하여 본인을 보호함

- 정의해놓은 모든 메소드는 정해진 응답시간 내에 반환되어야 함. 그렇지 않으면 Exception 발생 & fallback 정의 수행

⭐️ Hystrix 보단 Resilience4j 을 사용하는것이 좋음.
- Resilience4j 가 Java8 지원 및 함수형 프로그래밍을 지원해준다고 함.

참고

책: 마스터링 스프링 클라우드
링크: https://www.youtube.com/watch?v=K4laj5cDYLg&list=PL9mhQYIlKEhdtYdxxZ6hZeb0va2Gm17A5&index=5 

서비스 디스커버리 (Service Discovery)

설명

서비스 클라이언트가 다른 서비스를 호출시, 서비스의 위치(IP, port) 를 알아낼 수 있는 기능
관련 오픈소스로 넷플릭스 OSS의 유레카(Eureka)가 존재!

유레카 (Eureka)

설명

서버가 새롭게 시작되면 그것을 감지하여 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법 ?!
유레카와의 통합을 위한 스프링 클라우드 라이브러리는 클라이언트와 서버 두부분으로 구성되어있다!

    ‣ 서버
      등록된 서비스의 목록을 수집하기 위한 API & 새로운 서비스를 네트워크 위치 주소와 함께 등록하기 위한 API 으로 구성
      각 서버의 상태를 다른 서버로 복제해 설정하고 배포함으로써 가용성 높일 수 있다!
      서비스의 각 인스턴스로부터 생존신호(heartbeat) 메시지를 받는다. 설정된 기간동안 생존신호를 받지 못하면 레지스트리에서 서비스가 삭제된다.

    ‣ 클라이언트 
      애플리케이션 시작 후 등록 & 종료 전 등록 해제를 담당하고 유레커 서버로부터 주기적으로 최신 서비스 목록을 받아옴!

실습

• eureka server 1개 (eureka server) , client server 2개 (demo1, demo2)

    ‣ eureka.client.service-url.defaultZone 에는 유레카 서버 여러개 설정도 가능하다

    ‣ @EnableDiscoveryClient: spring-cloud-commons에 존재
    ‣ @EnableEurekaClient: spring-cloud-netflix에 존재하며, 유레카만을 위해 작동

    ‣ spring-cloud-starter-eureka-server vs spring-cloud-starter-netflix-eureka-server : 차이없음. 근데 netflix 붙은것을 권장하는듯

참고

링크: https://bcho.tistory.com/1252

링크: https://stackoverflow.com/questions/49885718/difference-between-spring-cloud-starter-eureka-server-and-spring-cloud-starte

책: 마스터링 스프링 클라우드

스프링 클라우드 (Spring Cloud)

‣ 분산/버전관리, 서비스 등록 및 검색 가능, 라우팅, 서비스간 호출, 부하분산, 회로차단기, 분산메세지 등의 기능을 사용할 수 있는 도구이다.
‣ https://spring.io/projects/spring-cloud

‣ 스프링부트 버전, 스프링클라우드 버전 유의해서 사용 필요!

12-팩터 앱(The Twelve-Factor App)

‣ 확장 가능하고 쉽게 클라우드 플랫폼에 배포할 수 있음.
‣ 지속 배포 프로세스에 따라 배포되는 Software as a Service(SaaS)를 개발하는 방법론.
‣ 스프링 부트 & 스프링 클라우드는 12-팩터룰에 부합하는 애플리케이션 만드는 기능 & 요소 제공
‣ https://12factor.net/ko/

※ Software as a Service(SaaS)
서비스 사업자가 인터넷을 통해 소프트웨어를 제공하고 사용자가 인터넷상에서 이에 원격 접속해 해당 소프트웨어를 활용하는 서비스 모델.
ERP..CRM..SLACK..

‣ https://medium.com/dtevangelist/12-factors-%EB%9E%80-b39c7ef1ed30

넷플릭스(Netflix) OSS

‣ 모놀리식 애플리케이션 기반 전통적 개발 모델 → 마이크로서비스 기반 개발 방식으로 전환한 선구자
‣ 많은 오픈소스가 존재하며, 유레카(Eureka), 히스트릭스(Hystrix), 리본(Ribbon), 줄(Zuul) 등과 스프링 클라우드와 통합됨.

유레카(Eureka)

‣ 서비스 디스커버리 (전화번호부 책)
    → 외부의 서비스들이 마이크로서비스를 검색하기 위해 사용되는 개념
    → 클라이언트가 로드밸런서 or API Gateway을 전달하게되면 serviceDiscovery 에 전달되어 필요 정보를 찾음
‣ 서비스 정보 및 위치정보 확인 등 (Naming server)
‣ 서버가 새롭게 시작되면 그것을 감지하여 자동으로 추가되고, 서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법.

‣ 클라이언트 & 서버로 구분
    • 클라이언트 (discovery client)
          → 애플리케이션의 일부로 원격 디스커버리 서버에 연결하는 일을 담당
          → 연결되면 서비스 이름 & 네트워크 위치를 담은 등록 메세지를 보냄
          → 현재 마이크로서비스가 다른 마이크로서비스의 종단점을 호출해야 할 경우, 서버로부터 등록된 서비스 목록을 담은 최신의 컨피규레이션(설정정보)를 가져옴.
          → 서버로부터 데이터를 가져와 캐싱하고 주기적으로 변경사항 체크한다.
          → 유레카 서버가 멈추더라도 서비스들끼리 통신이 가능하다! 서비스 레지스트리를 로컬에 캐싱했기 때문
          → spring-cloud-starter-netflix-eureka-client 사용

    • 서버 (Service registry)
          → 각 서비스들로부터 생존신호? 메세지를 받고, 메세지를 못받으면 레지스트리에서 서비스 삭제된다.
          → 독립적인 스프링 부트 애플리케이션으로 설정되고 실행됨. 각 서버의 상태를 다른 서버에 복제해 가용성(=서비스 정상 사용 가능정도)이 높음.
          → pring-cloud-starter-netflix-eureka-server 사용

히스트릭스(Hystrix)

‣ 서킷브레이커패턴 구현 도와주는 라이브러리 
‣ 폴백(fallback) 로직 쉽게 구현 가능
‣ spring-cloud-starter-hystricx 스타터 사용

※ 서킷 브레이커 패턴 (circuit breaker pattern)
성공 및 실패 요청 횟수를 센 다음, 에러 비율이 가정된 임계치를 넘으면 차단 발생 및 이후 실패처리한다.
→ 문제되는 부분(느린부분)을 특정 호출을 감지하여 스레드를 소진하지 않고 빠르게 실패시켜 버림(원격 자원 사용 부분 제거)
→ 다른서비스에 영향 안가도록!
지정된 시간이 지나고 나면, 재요청 후 서킷은 닫혀 정상처리가 되도록 한다. 

리본(Ribbon)

‣ 클라이언트 로드밸런서 역할,, 근데 비동기 처리가 잘 되지 않음,, 잘 사용 안하게됨
‣ IP..port..호출이 아닌 이름만 가지고 호출이 가능... 
‣ 클라이언트 측 부하 분산기
‣ HTTP, UDP, TCP 등 가장 유명한 프로토콜 지원
‣ 동기방식의 REST호출, 비동기, 리액티브 모델도 지원
‣ 서비스 디스커버리, 캐싱, 일괄처리, 장애 내성과 통합 가능.
‣ spring-cloud-starter-ribbon 스타터 사용
‣ springboot 2.4 이후 Maintenance 상태 

줄(Zuul)

‣ API 게이트웨이 or API Service, Edge Service
‣ JVM 기반 라우터, 서버 측 부하 분산 or 일부 필터링 수행
‣ 인증, 부하 평균 분배, 정적 응답 처리, 부하 테스트 등에 사용.
‣ 설정 가능 및 독립적 스프링 부트 애플리케이션으로 실행됨.
‣ spring-cloud-starter-zuul 스타터 사용
‣ springboot 2.4 이후 Maintenance 상태 

✻ 최근에는 Ribbon,, Zuul 보단, Spring Cloud Gateway 을 사용하는것을 권장하고 있다고 함.
https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now#spring-cloud-netflix-projects-entering-maintenance-mode

https://happycloud-lee.tistory.com/218​

페인(Feign)

‣ REST Client
‣ Interface 선언을 통해 자동으로 HttpClient 을 생성 
‣ 웹 서비스 클라이언트를 쉽게 작성하도록 도와줌.
‣ 관심사 분리 (리턴값만 관심,, 어떤 URL 인지 어떻게 응답값을 파싱할지는 관심없음)
‣ spring-cloud-starter-feign 스타터 사용
‣ 리본 클라이언트와 통합돼 디스커버리 서비스와 통신, 부하분산 같은 기능 제공.

분산 컨피규레이션 관리

‣ 설정정보 파일을 프로젝트 내부가 아닌, 외부에서 관리하는것 (중앙화 된 저장소에서 구성 요소 관리)
‣ 각 서비스를 다시 빌드하지않고 바로 적용! (중앙에 있으므로)
‣ 서버는 단 하나의 중앙 장소, 애플리케이션을 위한 모든 외부 속성이 모든 환경에 대해 서버에서 관리됨. (key, value.. yml file..)
‣ 설정 파일은 파일 시스템 또는 서버 클래스 경로에 있을 수 있다. (vault..)

※ Vault 
토큰 및 패스워드 자격증명을 관리할 수 있는 오픈 소스 도구
해시코프(HashCorp)에서 만듬
자격 정보 등을 안전한 장소에 저장이 가능하여 보안이슈에 도움이 될 수 있다.
API 을 통해 쉽게 접근 가능 (API는 기본 인증으로 보호됨)
키/공개 키 인증을 사용한 SSL 연결 설정도 할 수 있다.

‣ spring-cloud-config-server 의존성 추가하여 활성화

컨설(Consul)

‣ 넷플릭스 리본과 동적 라우터, 넷플릭스 Zuul의 filter를 지원
‣ spring-cloud-starter-consul-discovery 의존성 사용

아파치 주키퍼(Apache Zookeeper)

‣ 컨피규레이션과 이름을 유지하는 중앙 서비스로 분산 동기화, 그룹 서비스를 가능하게 함. 
‣ 분산 처리된 메세지 큐 정보들 관리, kafka 서버 가동하려면 zookeeper가 구동되어 있어야 함.
‣ 클라이언트 측에 주키퍼를 사용한 서비스 디스커버리를 사용하려면 spring-cloud-startet-zookeeper-discovery, 아파치 큐레이터를 의존성에 포함.
‣ 분산 컨피규레이션 클라이언트를 활성화 하기 위해서는 spring-cloud-starter-zookeeper-config 의존성을 추가필요.

분산추적

슬루스(Sleuth)

‣ 하나의 요청을 여러 마이크로서비스로 처리할때 이어지는 요청을 연관지음
‣ Slf4j, MDC로 개발되었다.
‣ spring-cloud-starter-sleuth 의존성 추가하여 활성화

※ Slf4j
로그백 log4j, logging 등과 같은 특정 로깅 프레임워크의 추상화 퍼사드(Facade=커다란 코드부분에 대해 간략화된 인터페이스를 제공)를함

※ MDC (mapped diagnostic context)
다양한 소스의 로그 출력을 구분하고 실제 범위에 없던 부가 정보를 추가하는 솔루션 

메세징

버스(bus)

‣ 분산시스템의 노드(마이크로서비스)를 경량 메세지 브로커(RabbitMQ)와 연결
‣ 상태 및 구성에 대한 변경사항을 연결된 노드에게 전달 (마이크로 서비스에게 변경사항을 알려줌)
‣ 컨피규레이션 변경 이벤트의 전달 등 공통 오퍼레이션을 위한 분산 메세징 기능을 사용할 수 있다.

스트림(Stream)

‣ 메세지 중심 마이크로 서비스로 구성된 시세틈을 개발하기 위한 올바른 프레임워크
‣ 두개의 바인더가 존재 (AMQP, Apache Kafka)
‣ 스프링 인테그레이션에 기반. 종단점, 채널, 애그리게이터, 트랜스포머와 같은 대부분의 엔터프라이즈 통합 패턴을 지원하는 프로그래밍 모델을 제공
‣ 마이크로시스템 내의 애플리케이션은 스프링 클라우드 스트림 입력 & 출력 채널을 통해 통신함. 
‣ 구독/게시 등 메세지 공유 토픽을 통해 전파. (웹소켓 통신방식 같은건가,,)

※ AMQP (Advanced Message Queue Protocol)
메세징 프로토콜 (MQ(메세지큐) 기반)
HTTP 프로토콜과 달리 네트워크 프로토콜의 정의 뿐 아니라 서버 측 서비스와 동작 방식도 정의한다.
관련 미들웨어 : RabbitMQ, Erlang
메세지브로커
오픈소스 메세지 소프트웨어
https://www.youtube.com/watch?v=80y2C54KPxg
받는 소비자 중심

※ Apache Kafka
Scala언어로 개발된 오픈소스 메세지 브로커 프로젝트
이벤트브로커 (메세지 브로커 기능 포함)
분산 스트리밍 데이터 처리하기 위한 목적으로 설계된 오픈소스 메세징 플랫폼
메세지 발행/구독 시스템 (Pub/Sub)
보내는 생산자 중심

클라우드 플랫폼 지원

‣ 피보탈..SQS,,SNS,,ElasticCache,,RDS,,등이 있다.
‣ 스프링 클라우드 펑션 프로젝트가 있다. FaaS(Function-as-a-Service),,AWS Lambda
‣ SMTP..rabbitMQ,,Redis,,

보안관리 활성화

‣ spring-cloud-starter-security 의존성 추가

릴리즈 트레인

‣ 하위 프로젝트의 혼란을 피하기 위해 릴리즈를 버전이 아닌 이름으로 구분
‣ BOM(Bill of materials)에 기반 → 아티팩트 버전을 독립적으로 관리하는 표준 메이븐 개념.
‣ https://spring.io/projects/spring-cloud-stream

참고

링크: https://m.blog.naver.com/quart21c/173614581

링크: https://coe.gitbook.io/guide/gateway/zuul

링크: https://sup2is.github.io/2020/04/12/spring-cloud-hystrix-circuit-breaker-with-fallback.html

책: http://www.yes24.com/Product/Goods/66581779

링크: http://blog.skby.net/amqp-advanced-message-queue-protocol/

강의: https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4/lecture/68407?tab=curriculum&volume=1.00&speed=1

WebSocket

설명

TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜
HTTP 폴링과 같은 반이중 방식에 비해 더 낮은 부하를 사용하여 웹 브라우저와 웹 서버간의 통신을 가능하게 함. 
서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공
연결이 유지된 상태에서 메세지들을 오갈 수 있게 허용함. (양방향)

※ 전이중 통신 (Full Duplex)
두 지점(시작과 끝) 사이에서 정보를 주고받는 전자 통신 시스템

※ TCP (Transmission Control Protocol), 전송제어프로토콜
서버끼리 통신을 하기 위한 규약(프로토콜)
웹브라우저들이 WWW에 서버 연결할때 사용
이메일 전송 및 파일 전송시 사용

✱ 최초 연결시  
    1. 클라이언트가 서버에 웹소켓 핸드셰이크 요청을 보냄
    2. 서버는 웹소켓 핸드셰이크 응답을 보냄
    3. 이후로 클라이언트는 요청에 대한 응답을 기다리지 않고 요청을 보낼수 있음. (!= HTTP)

Websocket in Spring

관련 예제 

https://spring.io/guides/gs/messaging-stomp-websocket/ 을 참고하여 실습을 해 보았다. 
해당 링크는 STOMP(Simple Text Messaging protocol)을 사용하였다.

※ STOMP(Simple Text Messaging protocol)
텍스트 기반 메세징 프로토콜
이를 이용하여 Binary, Text가 아닌 규격을 맞춘 메세지를 보낼 수 있다. 
발행(pub), 구독(sub), 메세지브로커(=발신자가 메세지 받아와 수신자에게 전달) 등의 개념이 있다.

+ Fallback Options으로 SockJS을 사용하였다. 

테스트 화면

브라우저에서 Send 버튼 클릭 시, /app/hello 을 호출하고
메세지 브로커 핸들러 내에서 처리 후 /topic/greetings 으로 결과정보를 반환함!

참고

링크: https://ko.wikipedia.org/wiki/%EC%9D%B4%EC%A4%91%ED%86%B5%EC%8B%A0

링크: https://ko.wikipedia.org/wiki/%EC%9B%B9%EC%86%8C%EC%BC%93

링크 :https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EC%A0%9C%EC%96%B4_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

링크: https://namu.wiki/w/TCP

링크: https://tecoble.techcourse.co.kr/post/2021-09-05-web-socket-practice/

링크: https://tech.kakao.com/2020/06/22/websocket-part3/

링크: https://www.youtube.com/watch?v=rvss-_t6gzg

스프링 클라우드

설명

클라우드 어플리케이션을 구축하기 위한 프레임워크
아래와 같은 내용들을 제공해준다.

    ▶︎ 분산 / 버전 컨피규레이션
        • 분산 컨피규레이션은 클라우드 네이티브 환경에서 인기있는 표준이다. 
        • 스프링 컨피그는 분산시스템에서 외부 컨피규레이션을 위해 서버 측과 클라이언트 측을 지원한다.
            → 중앙 단일 저장소 생성됨. ... vault..
        • 주키퍼(Zookeeper) 등이있다..

    ▶︎ 서비스 등록 & 디스커버리
        • 디스커버리는 컴퓨터 네트워크상의 디바이스가 제공하는 디바이스&서비스를 자동으로 감지하는 서비스이다.
            → 각 서비스들 실행시 중앙 서버에 자신(서비스)을 등록하는것. (IP, Port 등)
            → 클라우드 환경에서 각 서버인스턴스들이 오토스케일링 되거나, 생성 확장등이 될때 IP or Port 등이 변경될 가능성이 높아지기 때문에 이러한 정보들을 캐치하기 위하여 사용함.
        • 넷플릭스 OSS(Open Source Software) 의 디스커버리 패키지 유레카(Eureka)가 있다.
        • 유레카는 클라이언트 & 서버로 구성이 되며, 클라이언트는 원격 디스커러비서버에 연결하는 일을 담당하고
서버는 독립적인 스프링부트 어플리케이션을 담당한다.


    ▶︎ 라우팅
        • 넷플릭스 OSS(Open Source Software) 의 줄(Zuul)이 있다.
        • 줄은 부하분산 및 필터링을 수행하고, 게이트웨이로써의 중요한 역할을 한다.

    ▶︎ 서비스간 호출

        • API 게이트웨이에서 각 서비스를 호출할 때, 도메인으로 호출하지 않고 IP등으로 호출하게 되면 변경된 IP에 대해서는 관련 내용을 업데이트 해줘야 함
        • 디스커버리 서비스는 인스턴스의 ID나 이름으로 호출하기에, 변경된 정보를 불러오는데 문제가 없음. 
        • API 통신할때 사용하는 RestClient 종류로 넷플릭스 OSS(Open Source Software) 의페인(Feign) 이 있다.

    ▶︎ 부하분산
        • 라운드 로빈 규칙을 가지고 디스커버리에 등록된 인스턴스 목록을 가져오는 역할을 한다. (부하분산기)
        • 넷플릭스 OSS(Open Source Software) 의 리본(Ribbon) 이 있다.

    ▶︎ 서킷브레이커
        • 네트워크 타임아웃 문제 해결 
        • 서킷 브레이커: 성공 & 실패 확률을 저장
        • 임계치가 넘으면 차단! 
        • 폴백(fallback) 로직 수행!


    ▶︎ 분산 메세징 
        • AMQP, Apache kafka 등이 있다.

클라우드 네이티브 어플리케이션

설명

클라우드 환경을 위해 잘 설계된 프로그램
https://docs.spring.io/spring-cloud-commons/docs/3.1.1/reference/html/

참고

책: http://www.yes24.com/Product/Goods/66581779
링크: https://mangchhe.github.io/springcloud/2021/04/07/ServiceDiscoveryConcept/

링크: https://www.baeldung.com/spring-cloud-bootstrapping

하나의 어플리케이션을 여러 어플리케이션으로 쪼갠것 (느슨한 연결)
    → 프로젝트 참여자가 서비스 파악에 용이 (쪼개져 있으므로!)
    → 분리된 서비스를 각 담당자들이 나눠 관리함.
    → 쪼개져있어 서비스간 배포에 영향도 X
    → 확장성, 독립성, 유연성

작고 독립적인 단위이고 중앙에서 관리가 됨.
    → 네트워크 위치, 컨피규레이션(configuration), 로깅파일, 메트릭등은 중앙에서 관리됨.

※ 메트릭
소프트웨어의 속성이나 규격을 측정할 수 있는 지표.
프로그램의 복잡성, 코드별 버그의 수, 수요자 요구 사항의 수 따위를 측정한다.

참고

책: http://www.yes24.com/Product/Goods/66581779

링크: https://badadict.com/ko/1623891​

JPQL (Java Persistence Query Language)

설명

테이블 대상으로 한 언어가 아닌, 엔티티 객체 대상으로 쿼리한 것.
SQL을 추상화하여 특정 데이터베이스 SQL에 의존하지 않음.
JPQL → SQL 으로 변환함
객체지향SQL

특징

-- 일반 SQL 문
select * from Member as m where m.username = 'coffee' -- 별칭(m)은 필수다.

-- JPQL 문
/**
@Entity(name="memeber")
class Memeber {
  ...
  private String username;
}
*/
select m from memeber as m where m.username = 'coffee'
-- → 엔티티명(member)으로 조회해야한다.
-- → 그렇지 않으면 클래스명(Member)을 기본으로 사용한다. (클래스명 추천)
-- → 대소문자를 구분한다.

select m.username from member as m 
-- → username 을 조회 한다면, 별칭(m)은 필수로 사용해야함.

결과값을 받을 때 (createQuery 사용 시)

• TypeQuery: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 있는 경우 사용.
• Query: 반환타입(메소드 리턴타입)을 명확하게 지정할 수 없는 경우 사용.

결과 조회 API

• query.getResultList(): 결과가 하나 이상일때 리스트 반환
• query.getSingleResult(): 결과가 정확히 하나, 단일 객체 반환.

JPQL 조인

• 내부 조인과 외부조인

-- 내부 조인 (INNER JOIN, INNER 생략 가능)
select m from Member m inner join m.team t where t.name = :teamName


-- 외부 조인 (LEFT OUTER JOIN, OUTER 생략 가능)
select m from Member m left join m.team t


-- 세타조인 (연관관계 없는데 조인하고 싶은 경우!!)
select count(m) from Member m, Team t where m.username = t.name

• 컬렉션 조인
  → 일대다 or 다대일 관계 처럼 컬렉션을 사용하는 곳에 조인하는 것. 
  → 일대다(=다의 연관필드 사용) or 다대일(=일의 연관필드 사용)
 
• 세타 조인
  → where 절 사용하여 조인 (select count(m) from Memeber m, Team t where m.username = t.name)

• JOIN ON 절 (JPA 2.1 부터 사용 가능)
  → 외부조인에서만 사용.

• 페치 조인 (FETCH JOIN)
  → JPQL에서 성능 최적화를 위해 제공하는 기능. 연관된 엔티티나 컬렉션을 한번에 같이 조회하는 기능. join fetch 으로 사용.
  → 페치조인 사용시, SQL 한번으로 연관된 엔티티들을 함께 조회할 수 있어, SQL 조회 횟수를 줄여 성능 최적화가 가능하다.
  → 지연로딩 사용 및  fetch join 적용하는것이 효율적.
  → 페치조인은 alias 사용을 못하며, 둘 이상의 컬렉션을 페치할 수 없다. 그리고 페이징 API을 사용할 수 없다...헉 
  → 페치조인은 객체 그래프 유지할때 사용하면 효과적!
  → 특정 데이터만 표현해야 한다면 구지 페치 조인을 사용할 필요는 없다.

-- fetch join 을 사용하는 경우, m 및 m.team 모두 조회됨.
-- >> JPQL 식
select m from Member m join fetch m.team where m.name = 'AA'

-- >> SQL 식 
select
  m.*, t.*
from Member m join Team t on m.team_id = t.id
where m.name = 'AA'




-- fetch join 이 아닌 일반 join 을 하는 경우는 SQL 에서 이렇게 나옴
-- >> JPQL 식
select m from Member m join m.team

-- >> SQL 식 
select
  m.*
from Member m join Team t on m.team_id = t.id

• 묵시적 조인
  → join 키워드 직접 사용 (select ~~ from Member m join m.team t)
  → 조인이 일어나는 상황,,을 한눈에 알아보기 어렵다,,?

• 명시적 조인 (추천⭐️)
  → 경로 표현식에 의해 묵시적으로 SQL 조인 발생 (내부 조인만 가능) (select m.team from Member m)

서브쿼리

where, having 절에서만 사용 가능하며, select, from 절에서는 사용 불가능! (ㅠㅠ)
• EXISTS(결과 존재시 참) → select ~~ where exsist (select t from ~~)
• ALL(모두 만족 참) → select ~~ where o.number > ALL (select b from ~~)
• ANY(조건이 하나라도 만족시 참=SOME) → select ~~ where a.tesm = ANY(select c from ~~) 
• IN(서브쿼리 결과 중 하나라도 같은 값이 있으면 참) select ~~ where a.count in (select d from ~~)

CASE 식

• COALESCE: 하나씩 조회해서 null 이 아니면 반환
• NULLIF: 두 값이 같으면 null 반환, 다르면 첫번째 값 반환

사용자 정의 함수

select function('group_concat', name) from ~~
→ 사용 전 group_concat을 사용한다는 정의를 해야 함. (DB방언 상속 받고, 사용자 정의 함수 등록 필요)

참고

- 책: https://www.coupang.com/vp/products/20488571?itemId=80660090&vendorItemId=3314421212&src=1042503&spec=10304982&addtag=400&ctag=20488571&lptag=10304982I80660090&itime=20220302010946&pageType=PRODUCT&pageValue=20488571&wPcid=16461509863931582782572&wRef=&wTime=20220302010946&redirect=landing&gclid=CjwKCAiApfeQBhAUEiwA7K_UHxuELLbyb9IhdrRf5inlJZLtN8-t8cUswFHeV6fFp-Yd4RThtzZvHxoCPFsQAvD_BwE&campaignid=12207438463&adgroupid=115720946583&isAddedCart= 

연관관계 매핑

테이블을 기준으로 하면, 외래키를 사용하여 테이블끼리 연관을 맺는것 or 객체라면 참조(주소)을 사용하여 연관을 맺는것.

연관관계 방향 (Direction)

‣ 단반향 연관관계
    → 한쪽만 참조하는것
    → 객체 관계

‣ 양방향 연관관계 
    → 서로 참조하는것
    → mappedBy 속성 사용
    → 테이블 끼리 연관관계 맺기 (외래키 이용) = 서로 다른 단방향 관계 2개

다중성 (Multiplicity)

‣ 다대일 (N:1)
    → 단방향, 양방향
    → @ManyToOne 으로 표현
    → N 에 외래키 존재 = 연관관계 주인
    → @ManyToOne 기본 페치전략: 즉시로딩 (EAGER)


‣ 일대다 (1:N)
    → 단방향(@JoinColumn 명시 필요), 양방향(=존재하지 않음. 다대일 양방향 매핑을 사용해야함)
    → @OneToMay 으로 표현
    → N 에 외래키 존재 = 연관관계 주인
    → @OneToMany 기본 페치전략: 지연로딩 (LAZY)
    → 일대다 단방향 매핑보단, 다대일 양방향 매핑을 사용하도록 하자! (외래키 관리하기 힘들기 때문이다.)

‣ 일대일 (1:1)
    → 주테이블 or 대상테이블 에서 외래키 가질 수 있음.
    → @OneToOne 으로 표현
    → @OneToOne 기본 페치전략: 즉시로딩 (EAGER)

‣ 다대다 (N:N)
    → 단방향, 양방향 (다대다 양방향은 일대다 양방향과 같음)
    → @ManyToMany 으로 표현
    → N:N 사이 중간 테이블을 추가하여 사용.
    → 식별관계와 비식별관계가 있다.
    → @ManyToMany 기본 페치전략: 지연로딩 (LAZY)

연관관계 매핑 관련 어노테이션

@ManyToOne(optional="false 리면 연관된 엔티티가 항상 있어야 한다. 기본값: true", 
           fetch="글로벌 페치 전략(EAGER, LAZY)", 
           cascade="영속성 전이 기능 사용", targetEntity="연관된 엔티티의 타입 정보 설정(거의사용안함).")
           
           
@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)

@ManyToOne(fetch = FetchType.LAZY)

@ManyToMany(mappedBy = "items")

@JoinColumn(name="매핑할 외래 키 이름", 
            referencedColumnName="외래키가 참조하는 대상 테이블의 컬럼명", 
            foreignKey="외래키제약조건을 직접 지정할 수 있다. 이 속성은 테이블을 생성할 때만 사용한다.")
/**
- 그외속성
unique, nullable, insertable, updatable, columnDefinition, table..
*/

@JoinTable(name = "category_item",
        joinColumns = @JoinColumn(name = "category_id"),
        inverseJoinColumns = @JoinColumn(name="item_id")
)

// 부모 객체에 설정
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) // 한테이블에 컬럼 다 때려박음
@DiscriminatorColumn(name = "dtype") // 하위 자식테이블들 타입..

// 자식객체에다가 설정
@DiscriminatorValue("A")

@Enumerated(EnumType.STRING)

@Embedded

@Id @GeneratedValue
@Column(name = "order_id")
private Long id;

연관관계 주인 (Owner) vs 주인이 아닌쪽

‣ 연관관계의 주인
    → 데이터 베이스 연관관계와 매핑되고 외래키를 관리(등록,수정,삭제)를 할수있다.
    → mappedBy 속성을 사용하지 않는다.
    → 외래키 관리자를 선택 하는것이다.
    → 외래키의 위치와 관련해서 정해야하고, 비지니스 중요도로 접근하면 안됨
‣ 주인이 아닌 쪽
    → 읽기만 가능하다.
    → mappedBy 속성을 사용 하여 속성의 값으로 연관관계의 주인을 지정할 수 있다.

프록시

연관된 객체를 처음부터 데이터베이스에서 조회하는것이 아니라, 실제 사용하는 시점에 데이터베이스에서 조회할 수 있음

프록시 객체

‣ 데이터베이스 조회를 지연할 수 있는 가짜 객체(지연로딩에서 사용). 실제 엔티티 클래스를 상속받아 만들어져있음.
‣ 진짜객체인지, 프록시 객체인지 구분하지 않고 사용 가능
‣ EntityManager.getReference(): 조회를 미루고 싶을때 사용. 이를 사용하면 프록시 객체를 반환
‣ 처음 사용할때 한번만 초기화 → 초기화되면 프록시 객체를 통해 실제 엔티티에 접근 가능.
‣ 영속성 컨텍스트에 찾는 엔티티가 이미 있으면, 데이터베이스를 조회할 필요가 없으므로
em.getReference()을 호출해도 프록시가 아닌 실제 엔티티를 반환함.

즉시로딩(FetchType.EAGER) 과 지연로딩(FetchType.LAZY) 

‣ 즉시로딩(FetchType.EAGER)
    → 엔티티를 조회할 때 연관된 엔티티도 함께 조회
    → 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회
    → 연관된 엔티티가 하나면 즉시로딩 사용


‣ 지연로딩(FetchType.LAZY)
    → 연관된 엔티티를 실제 사용할 때 조회
    → 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회
    → 연관된 엔티티가 컬렉션이면 지연로딩 사용

✰ 지연로딩을 사용하도록 하자. (N+1문제 방지)
✰ 컬렉션은 필드에서 바로 초기화를 하도록 하자. (ex. Apple apple = new Apple();)
✰ 만약 엔티티조회시, 연관된 엔티티를 조회해야한다면 fetch join을 사용하자. 

참고

- 책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 

- 링크: https://velog.io/@lsj8367/JPA-%ED%94%84%EB%A1%9D%EC%8B%9C

변경감지 (Dirty Checking)

‣ 변경된 엔티티 내용을 데이터베이스에 자동으로 반영해주는 기능.

em.save() 을 호출하지 않았는데 데이터베이스에 저장이 되었다.

‣ 트랜잭션 커밋 후, flush (데이터베이스 동기화) 하면서 username 변경됨 → 데이터베이스 반영 

참고

- 링크: https://cornarong.tistory.com/m/63