주요 주제
- tomcat 9 (2017 예정 java 9과 함께)
- Spirng 5.0 (2016.11 예정)
- 4.3 은 6월에 나왔음
Spring F/W 5
- 발표자
- 이창제
- 주요 업그레이드 항목
- JDK 8 +
- Servlet 3.1 +
- JMS 2.0
- JPA 2.1
- JUnit 5
- 특징
- JDK8
- 람다, 스트림 >> 언어의 패러다임 이 바뀌고 있다. (적응하자)
- JDK 6,7 은 사용 불가할것 (그만쓰자)
- Core Container
- Bean 디텍션, 생성 강화
- 기존 싱글쓰레드의 Bean 검색 > 멀티쓰레드 방식으로 바뀜 (빌드가 빨라질거다)
- Bean 디텍션, 생성 강화
- Java9
- JigSaw (직쏘?) 알아볼것
- String Compact 개선
- GC 개선
- JDK8
- 마이크로 서비스화에 대해
- 전통적 스케일 방식이 바뀐다.
- 멀티쓰레드 > 프로세싱 > 레이턴시 확장
- 쓰레드풀 방식의 쓰레드 관리의 한계점
- Application Handling
- 부하에는 로드밸런싱 방식의 해결이 더 적합하다고 판단
- 부하에는 클라우드 서버의 레이턴시를 확장함으로 해결 (컨테이너 방식 ex.도커)
Spring Boot 1.4
- 발표자
- pivotal 부장
- 써야하는 이유
- 웹 어플리케이션을 만들기 위해 했던 많은 수작업을 자동으로 수행해 준다.
- 수작업 - 웹어플리케이션 어노테이션 설정 (~ProjectWebApplicationConfig.java 등), 서버 관련 설정 등
- 자동 - 어노테이션 기반 (찾아보자.)
- 웹 어플리케이션을 만들기 위해 했던 많은 수작업을 자동으로 수행해 준다.
- 1.4 의 달라진점
- 테스트가 강화 되었다. '@SpringBootTest 어노테이션. '@SpringRunner | '@WebMVCTest (도메인마다 어노테이션 이름이 달라짐),
- '@EnableCache('캐쉬명') Caffein 프로젝트 기반 캐시 라이브러리 제공, 쉽게 쓸 수 있다.
- 이스터에그? - web 리소스 최상단에 banner.jpg or png 를 넣으면 ASCII 코드 방식으로 바꿔서 콘솔에 출력해 준다.
- build_info 라는 곳에 빌드 정보를 자동 생성 할 수 있다.
React Program. with Spring
- Reactive program
- 비슷한 패러다임 - RxJava (Netflix) Akka
- 기존에는 다중 처리방식에는 thread 기반으로 처리했다.
- 쓰레드풀 방식에는 한계가 있다.
- 비동기 방식으로 해결 하자. (Async)
- Pool 방식에서 Data 방식으로 해결을 해보자 라는 관점에서 출발
- Publisher < back pressure > Subscriber
- 뒷단이 받을 수 있을 만큼만 보낸다.
- ex1) Flux . '[0..N] 끊임없는 데이터
- account 정보를 Alert 라는 객체로 기대하며 id 를 보냈을때 완료 시 bodyStream 에 보낸다. 라는 정도의 이해.
- ex2) Mono. '[0..1] 이거나 아니거나
- error 일경우 , 비었을 경우 등의 처리를 callback 방식으로 처리 하는 것 을 볼 수 있다.
- 프로그램의 관점이 바뀐다.
- Pull -> Push
- 데이터를 당겨 온다는 개념 > 데이터를 밀어준다는 개념 (참조하고있는곳에)
- 데이터의 흐름과 변화를 전달하는 하나의 개념
- 기존에는 있지 않았나? ex. future 메소드
- future.get() >> 이 자체도 비동기 방식이다.
- Stream방식의 데이터 처리 방식에 따라 관점이 바뀌게 되었다.
- 싱글쓰레드로 잘쓰는게 멀티쓰레드 보다 빠르다.
- 퍼포먼스를 중히 여기는 프로그래머는 기계?에 동점심을 가져야 한다.
- Non Blocking Event Driven
- 콜렉션 단위의 처리에 좋을 듯 하다.
- Pull -> Push
- 데이터 흐름의 방식
- 기존 - return rep.findOne(id);
- 변경1 - Future<User> findOne(id);
- 변경2 - ComPletableFuture<Void> save(user).callBack(~).onError(~).onComplete(~);
- 장점
- 응답성 / 장애대응 / 확장성 / 메시지 기반
- 필요한 인식
- Circuit Breaker 디자인 패턴
- 한 서비스를 호출하는데 시간이 허용 범위 이상으로 많이 걸릴 경우 끊어서 장애 대응
- 처리하지 못하는데 쓰레드만 쌓일 경우 처리하는 방식
- ex. 코레일 예매시스템.
- Circuit Breaker 디자인 패턴
- 확인 필요
- LMAX 방식( 림구조) - 버퍼를 만들어서 바로 사용
- 싱글쓰레드 방식의 처리
- log4j2가 LMAX방식으로 사용한다.
- LMAX 방식( 림구조) - 버퍼를 만들어서 바로 사용
- 생각해봐야 할점
- 프로그램의 끝은 어떻게?
- 어떤 방식으로 끝내든 마지막에 신청한 사용자는 받지 못하게 될 것이다. 이 경우 끝은 어떻게 낼까?
- 프로그램의 끝은 어떻게?
- Q&A
- 왜 node js 를 안쓰나?
- 그럴거면 node js 세미나를 가던지... 우리는 문제를 스프링 기반으로 해결하고자 하는 방향의 관점에서 본다.
- 왜 node js 를 안쓰나?
'spring' 카테고리의 다른 글
BeansUtil copyProperties 사용, date exception 회피 (0) | 2015.12.28 |
---|---|
No Spring WebApplicationInitializer types detected on classpath (0) | 2013.10.22 |
Spring Task 관리. (0) | 2013.05.10 |
AOP 란 (0) | 2013.05.10 |
Spring이란? (Key word로 설명하는 Spring이란) (0) | 2013.05.07 |