마이크로서비스패턴

개발이 간단 : 단일 애플리케이션 구축에 초점쉽게 변경 : 코드 db스키마 변경 빌드 배포 용이 (규모가 작을때 아닐까..?)테스트 하기쉽다 : 이것도 규모가 작을때배포 확장이 쉬움 -> 로드 밸런서를 이용해 인스턴스 여러개하지만 사이즈가 점점 커지면서 구현 스토리 늘

핵심 사상은 기능 분해 잘게 쪼개보자? 여러 서비스로 구성하자!어느정도 크기로 분해해야 될까..소프트웨어 아키텍처가 뭔지부터... 아키텍처가 중요한 이유는 \~~ 성으로 끝나는 지표가 아키텍처에 의해 결졍됨확장성, 신뢰성 보안... 이제는 신속 안전 소프트웨어 전달어렵

스타일일대일 : 각 클라이언트 요청은 한 서비스가 처리 일대다: 각 클라이언트 요청을 여러 서비스가 협동 처리일대일 상호작용요청/응답 (동기) 비동기 요청 응답 단방향 알림일대다 상호작용발행/구독발행/비동기 응답여러 스타일 상호 작용을 조합해 사용 가능함서비스 API를

트랜잭션 관리의 복잡성단일 DB 모놀리식 애플리케이션: 간단한 트랜잭션 관리다중 DB, 다중 서비스 환경: 복잡한 트랜잭션 관리 필요분산 트랜잭션의 필요성1.마이크로서비스 환경에서 여러 서비스의 데이터 일관성 유지 필요예: createOrder() 작업에서 여러 서비스