MSA 전환

모노리식 → MSA 전환 대형 서비스에 적합하지만, 현재 프로젝트가 그런 서비스라고 가정!하고 전환을 시작. 각 비지니스 로직을 분리해 개별 프로젝트로 생성. 제일 앞단에 API Gateway (분배기) 통해 서버 요청 분산 관리할 수 있다. 장점 서비스별 각각 스케일링이 가능 스케일 업 : 업그레이드! 사양을 업그레이드 스케일 아웃...

Eureka 서버 역할 MSA 구성하는 모든 서비스 모니터링 역할 뿐 아니라 현재 존재하는 마이크로 서비스 목록 gateaway에 알려줘 원활한 스케일 아웃 동작 하도록. msa는 컨테이너들이 자동으로 스케일 아웃 스케일 아웃으로 새로 생긴 서버는 S

Spring Cloud Gateway MSA 가장 앞단에서 클라이언트로부터 오는 요청 알맞게 각 서비스에 전달 항상 무중단 상태로 모든 요청 받아야 함. 특성 이전의 스프링부트, Eureka, Config 들은 블로킹 기반 → 모두 톰캣 엔진. But 게이트웨

현재 서비스는 모노리식 아키텍쳐로 구성되어 있고, 8개의 도메인으로 구성되어 있다. monolithic 아키텍쳐에서 microservice 아키텍쳐로 전환을 할 계획이다. 해당 도메인 하나 당 서버를 하나 만드는 것이 아닌, 비슷한 성격을 가진 도메인 별로 묶어서 3

동시성 문제 monolithic 구조에서는 동시성 문제 해결을 위해 synchronized를 사용하였다. synchronized는 하나의 프로세스 안에서만 보장이 되기 때문에, 서버를 1대 사용하였던 monolithic 구조에서는 문제가 없었다. 하지만 MSA 환경에

용어 이미지 : 서비스 운영에 필요한 서버 프로그램, 소스코드, 라이브러리, 컴파일된 실행 환경 모두 묶은 것. 즉 컨테이너 실행 위한 모든 파일과 설정값(환경) 컨테이너 : 앱이 구동되는 환경까지 모두 감싸서 실행하게 하는 격리 기술. 이미지로 컨테이너 생성 컨테

Hexagonal Architecture