앱)마이크로 서비스와 스프링 부트

마이크로 서비스로 진화의 이유
1)비지니스적 요구
전통적인 일체형 애플리케이션에 비해 마이크로서비스는 애자일성, 변경 및 배포 신속성, 확장성 측면에서 더 나은 결과물을 만들어 낼 수 있다
빠르고 애자일한 애플리케이션을 개발하는 접근 방식을 사용해서 전체 소요 비용을 낮출 수 있다
현대적인 아키텍쳐에는 시스템 일부분의 교체 가능성을 극대화하고, 교체에 소요되는 비용은 최소화할수 있는 능력이 있을 것이라고 기대한다. 이에 마이크로서비스방식이 어울린다
2)기술
HTML5와 CSS3의 출현 및 모마일 애플리케이션의 발전으로 사용자 인터페이스의 위상도 바뀌었다
Augular, Ember, Backbone 등과 같은 클라이언트 측 자바 스크립트 프레임워크는 클라이언트 측 렌더링과 반응형 디자인과 함께 인기를 누리고 있다
클라우드의 도입이 대세가 됨에 따라 Docker의 등장은 컨테이너 기술의 급격한 혁신을 불러일으켰다.  최근에는 인프라스트럭처는 구축하는 대상이 아니라 사서 쓰는 상품처럼 인식되고 있다
NoSQL은 데이터베이스 영역의 혁신을 이끌고 있다. 데이터베이스의 종류가 엄청나게 많아졌고 Hadoop, Cassandra. CouchDB, Neo4j등 아키텍처 관점에서의 특수한 문제를 해결하는데 특화되어 있다


마이크로 서비스 복잡한 시스템을 더 작은 여러 개의 서비스로 나눠서 대규모의 비지니스 서비스를 처리하는 아키텍쳐 스타일이나 패턴이다

마이크로 서비스의 특징은
-자율적
-자기 완비적(self-contained) = 스스로 모두 갖춰서 독립성을 지니고 있다는 의미
-독립적으로 배포가능

SOA(Service Oriented Architecture)에서의 서비스들이 갖는 특징 중에서 마이크로서비스에도 적용할 수 있는 특징
-서비스 계약 : SOA와 비슷하게 마이크로서비스도 분명하게 정의된 서비스 계약에 의해 작성, JSON과 REST에 대해서 서비스 계약을 정의하는데 JSON스키마, WADL, Swagger, RAML등의 기법을 사용한다
-느슨한 결합: 마이크로 서비스는 독립적이고 서로 느슨하게 연결돼 있다. 대부분의 경우 마이크로서비스는 이벤트로 입력을 받고 이벤트로 응답한다. 일반적으로 메시징, HTTP, REST가 마이크로서비스 사이에서 커뮤니케이션의 수단으로 사용된다. 메시지 기반의 종단점은 결합도를 낮추는 고수준의 수단을 제공
-서비스 추상화:마이크로서비스에서 서비스 추상화는 단순히 서비스의 구현 실체를 추상화하는 것이라기보다는 앞에서 기술한 것처럼 모든 라이브러리와 제반 환경 전체를 추상화하는 것
-서비스 재사용:마이크로서비스는 덩어리째 재사용 가능한 서비스다. 마이크로서비스는 모바일 디바이스나 데스크탑 채널, 다른 마이크로서비스 또는 아예 다른 외부 시스템에서도 접근가능
-무상태:제대로 설계된 마이크로서비스는 상태가 없으며, 서비스에 의해 관리되는 어떤 공유 상태와도 아무런 정보도 공유하지 않음, 상태를 관리하게 요구 사항이 정의돼 있다면 데이터베이스나 메모리를 이용해서 상태를 관리한다
-서비스발견성:마이크로서비스는 탐색을 통해 찾을 수 있다. 일반적인 마이크로서비스 환경에서 마이크로서비스는 자신의 존재를 스스로 드러내서 알리고, 탐색에 의해 찾아지고 사용될 수 있게 한다. 서비스가 중지되면 마이크로서비스는 자기자신이 소속돼 있던 마이크로서비스 환경에서 스스로를 제거한다
-서비스 호환성:서비스는 표준프로토콜과 메시지 교환 표준을 준수하기 때문에 호환성이 좋다. 전송 메커니즘으로는 메시징이나 HTTP등과 같은 표준 방식을 사용한다. REST/JSON은 마이크로서비스 세상에서 호환성이 좋은 서비스를 개발하는데 가장 널리 사용되는 방법, 커뮤니케이션부분에서 최적화가 필요하다면 Protocol Buffers, Thrift, Avro, ZeroMQ같은 다른 프로토콜을 사용할 수 있다.하지만 이런 비표준 프로토콜을 사용하면 서비스의 전체적인 호환성은 제약을 받을 수밖에 없다
-서비스 조립성:마이크로 서비스는 조립이 가능하다. 서비스 조립성은 서비스 조율(service orchestration)이나 서비스 연출(service choreography)을 통해 확보 가능

