Error와 Exception

Error

컴파일시 문법적인 오류와 런타임시 예측불가능한 에러가 있다. 에러의 예로는 StackOverflowError / OutOfMemoryError 등이 있으며 발생시 프로세스가 종료된다. 핸들링이 불가능하고 회복이 불가능하다.

Exception

프로그램이 핸들링이 가능한 경우 익셉션이라한다.
처리가 가능하다.
프로그램이 동작중 예상하지 못한 상태가 발생하여 수행중인 프로그램이 영향을 받는것.
CheckedException(Compile tiem)

• 컴파일시점에 예측이 가능하다.
  UncheckedException(Run time)
  • 컴파일 시점에는 예측이 불가능하고, 런타임시에 발생하는 예외

스프링에서의 예외처리

1. 메소드 단위에서 try/catch를 이용하여 처리
2. 컨트롤러 단위에서 @ExceptionHandler를 이용해서 처리
   • @Controller / @RestController 가 적용된 Bean내에서 발생하는 예외를 잡아서 하나의 메소드에서 처리해주는 기능.
3. @ControllerAdvise를 이용하여 Global level에서 컨트롤러 이후 Client에게 전달되기 직전 처리
   • @ControllerAdvise 모든 @Controller 즉, 전역(Global)에서 발생할 수 있는 예외를 잡아서 처리해주는 어노테이션

REST API

아래의 블로그에 정리가 매우 잘되어있음

meetup.toast.com/posts/92

이영상도 보면 좋음

www.youtube.com/watch?v=RP_f5dMoHFc

마지막으로 fetch에 대하여

juunone.netlify.app/web/fetch-api/

MSA란 무엇인가?

• MSA

  • 하나의 서비스를 만들때 도메인별로 서비스를 쪼개어 독립적으로 서비스하고, 디플로이할 수 있도록 구성하는 아키텍쳐
  • 모놀리식(monolithic) 아키텍처와 대비되는 성격의 아키텍처이다.
  • 애플리케이션 로직을 각자 책임이 명확한 도메인별로 분리하여 이를 조합해 솔루션을 제공한다.
  • 각 컴포넌트(도메인)는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포된다. 마이크로 서비스는 비지니스 영역의 한 부분에서의 책임만을 담당하고, 여러 어플리케이션에서 재사용할 수 있어야한다.
  • 어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하기때문에 서비스 구현기술과 무관하다. 이는 한 서비스를 구축하할때 개발언어 및 기술에 종속되지 않고 다양한 언어와 기술을 사용할 수 있다는 장점이있다.

• Monolithic

  • 모듈이 서비스 내부의 Product 현태로 종속되어있으며, 서비스에만 집중할 수 있는 구조
  • 장점
    • 개발 초기에는 단순한 아키텍처 구조와 개발의 용이함이 큰 잠점.
  • 단점
    • 규모가 커짐에따라 복잡도의 증가가 심해진다.

• MSA의 장점

  • 각 도메인별로 서비스를 배포하고 운용하기때문에 결합도(coupling)이 낮아지는 장점이있다.
  • 배포가 유연하다.
  • 재사용성 및 확장성이 크다.
  • 서비스별 기술의 도입 및 확장이 자유롭다.
  • 하나의 서비스에 문제가생겨도 연관되지 않은 다른 도메인은 지속적으로 서비스가 가능하다.

• MSA의 단점

  • 장애추적, 모니터링, 매시징이 어렵다(?? 이게 어렵나?)
  • 어려 도메인에 걸친 기능의 경우 트랙잭션을 다루기 어렵다.
  • 도매인간 의존성이 있는경우 릴리즈가 어렵다. <=> 도매인간 roll-out계획 마련 및 명확한 의존성 관리

** 참고 자료 https://waspro.tistory.com/429