엔터프라이즈 자바 마이크로서비스
엔터프라이즈서비스를 구현할 때 도움되는 프레임워크나 라이브러리 소개, 서비스발견개념, 히스트릭스, 도커 등 엄청 다양하고 얇게 예제를 통해 소개하고 있다.
필요한공부는 각자 깊게 해야함!
실습은 나중에 따라 해볼만할 듯. 소스원본도 있는 듯
엄청가볍게 개념만 읽으려고 본책이지만 깊게 설명한내용이 많아 그냥 넘어간내용도 많다.
실습과 함께 다시 읽어볼 필요도 있음
필요한 부분 참조해서 보면 좋을듯
- 모노리스는 한 전개 단위 안에 모든 컴포넌트가 들어 있는 애플리케이션
- 애플리케이션을 아주 조금 변경헀다고 해도 그 애플리케이션에 들어 있는 다른 부분들이 제대로 작동하는지 알기 위해 아주 큰 회귀 테스트를 돌려봐야한다. 자동화 했다고해도 그런 재귀 테스트는 여전히 거대한 작업이다.
- 모노리스를 계속 유지해야 할지 어떻게 알 수 있을까?
- 회사에 활발하게 개발과 유지보수가 이뤄지는 애플리케이션이 몇 가지밖에 없다.
- 현재 개발팀의 인원이 십여명이라면, 두세 사람으로 구성된 마이크로서비스 팀으로 개발팀을 나누느 것은 아무 이득 없다. (12명이 좋은 예)
- 주중에 여러 번 릴리스할 필요가 있나?
- 애플리케이션의 필요를 충족시키기 위해 서로 통신하는 다수의 마이크로서비스가 존재할 때 마이크로서비스 아키텍쳐가 유용해진다.
- 분산에 신경을 써야하는 이유?
- 서비스가 위치와 무관해진다.
- 서비스가 언어와 무관해진다.
- 서비스 전개 규모가 작고 한 가지 목적을 위해 전개가 이뤄진다.
- 이를 통해 기업은 더 쉽게, 거의 실시간에 준하는 방식으로 비즈니스에 대응할 수 있다.
- 새로운 서비스는 기존 서비스 기능을 재조합하는 방식으로 정의된다.
- JeAS는 애플리케이션 서버와 애플리케이션의 관계를 뒤집어서 애플리케이션 서버의 구성 요소 중 애플리케이션 실행을 위해 필요한 부분만을 패키징한 것
- 꼭 필요한 만큼의 애플리케이션 서버 (Just Enough Application Service)
- ex_ 드롭위자드, 파야라 마이크로, 스프링부트, 손테일 등
- JeAS를 사용하면 마이크로서비스와 함께 사용하기에 꼭 필요한 런타임만을 패키징할 수 있다.
- JuAS 런타임은 RESTFul 마이크로서비스를 전재할 때 최고의 전개방법이다.
- JeAS 런타임을 사용한 이점
- 패키지 크기 감소
- 할당된 메모리 감소
- 보안 풋프린트 감소
- 애플리케이션 분리 증대
- 업그레이드 단순화
- 마이크로서비스 테스트의 핵심은 마이크로서비스가 정의하는 계약, 즉 마이크로서비스가 노출하는 API를 검증하되 마이크로 서비스가 API를 노출하는 의도에 대해서가 아니라 클라이언트가 어떤 요청을 보내고 어떤 응답을 받을 것으로 예상하는지에 대해서 검증하는 것이다.
- IaaS, 인프라 제공서비스 (Infra as a Service)
- 보통 가상 머신을 게스트로 실행할 수 있는 하이퍼바이저를 포함한다.
- PaaS, 플랫폼 제공서비스 (Platform as a Service)
- Iaas 위에서 운영체제, 다양한 프로그래밍 언어에 대한 실행환경, 데이터베이스, 웹 서버를 제공하는 계층
- SaaS, 소프트웨어 제공서비스 (Software as a Service)
- 애플리케이션의 일부분이나 전체 애플리케이션을 사용자의 필요나 요청에 따라 제공
- 컨테이너를 사용하면 애플리케이션이나 서비스를 사용할 운영체제와 함께 패키지로 만들 수 있다. 이때 필요한 소프트웨어 설정도 컨테이너에 들어가는 운영체제에 포함시킬 수 있고, 전통적인 가상머신에 비해 만들어지는 이미지의 크기도 작아질 수 있다.
- 클라우트 네이티브 개발은 클라우드 환경에서 전개할 것을 전제로 서비스나 애플리케이션을 개발하는 것을 뜻한다.
- 미니시프트는 로컬 컴퓨터에서 오픈시프트를 사용하는 클라우드 환경을 제공한다. 따라서 여러 기계를 관리할 필요 없이 마이크로서비스를 실행하고 테스트하는 과정을 단순화할 수 있다.
- JAX-RS 클라이언트 라이브러리를 사용하면 RESTful 마이크로서비스에 연결할 때 필요한 저수준 HTTP 연결에 대해 신경쓰지 않고 꼭 필요한 메타데이터에 집중할 수 있다.
- 클라이언트측 부하 균일화 : 클라이언트가 어떤 마이크로서비스를 소비할지 결정하는 책임을 지는 경우
- 서비스 발견 : 실행 시점에 한 마이크로서비스가 소비할 것을 목적으로 다른 마이크로서비의 물리적 위치를 얻을 수 있는 수단을 뜻한다.
- 소비할 마이크로서비스의 위치를 포함하는 코드는 인스턴스가 새로 시작되거나 끝나면 잘못될 가능성이 있다. 마이크로서비스의 위치가 바뀐 경우 코드나 설정을 변경해야하고, 그런 변경의 영향이 미치는 여러 환경에 다시 전개해야하는 코드에서도 실패가 일어날 수 있다. 서비스 발견을 통해 마이크로서비스가 직접 IP환경을 다루지 않고도 축소나 확장을 할 수 있도록 다른 마이크로서비스의 위치를 코드와 분리할 수 있다.
- 히스트릭스 : 지연시간과 내고장성을 위한 라이브러리로 원격 시스템, 서비스, 라이브러리에 대한 접근 지점을 격리시키고, 연쇄적인 샐패를 중단시키면, 분산시스템에 탄력성을 부여하려는 목적으로 만들어졌다.
- 분산 아키텍처에 마이크로서비스를 전개할 때 지연시간이나 고장을 견딜 수 있는 내고장성을 갖추는 것이 중요하다.
- 마이크로서비스를 소비하는 코드를 히스트릭스로 감싸서 폴백, 요청캐시, 벌크헤드와 같은 내고장성 기능을 추가할 수 있다.
- 마이크로서비스의 보안 측면에서 인증과 권한부여가 가장 중요한 부분이다.
- 아파치 카프카 : 분산 스트리밍 플랫폼. 카프카는 단일데이터 스트림에 속하는 데이터를 클러스터상의 여러서버에 분할해 처리할 수 있다. 추가로 내고장성을 위해 분할된 각 부분을 서버 사이에 복제할 수 있다.