---
# System prepended metadata

title: "\U0001F380 2020-10-10 BE 공부방 \U0001F380"

---

# 🎀 2020-10-10 BE 공부방 🎀

## 1. 무엇을 공부해볼까요?
- 동기? 비동기?
- 블로킹? 논블로킹?

----------

- Netty 태린
유지 관리가 용이한 고성능 프로토콜 서버와 클라이언트를 신속하게 개발하기 위한 **비동기식 이벤트 기반 네트워크 애플리케이션 프레임워크**

Netty를 써야하는 이유?
1. 고성능
2. 쓰기 편하다.(유연하고 쉽다)

Netty가 고성능인 이유는?
- Non-Blocking Asynchronous 처리가 기본
- 적은 스레드로 많은 요청을 처리
- GC부하를 최소화하는 Zero-copy ByteBuf 지원

Netty가 쓰기 편한 이유는?
- 각종 네트워크 프로토콜(코덱) 기본 지원
- 필요한 부분을 쉽게 조립해 쓸 수 있는 구조
- 멀티스레딩 처리 없이도..?

NIO(non-blocking input output)?
기존의 소켓 프로그래밍은 클라이언트가 접속할 경우 스레드를 할당해야함(1:1r관계)
많은 클라이언트가 접속할경우 그 수만큼 스레드 생성 -> 리소스낭비, 무한대기현상 발생
=> 이러한 문제 해결하기위해 NIO탄생 (비동기)
    - 클라이언트 당 스레드 생성하지 않고 필요할때마다 스레드에게 통지하기 때문에 비동기적인 통신 구조 가능
    
===> 순수 자바 라이브러리를 이용해 이러한 네트워크 구축하는것은 어렵
======> 이걸 이미 구현해서 도와주는 애가 네티






- Netty vs Servlet Container
- Servlet+Servlet Container
    - Servlet
         웹프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술, 즉 클라이언트의 요청을 받아 처리하여 응답하는 역할.
         - 특징
         1. 클라이언트 요청에 대해 동적으로 작동
         1. Java Thread를 이용하여 동작
         1. mvc 패턴에서 Controller로 이용
    
    - Servlet Container (vs. WAS??)
        서블릿을 관리해주는 컨테이너. (서블릿이 존재한다고 해서 스스로 작동하지 않음) 즉, servlet에 명시되어 있는대로 동작한다. 요청을 받고 응답을 할 수 있게 웹서버와 소켓을 만들어 통신한다.
        - 서블릿 컨테이너는 요청이 올 때 마다 새로운 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를
실행하고 나면, 쓰레드는 자동으로 없어짐.

전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술
---------
연주
- 스프링 클라우드(SaaS)
    - 왜 필요해?
        - 서비스 확장성
        - 클라우드 플랫폼 쉽게 배포가능
        - 클라우드 플랫폼에서 지속적인 배포가 가능
    - 지원 라이브러리
        - Security
        Spring Security에서 지원하는 서비스(OAuth2, JWT, 기본인증)를 Cloud에서 사용할 수 있도록 해준다. 
        장점은 Cloud에서 사용하는 API Gateway에 인증 과정을 넣기 편하도록 해준다.
        

- JWT+Spring Security의 문제점
    - 매 요청마다 사용자디테일서비스의 사용자DB에 들러 확인해야하는 불편함이 있다 

- Spring Security vs Spring Cloud Security
    - Spring Cloud는 Spring Cloud Gateway를 지원해준다. Gateway에서 Security기능을 사용할 수 있다.
    - 하지만 필자는 1) 매요청마다 DB에 들러 사용자디테일서비스 확인 2) 게이트웨이에서 사용할 수 있는 Security를 사용
    -  이 2가지 방법 중 하나를 채택하지 않고 cutom global filter를 만들어 게이트웨이에 적용했다. 

- Spring Cloud Zuul vs Spring Cloud Gateway
    - Spring Cloud의 초창기 버전에서는 Netfilx OSS(Open Source Software)에 포함된 컴포넌트 중 하나로서 API Gateway 패턴을 구현할 수 있는 Zuul 을 사용했다. 이렇게 Spring Cloud + Zuul의 형태를 Spring Cloud Zuul이라고 한다. Zuul은 서블릿 프레임워크 기반으로 만들어졌기 때문에 동기(Synchronous), 블로킹(Blocking) 방식으로 서비스를 처리한다. 

    - 그러다 최근(?) 비동기(Asynchronous), 논블로킹(Non-Blocking) 방식이 대세가 되면서 해당 방식을 지원하는 Zuul2가 나오게 된다. 

    - 하지만 Zuul은 Spring 생태계의 취지와 맞지 않아, Spring Cloud Gateway에서는 Zuul2를 사용하지 않고 API Gatewway 패턴을 구현할 수 있는 Spring Cloud Gateway를 새로 만들게 된다. 

    - Spring Cloud Gateway도 Zuul2와 마찬가지로 비동기, 논블로킹 방식을 지원한다. 또한 Spring 기반으로 만들어졌기 때문에 Spring 서비스와의 호환도 좋다. 더 나아가 최근에 Zuul2와 Spring Cloud Gateway의 성능을 비교하는 글이 많이 올라오는데 Spring Boot2와 Spring Cloud2가 릴리즈 된 이후에는 Spring Cloud Gateway가 성능이 더 좋다는 분석도 있다(참고)

    - Spring Cloud Gateway는 Netty 런타임 기반으로 동작한다. 때문에 서블릿 컨테이너나 WAR로 빌드된 경우 동작하지 않는다.



## 참고자료
[[API Gateway + Refresh JWT 인증서버 구축하기] Spring boot + Spring Cloud Gateway + Redis + mysql JPA 1편](https://velog.io/@tlatldms/API-Gateway-Refresh-JWT-%EC%9D%B8%EC%A6%9D%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-Spring-boot-Spring-Cloud-Gateway-Redis-mysql-JPA-1%ED%8E%B8)