Dev.99_tale 님의 블로그

4. [민수님] Saga (2) + 마지막 비교Saga 코레그로피 정의 및 개념코레그래피의 장단점활용 주문을 예를 들어서코드로 표현 (예제 중하나)시각화마지막 비교 ( Saga1 vs Saga2)혹시 모르니 추가마이크로서비스의 독립적인 분산 트랜잭션 처리를 지원하는 패턴이 바로 사가(Saga) 패턴이다. 사가 패턴은 각 서비스의 로컬 트랜잭션을 순차적으로 처리하는 패턴이다. 사가 패턴은 여러개의 분산된 서비스를 하나의 트랜잭션으로 묶지 않고 각 로컬 트랜잭션과 보상 트랜잭션을 설정해 비즈니스 및 데이터 정합성을 맞춘다. 즉 로컬 트랜잭션은 자신의 데이터를 업데이트 한 다음 사가 내에 다음 로컬 트랜잭션을 업데이트 하는 트리거 메시지를 게시해서 정합성을 맞춘다. 다른 트랜잭션이 실패해서 롤백이 필요한 경우..

트랜잭션이란?트랜잭션(Transaction)은 데이터베이스에서 하나의 작업 단위를 의미하며, 다음의 4가지 특성(ACID)을 만족해야 합니다.Atomicity (원자성): 모두 성공하거나 모두 실패해야 함Consistency (일관성): 트랜잭션 전후 상태가 데이터베이스 규칙을 위배하지 않음Isolation (격리성): 동시에 수행되는 트랜잭션들이 서로 간섭하지 않음Durability (지속성): 트랜잭션이 성공하면 그 결과는 영구히 저장됨단일 DB vs 분산 트랜잭션 비교구분단일 DB 트랜잭션분산 트랜잭션구조하나의 DB에 의존여러 DB, 여러 마이크로서비스장점ACID 쉽게 보장 가능MSA 구조에 적합단점서비스 분리 어려움성능 저하, 복잡성 증가트랜잭션 방식DB 자체 트랜잭션2PC, SAGA, 이벤트 기..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업✅ 각자 맡은 모듈 개발 진행 금일 작업 ✅ 금일 작업 내용 ✅ JIRA 사용법 숙지이슈 클릭 후 시작 기간, 작업 기간 체크이슈 막대를 링크 연결하여 진행 상황 시각화하위 이슈로 작업 시 보드 라인에 표시되지 않음 참고✅ COMMON 공통 모듈 역할 정리API 응답 표준화 → CommonResponse를 통해 일관된 성공/실패 응답 반환Spring Security 기반 사용자 인증 → CustomUserDetails 사용 (UUID 기반 사용자 식별)JPA 감사 기능 → JpaAuditingConfig 및 UserAuditorAware 활용하여 @CreatedBy, @LastModifiedBy 자동 ..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업✅ 각자 맡은 모듈 개발 진행 금일 작업✅ 본인 상황 공유 진행 현황🔹 수연📌 담당 도메인: Order, Delivery, Shipper도메인별 필요한 파일 구성 완료 (아주 기본적인 구조만 잡아둠)모든 로직을 디테일하게 수정해야 함예) QueryDSL(검색), FeignClient(타 도메인 요청/응답) 등의 구현 필요필요하면 각 도메인별 브랜치(feat/order, feat/delivery, feat/shipper)에 push 예정 (현재는 commit만 진행)📌 FeignClient 활용 - 타 도메인 요청사용자 정보 필요shipper → hub, userorder → company, pro..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업✅ 초기 개발 셋팅 금일 작업✅ 본인 상황 공유✅ 각자 맡은 부분 (FeignClient 제외하고) 개발 진행 📦 application ├── 📂 dtos │ ├── 📂 request │ ├── 📂 response ├── 📂 exception📦 domain ├── 📂 entity ├── 📂 repository │ ├── JpaRepository📦 infrastructure📦 presentation ├── 📂 controller 전체 조회 및 검색 기능전체 조회: 기존 API URL 사용 → /api/v1/shippers검색 기능 추가: 파라미터 방식 적용 → /api..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업✅ API 명세서 작성 완료✅ 테이블 명세서 완료✅  ERD 설계 완료✅ 인프라 설계 완료✅ JIRA 활용 및 이슈 구성 결정 금일 작업✅ 초기 개발 셋팅 MSA 설계에 맞춰 멀티모듈 구조 설정프로젝트의 최상위 루트를 설정하고, 공통 모듈(common)을 분리하여 관리공통 모듈(common) 셋팅 및 주요 논의 진행각 모듈이 공통적으로 사용할 기능을 common 모듈에 포함디렉토리 및 주요 구성 요소:configJpaAuditingConfig : JPA 감사(Auditing) 기능 설정QueryDslConfig : QueryDSL 설정SwaggerConfig : API 문서 자동화를 위한 Swagger..

