본문 바로가기

MicroService Architecture

 (10)
마이크로 서비스 설계 시 주의 사항 올바른 마이크로 서비스 세분화광범위하게 시작하고 더 작은 서비스로 리팩터링→ 모든 것을 마이크로 서비스로 만들어 버리는 것을 주의서비스 간 교류하는 방식에 중점문제 도메인에 이해가 깊어지면서 서비스 책임이 계속 변화 나쁜 마이크로 서비스의 징조책임이 너무 많은 서비스다수 테이블에 걸쳐 데이터를 관리하는 서비스마이크로 서비스는 자기가 관리하는 데이터에 대한 기록여러 테이블에 데이터를 유지하거나 서비스의 데이터베이스 외부에 있는 테이블에 접근하면 서비스가 너무 크다는 징조마이크로 서비스는 3~5개 이하의 테이블 소유 권장→ 이보다 많으면 서비스가 너무 많은 책임을 담당할 가능성 ↑테스트가 너무 많은 서비스서비스가 적은 수의 테스트 케이스로 시작해서 수백 개의 유닛 테스트와 통합 테스트로 끝나는 서비스가 있다..
모놀리식 아키텍처 vs 마이크로 서비스 아키텍처 모놀리식 아키텍처단일 코드 베이스의 애플리케이션모든 개발자가 코딩을 처음 시작할 때 시작하는 방식 (보편적)모든 서비스가 한 데이터 베이스 안에 존재 마이크로 서비스 아키텍처애플리케이션을 작은 서비스로 분할하여 각 서비스가 서로 독립적(느슨한 결합)이라 기술에 구애받지 않음각각의 서비스는 각각의 고유한 데이터베이스를 소유 모놀리식 아키텍처 장단점장점단점단순성→ 모든 코드가 단일 베이스→ 변경 사항 발생 시 모든 코드가 한 곳에 존재애플리케이션의 규모가 커질 경우 유지보수 어려움간편한 배포→ 단일 프로젝트로 배포유연하지 않은 확장성→ 애플리케이션의 특정 부분 요청 시 해당 부분만 확장할 수 없고 전체 애플리케이션 확장보편성→ 대부분의 개발자가 경험대규모 팀 작업이 어려움→ 모든 팀이 동일한 코드, 동일한 ..

티스토리툴바