대부분의 마이크로서비스는개발과정부터 운영에 이르기까지 전 과정을 최대한 자동화한다
마이크로서비스가 자동화되지 않는다면 관리 부담이 커질수 있다
일반적으로 마이크로 서비스는 빌드 자동화, 테스트 자동화, 배포 자동화, 확장 자동화 등 모든 과정을 자동화한다
-개발단계: Git같은 형상 관리 도구와 Jenkins, Travis CI 등과 같은 지속적 통합 도구를 함께 사용, 이런 자동화 과정에는 코드품질 검사와 단위 테스트 자동화를 포함할 수도 있다. 소스코드를 반영할때 마다 전체 빌드를 자동화하는 것도 마이크로 서비스에서는 가능하다
-테스팅단계:Selenium, Cucumber나 다른 A/B 테스팅 전략을 사용해서 자동화를 적용가능, 마이크로서비스는 단위 비즈니스 영역에 맞춰 만들어지므로, 일체형 애플리케이션에서보다는 자동화해야 할 테스트 케이스의 수가 상대적으로 더 적다. 그래서 빌드할때마다 회귀테스트를 진행하는 것도 가능
-인프라스트럭쳐프로비저닝도 도커와 같은 기술과 Chef 또는 Puppet같은 릴리스 관리 도구, Ansible 같은 구성관리 도구를 함께 사용해서 자동화할 수 있다. 스프링 클라우드, Kubernetes, Mesos, Marathon 같은 도구를 사용하면 배포 자동화도 가능하다.

클라우드 네이티브
:클라우드 환경에서 효율적으로 작동하고, 탄력성, 사용량 기반 과금, 장애 인식 등과 같은 클라우드의 특징을 인식하고 활용할수 있는 애플리케이션을 개발하는 것을 의미

클라우드 운영가능한 애플케이션의 12 요소(heroku제시)

(1번)
단일 코드 베이스
각 어플리케이션이나 하나의 코드 베이스만을 가져야 한다고 권장(하나의 프로젝트 저장소)

(2번)
의존성 꾸러미
모든 애플리케이션은 필요한 모든 의존성을 애플리케이션과 함께 하나의 꾸러미에 담아야 한다

(3번)
환경설정 외부화
-애플리케이션의 환경설정 파라미터는 이메일, ID, 외부시스템의 URL, 사용자 이름, 비밀번호, 큐 이름 등과 같은 것들은 개발, 테스팅, 운영 버전에 따라서도 달라진다. 모든 서비스 환경 설정 정보는 외부화되어야 한다

(4번)
후방 지원 서비스 접근성
모든 후방 지원 서비스는 URL을 통해 접근가능해야 한다
모든 서비스는 살아있는 실행 주기 동안 외부의 자원과 의사소통해야 한다
메일서버, 외부 서비스 등의 후방 지원 서비스는 URL를 통해 접근 가능해야 함

