신경 써야하는 요소
🔹 응답성 : 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공
🔹 유연성 : 사용량의 변화가 있더라도 균일한 응답성 제공
🔹 탄력성 : 장애 or 고장이 있어도 시스템 전체에 영향 x 빠르게 복구 가능
🔹 메시지 기반 : 비동기 메시기 전달을 통해 위치 투명성,losely coupled, 논 블록킹 토인 지향
위의 3개를 구성요소 및 이들의 관계를 정의
== 마이크로 서비스 외부 아키텍처
실제 비지니스 애플리케이션 즉, 마이크로 서비스의 내부구조
== MAS 내부 아키텍처
마이크로 서비스가 운영되는 환경을 정의
ex)
인프라 : VM , 베어메탈 (SW : X 하드웨어 서버 제품 군 자체),AWS,Azure, google cloud...
플랫폼: 지라 카프카 엘라스틱..., Zuul, hystrix,config server, eureka...
애플리케이션 : 브라우저, 프론트엔드 서비스(ex) BFF), 백엔드 서비스, 데이터.
서비스 디스커버리 패턴은 클라이언트가 여러개의 마이크로 서비스를 호출하기 위해서 최적 경로를 찾아주는 라우팅 기능과 부하 분산을 위한 로드 밸런싱 기능이 제공 되어야 한다.
ex) 넷플릭스 OSS
🔹라우팅 = Zuul(줄),
🔹로드밸런싱 = (Ribbon)
라우터는 최적경로 탐새을 위해 서비스 명칭에 해당하는 IP주소를 알아야함.
클라우드에선 동적으로 변경되는 백엔드의 유동 IP를 매번 전송받아야하기에 직접 받기보단 2제 3의 공간에서 접근하게 하는 것이 좋다.
== 이를 넷플릭스 OSS에선 (Eureka)유레카 라고 하고 이를
즉,
모든 마이크로 서비스는 처음 기동할 때 자신의 위치 정보를 저장, 서비스 종료시 모든 정보를 삭제
마이크로서비스 + 관리& 운영을 위한 기반 서비스 주소 보관
쿠버네티스의 경우 쿠버네티스 DNS & 서비스로 제공
다양한 클라이언트가 다양한 서비스에 접근하기 위해서 단일 진입점을 만들어 두면 복잡한 호출 관계가 만들어지지 않는다.
위와 같은 기능은 HW로도 SW로도 구현이 가능하다.
HW : L4과 같은 하드웨어 장비로 구현 가능,
SW :API 게이트웨이가 Application 레벨의 라우팅을 수행 & 인스턴스 부하 분산하는 로드 밸런싱 수행, 라우팅시 필터를 통해 선행, 후행 ,에러 처리등을 쉽게 구현 가능
제공하는 기능
BFF(Backend For Frontend) : 다양한 클라이언트를 위한 API처리 || 조합
클라이언트 종류에 따라 최적화된 처리 수행가능.
API 게이트 웨어 같은 진입점을 하나로 두지 않음.