1장 추가

Author: mete0rfish

🏗️Architecture/[Book]마이크로서비스패턴/1장 모놀리식 지옥에서 벗어나라.md

@@ -0,0 +1,66 @@
+## 1.1.2 모놀리식 아키텍처의 장점
+- 개발이 간단하다
+- 애플리케이션을 쉽게 변경할 수 있다.
+- 테스트하기 쉽다
+- 배포하기 쉽다
+- 확장하기 쉽다
+
+## 1.1.3 모놀리식 지옥의 실상
+
+단일 소스 코드 저장소, 개발 파이프라인으로 인해 코드 커밋할 때부터 프로덕션 배포까지 큐에 대기된다.
+최근 트렌드는 지속적 배포로, 실제 아마존 닷컴은 2011년 사용자에게 아무 영향 없이 11.6초마다 한 번씩 변경분을 프로덕션에 배포했다. 그러나 모놀리식에선 사실상 불가능하다.
+
+모듈마다 리소스 요건이 서로 맞지 않아 확장하기 어렵다. 음식점 데이터는 인메모리 DB 형태로 저장되어 메모리가 많은 서버가 유리하지만, 이미지 처리 모듈은 CPU Bound 작업이므로 CPU 코어가 많은 서버가 최적이다. 하지만 하나의 애플리케이션이으로 나누는 것이 불가능하다.
+
+신뢰성이 부족하다. 애플리케이션이 워낙크기에 테스트성이 부족하다.
+
+기술 스택이 발전할수록 모놀리식은 마이그레이션하기 어려워진다.
+
+# 1.4 마이크로서비스 아키텍처가 답이다
+유스 케이스는 어떤 아키텍처든 구현이 가능하지만, ~성으로 끝나는 서비스 품질에는 영향을 미친다.
+
+## 1.4.1 확장 큐브와 마이크로서비스
+### X축 확장: 다중 인스턴스에 고루 요청 분산
+부하 분산기를 이용하여 동일한 애플리케이션 인스턴스를 부하분산
+
+### Z축 확장: 요청 속성별 라우팅
+요청의 Authorization: userId:Password에 따라 라우팅할 목적지를 결정.
+동일한 애플리케이션 인스턴스 중 특정 사용자를 라우팅.
+
+### Y축 확장: 기능에 따라 애플리케이션을 서비스로 분해
+서비스는 주문 관리, 고객 관리 등 지엽적 기능이 구현된 미니 애플리케이션
+
+## 1.4.3 마이크로서비스는 모듈성을 갖고 있다
+마이크로서비스 아키텍처는 서비스를 모듈성의 단위로 사용한다. 각 서비스는 다른 서비스가 함부로 규칙을 거이고 침투하지 못하게 API라는 경계선을 갖고 있다.
+
+## 1.4.3 서비스마다 DB가 따로 있다
+마이크로서비스는 서로 API를 통해서만 통신한다. 느슨하게 결합된 서비스는 자체 DB를 갖고 있다.
+런타임에 서비스는 서로 완전히 분리되어 있어, 다른 서비스가 DB 락을 획득해 내 서비스를 블로킹하는 일이 발생하지 않는다.
+
+## 1.4.5 마이크로서비스 아키텍처와 SOA
+| 구분 | SOA        | 마이크로서비스 |
+|:----:|-----------|------------|
+| 서비스 간 통신 | SOAP, WS 처럼 무거운 프로토콜을 통해 엔터프라이즈 서비스 버스 중심의 스마트 파이프 | REST나 gRPC 같은 가벼운 프로토콜로 메시지 브로커 또는 서비스 간 통신 중심의 덤 파이프 |
+| 데이터 | 전역 데이터 모델 및 공유 DB | 서비스 개별 데이터 모델 및 DB |
+| 주요 사례 | 대규모 모놀리식 애플리케이션 | 소규모 서비스 |
+
+# 1.5 마이크로서비스 아키텍처의 장단점
+## 1.5.1 장점
+- 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
+- 서비스가 작아 관리하기 용이하다
+- 서비스를 독립적으로 배포/확장할 수 있다.
+- 결함 격리가 잘된다
+  - 어느 서비스에서 메모리 누수가 발생해도 다른 서비스는 정상 작동
+- 신기술을 시험/도입하기 쉽다
+
+## 1.5.2 단점
+- 딱 맞는 서비스를 찾기가 쉽지 않다
+  - 정해진 알고리즘이 없다
+- 분산 시스템은 복잡하다
+  - 서비스 간 데이터 일관성 유지가 어려움
+  - 여러 서비스가 연관된 테스트를 자동화하기 어렵다
+  - 이를 위해 다양한 플랫폼을 사용해야 한다
+- 여러 서비스에 걸친 공통 기능은 배포할 때 잘 봐야 한다.
+- 도입 시기를 결정하기 어렵다
+
+# 1.6 마이크로서비스 아키텍처 패턴 언어