(5번)
빌드, 출시, 운영의 격리
-빌드단계:모든 필요한 자원을 포함해서 컴파일하고 바이너리를 만들어내는 과정
-출시단계:바이너리를 환경설정 파라미터와 혼합하는 과정
-운영단계:특정 실행 환경에서 애플리케이션을 운영하는 것을 말함

(6번)
무상태, 비공유 프로세스
-애플리케이션 상태가 없다면 장애 대응성이 좋고 쉽게 확장가능
상태를 저장해야 하는 요구사항이 있다면 데이터베이스나 인메모리 캐시 같은 후방 지원서비스에서 처리돼야 한다

(7번)
서비스를 포트에 바인딩해서 노출
자기 완비적이어야 한다
외부의 웹서버에 의존하지 않는다
포트 바인딩은 마이크로서비스가 자율적이고 자기 완비적인 특성을 유지하는데 필요한 기본적인 요구 사항 중 하나다

(8번)
확장을 위한 동시성
프로세스가 복제를 통해 확장될수 있게 설계 되야 한다고 권고
이는 프로세스 내부에서 추가적인 스레드를 사용하게 됨을 의미한다

마이크로서비스 세상에서는 서비스가 서버의 자원을 늘리는 수직적 확장이 아니라 서버를 늘리는 수평적 확장방식으로 확장된다
마이크로서비스는 병렬 프로세싱과 동시성 지원 프레임워크를 사용해서 기존 트랜잭션 처리 속도를 높이거나 확장하기도 한다

(9번)
폐기 영향 최소화
애플리케이션의 시동과 종료에 필요한 시간을 최소화하고, 서버가 종료될 때에는 필요한 처리가 모두 수행되는 우아한 방식으로 종료되게 만들어야 한다고 권고한다
자동화된 배포 환경에서는 가능한 빠른 시간안에 인스턴스를 올리거나 내려야 한다.애플리케이션의 시동이나 종료에 오랜 시간이 걸리면 자동화에 부정적인 영향을 미치게 된다
마이크로서비스에서는 완전 자동화를 달성하기 위해 최소한의 시동/종료 시간을 갖게 애플리케이션의 크기를 가능한 한 작게 유지하는 것이 극단적으로 아주 중요하다
이를 위해 마이크로서비스에서는 객체와 데이터의 지연로딩에 대해서도 고려해봐야 한다

(10번)
개발과 운영의 짝 맞춤
개발 환경과 운영 환경을 가능한한 동일하게 유지하는 것이 중요하다고 강조

(11번)
로그 외부화
-로그파일을 절대로 자기 자신 안에 담지 않는다.
중앙집중식 로깅 프레임워크를 사용하는 것
Splunk, Greylog, Logstash, LogPlex, Loggly 등은 로그를 쌓고 분석할 수 있는 도구들이다. 권장되는 접근방식은 로그백 추가자(appender)를 통해 로그를 중앙 저장소에 적재하고, 적재도구의 종단점에 로그를 쓰는 방법이다.


(12번)
패키지 관리자 프로세스
애플리케이션 서비스와 별개로 대부분의 애플리케이션은 관리자 태스크도 함께 제공한다
패키지 관리자 프로세스 원칙은 애플리케이션 서비스와 관리자 태스크 모두에 대해 동일한 환경뿐 아니라 동일한 출시 버전의 꾸러미를 사용하라고 권고한다. 관리자 태스크를 위한 코드로 애플리케이션 코드와 함께 패키징돼야 한다

