• 주요 주제

    1. tomcat 9 (2017 예정 java 9과 함께)
    2. Spirng 5.0 (2016.11 예정)
      1. 4.3 은 6월에 나왔음

  • Spring F/W 5

    1. 발표자
      1. 이창제
    2. 주요 업그레이드 항목
      1. JDK 8 +
      2. Servlet 3.1 +
      3. JMS 2.0
      4. JPA 2.1
      5. JUnit 5

    3. 특징
      1. JDK8
        1. 람다, 스트림 >> 언어의 패러다임 이 바뀌고 있다. (적응하자)
        2. JDK 6,7 은 사용 불가할것 (그만쓰자)
      2. Core Container
        1. Bean 디텍션, 생성 강화
          1. 기존 싱글쓰레드의 Bean 검색 > 멀티쓰레드 방식으로 바뀜 (빌드가 빨라질거다)
      3. Java9
        1. JigSaw (직쏘?) 알아볼것
        2. String Compact 개선
        3. GC 개선
    4. 마이크로 서비스화에 대해
      1. 전통적 스케일 방식이 바뀐다.
      2. 멀티쓰레드 > 프로세싱 > 레이턴시 확장
      3. 쓰레드풀 방식의 쓰레드 관리의 한계점
      4. Application Handling
      5. 부하에는 로드밸런싱 방식의 해결이 더 적합하다고 판단
      6. 부하에는 클라우드 서버의 레이턴시를 확장함으로 해결 (컨테이너 방식  ex.도커)

  • Spring Boot 1.4

    1. 발표자 
      1. pivotal 부장
    2. 써야하는 이유
      1. 웹 어플리케이션을 만들기 위해 했던 많은 수작업을 자동으로 수행해 준다.
        1. 수작업 - 웹어플리케이션 어노테이션 설정 (~ProjectWebApplicationConfig.java 등), 서버 관련 설정 등
        2. 자동 - 어노테이션 기반 (찾아보자.)
    3. 1.4 의 달라진점
      1. 테스트가 강화 되었다. '@SpringBootTest 어노테이션. '@SpringRunner | '@WebMVCTest (도메인마다 어노테이션 이름이 달라짐), 
      2. '@EnableCache('캐쉬명') Caffein 프로젝트 기반 캐시 라이브러리 제공, 쉽게 쓸 수 있다.
      3. 이스터에그? - web 리소스 최상단에 banner.jpg or png 를 넣으면 ASCII 코드 방식으로 바꿔서 콘솔에 출력해 준다.
      4. build_info 라는 곳에 빌드 정보를 자동 생성 할 수 있다. 

  • React Program. with Spring

    1. Reactive program
      1. 비슷한 패러다임 - RxJava (Netflix) Akka
      2. 기존에는 다중 처리방식에는 thread 기반으로 처리했다.
      3. 쓰레드풀 방식에는 한계가 있다. 
      4. 비동기 방식으로 해결 하자. (Async)
      5. Pool 방식에서 Data 방식으로 해결을 해보자 라는 관점에서 출발
      6. Publisher < back pressure > Subscriber
        1. 뒷단이 받을 수 있을 만큼만 보낸다.
      7. ex1) Flux . '[0..N] 끊임없는 데이터
        1. account 정보를 Alert 라는 객체로 기대하며 id 를 보냈을때 완료 시 bodyStream 에 보낸다. 라는 정도의 이해.
      8. ex2) Mono. '[0..1] 이거나 아니거나
        1. error 일경우 , 비었을 경우 등의 처리를 callback 방식으로 처리 하는 것 을 볼 수 있다.



    2. 프로그램의 관점이 바뀐다.
      1.  Pull -> Push
        1. 데이터를 당겨 온다는 개념 > 데이터를 밀어준다는 개념 (참조하고있는곳에)
        2. 데이터의 흐름과 변화를 전달하는 하나의 개념
      2. 기존에는 있지 않았나? ex. future 메소드
        1. future.get() >> 이 자체도 비동기 방식이다.
      3. Stream방식의 데이터 처리 방식에 따라 관점이 바뀌게 되었다.
      4. 싱글쓰레드로 잘쓰는게 멀티쓰레드 보다 빠르다.
      5. 퍼포먼스를 중히 여기는 프로그래머는 기계?에 동점심을 가져야 한다.
      6. Non Blocking Event Driven
      7. 콜렉션 단위의 처리에 좋을 듯 하다.
    3. 데이터 흐름의 방식
      1. 기존 - return rep.findOne(id);
      2. 변경1 - Future<User> findOne(id);
      3. 변경2 - ComPletableFuture<Void> save(user).callBack(~).onError(~).onComplete(~); 
    4. 장점
      1. 응답성 / 장애대응 / 확장성 / 메시지 기반
    5. 필요한 인식 
      1. Circuit Breaker 디자인 패턴 
        1. 한 서비스를 호출하는데 시간이 허용 범위 이상으로 많이 걸릴 경우 끊어서 장애 대응
        2. 처리하지 못하는데 쓰레드만 쌓일 경우 처리하는 방식
        3. ex. 코레일 예매시스템. 
    6. 확인 필요
      1. LMAX 방식( 림구조) - 버퍼를 만들어서 바로 사용 
        1. 싱글쓰레드 방식의 처리
      2. log4j2가 LMAX방식으로 사용한다.
    7. 생각해봐야 할점
      1. 프로그램의 끝은 어떻게?
        1. 어떤 방식으로 끝내든 마지막에 신청한 사용자는 받지 못하게 될 것이다. 이 경우 끝은 어떻게 낼까?


    8. Q&A
      1.  왜 node js 를 안쓰나?
        1. 그럴거면 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

    + Recent posts

    티스토리툴바