클라이언트 사이드 로드 밸런싱 개요4. 로드 밸런싱이란로드 밸런싱은 네트워크 트래픽을 여러 서버로 분산시켜 서버의 부하를 줄이고, 시스템의 성능과 가용성을 높이는 기술서버 간 트래픽을 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지종류클라이언트 사이드 로드 밸런싱, 서버 사이드 로드 밸런싱4.1 클라이언트 사이드 로드 밸런싱이란클라이언트가 직접 여러 서버 중 하나를 선택하여 요청을 보내는 방식클라이언트는 서버의 목록을 가지고 있으며, 이를 바탕으로 로드 밸런싱을 수행4.2 FeignClient란Spring Cloud에서 제공하는 HTTP 클라이언트로, 선언적으로 RESTful 웹 서비스를 호출할 수 있음Eureka와 같은 서비스 디스커버리와 연동하여 동적으로 서비스 인스턴스를 조회하고 로드 밸런싱..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업 ✅ 발제 숙지팀 편성 완료✅ 각 도메인 선정✅  S.A산출물 작성✅  깃허브 프로젝트 셋팅 금일 작업✅ S.A 산출물 결정 및 제출1️⃣ API 명세서시스템이 제공하는 기능과 API 엔드포인트를 정의한 문서주요 내용각 기능별 HTTP 메서드 (GET, POST, PUT, DELETE, PATCH)엔드포인트 경로 (/api/v1/orders, /api/v1/deliveries 등)필요한 권한 (MASTER, HUB, COMPANY, DELIVERY)요청 및 응답 데이터 구조각 도메인별로 APIUser, Company, Product, Order, Hub, Devlivery, Shipper, Delive..

API 명세서 https://teamsparta.notion.site/API-1b22dc3ef5148002b6ceccd511db7b16 API 명세서 | NotionRole : MASTER HUB DELIVERY COMPANYteamsparta.notion.site 테이블 명세서 https://teamsparta.notion.site/1b32dc3ef514801cb66bfa79b378ee89 테이블 명세서 | Notion테이블 명세서 예시teamsparta.notion.site  ERD 명세서https://teamsparta.notion.site/ERD-1b32dc3ef51480e6b87bf08137c4e3e5  ERD 설계 | Notionhttps://www.erdcloud.com/d/r73ruMAQf..

어제 작업, 금일 작업, 내일 작업장소 : ZEP 참여자 : 정민수, 이수연, 정아현, 박준혁 어제 작업✅ 팀 구성 및 기초 작업팀 편성 완료각 팀원 자기소개 진행팀장 선정팀명 선정✅ 협업 도구 및 개발 환경 설정노션(Notion) 구조 설계Git / Code 컨벤션 작성JIRA 구조 틀 설정깃허브(GitHub) 구현슬랙(Slack)과 깃허브 연동금일 작업✅ 발제 숙지 ✅ 각 도메인 선정정민수사용자(User)API Gateway이수연주문(Order)배송(Delivery)배송 담당자(Shipper), +(Delivery Channel)정아현업체(Company)상품(Product)박준혁허브(Hub),메시지(Message)AI API✅  S.A산출물API명세서 작성테이블 명세서 작성ERD 설계인프라 설계✅  ..