***마이크로서비스 아키텍쳐가 적용돼도 좋을 후보가 될 수 있는 일반적인 시나리오에 대해 알아보자
-확장성, 유지관리성, 애자일성, 변경 및 배포 속도의 개선이 필요해서 일체형 애플리케이션을 전환하는 경우로, 비슷한 시나리오로는 시대에 뒤쳐져서 수명이 다한 무거운 레거시 애플리케이션을 재작성하는 것이 있다.두가지 경우 모든 마이크로서비스를 적용하기에 적합한 사례라고 할 수 있다.
이런 접근 방식의 장점은 대규모의 선행 투자가 필요없고, 비즈니스에 중대한 악영향을 끼치지도 않으며, 심각한 비즈니스 위험도 없다는 점, 서비스 의존성이 잘 드러나므로, 마이크로서비스의 의존성은 적절하게 관리될 수 있다.
-최적화 서비스, 예보 서비스, 가격 산정 서비스, 예측서비스, 제안 서비스, 추천 서비스 등을 통합하는 유틸리티 컴퓨팅은 마이크로서비스를 적용하기에 적합한 후보군이다.
이런 서비스들은 어떤 데이터를 받아 알고리듬을 적용하고 결과 값을 반환하는 독립적인 무상태 컴퓨팅 단위라고 할 수 있다.
커뮤니케이션 서비스, 암호화 서비스, 인증 서비스등 독립적인 기술 서비스들도 마이크로서비스를 적용하기에 적합하다
-많은 사례에서 태생적으로 자율적이면서 눈에 보이는 화면이 없는 비즈니스 애플리케이션이나 서비스를 만들 수 있다. 예를 들면 결제 서비스, 로그인 서비스, 항공편 검색 서비스, 고객 프로파일 서비스, 알림 서비스 등이다. 이런 서비스들은 다수의 채널에 걸쳐 재사용되므로 마이크로 서비스로 만들기에 적합하다
-하나의 목적과 하나의 책임만을 담당하는 마이크로 또는 매크로 애플리케이션이 있을 수 있는데, 단순한 시간 추적 애플리케이션이 이런 부류에 속한다.이 애플리케이션이 하는 일은 시간, 지속 시간과 수행된 작업을 기록하는 것뿐이다.
이처럼 기업 애플리케이션에 걸쳐 공통으로 사용되는 서비스 역시 마이크로서비스로 만들기에 적합
-제대로 설계된 백엔드서비스, 반응형 웹 MVC애플리케이션(BaaS)은 사용자의 액션에 따라 반응해 언제든지 데이터를 읽을 수 있다.
-높은 애자일성을 요구하는 애플리케이션, 빠른 변경 및 배포 속도나 시장 타이밍에 맞는 애플리케이션, 혁신적인 파일럿, 데브옵스를 위한 애플리케이션, 혁신 체계 유형의 애플리케이션 등도 마이크로서비스 아키텍처를 적용하기에 적합한 잠재적인 후보군이다
-폴리그랏을 요구하는 애플리케이션, CORS(command query responsiblity segregations)를 요구하는 애플리케이션 등 마이크로서비스의 장점을 필요로 하는 애플리케이션도 마이크로서비스 아키텍처로 만들기에 적합


마이크로서비스를 적용하지 않는 시나리오
-비지니스 로직을 ESB같은 무거운 중앙 집중적인 컴포넌트에 관리해야 하는 조직 정책이 존재하거나, 마이크로서비스의 기본 원칙을 실천하는데 방해가 되는 조직 정책이 존재하는 경우에는 조직 프로세스가 순화되기 전에 마이크로 서비스는 올바른 답이 아니다.
-조직의 문화, 프로세스 등이 폭포수 모델, 긴 출시 주기, 복잡한 개발 팀 조직, 수동 배포 및 무거운 출시 절차, 인프라스트럭처 자동 구성 부재 등과 같은 전통적인 방식에 맞춰져 있다면 마이크로서비스를 적용하기 적합하지 않다. 콘웨이 법칙에 의하면 조직의 구조와 그 조직이 만드는 소프트웨어에는 대단히 밀접한 연관성이 있다고 한다

스프링 부트는 자바로 실제로 운영할수 있는 수준의 마이크로서비스를 만들 수 있는 프레임워크다

스프링 부트는 무거운 애플리케이션 컨테이너를 제거하고 가볍고 서버리스한 애플리케이션을 가능하게 했음