📦 Order-service

🔖 서비스 개요

• 주제: 주문 처리 및 이벤트 발행 전담 마이크로서비스
• 주요 역할:
  • 사용자 주문 요청 수신, 검증, 처리
  • 주문 상태 생성, 저장, 관리
  • User 서비스와 gRPC 통신으로 사용자 잔액 및 보유 종목 실시간 검증
  • RabbitMQ 통한 비동기 이벤트 발행 및 수신 (주문 생성, 체결 결과 등)
  • Company 서비스 연동, 회사(종목) 코드 및 관련 정보 조회 활용
  • 체결 결과 기반 거래 내역 생성 및 관리

🔗 주요 기능

1️⃣ 주문 생성 및 처리

• 사용자 주문 요청 API 수신
• 주문 가격 유효성 검증 (예: 전일 종가 기반 호가 범위)
• User 서비스에 사용자 자산(잔액, 보유 주식) 검증 요청 및 결과 반영
• 검증 완료 후 주문 데이터 생성 및 초기 상태로 DB 저장

2️⃣ 주문 데이터 관리

• 주문 정보 DB 저장 및 관리
• Matching 서비스의 체결 결과 비동기 수신 후 주문 수량, 상태 실시간 업데이트 (부분 체결, 전체 체결 등)

3️⃣ 주문 검증 및 이벤트 발행

• User 서비스와 gRPC 통신, 사용자 매수/매도 주문 필요 자산 실시간 검증
• 최종 검증 성공 시, order.created 이벤트 RabbitMQ 발행 (Matching 서비스 인지 및 매칭 프로세스 시작)

4️⃣ 체결 결과 수신 및 반영

• Matching 서비스의 체결 결과 이벤트 RabbitMQ 통해 비동기 수신
• 수신 정보 기반 주문 상태 업데이트, 거래 내역 생성 및 저장

5️⃣ 회사 정보 조회 및 활용

• Company 서비스 연동, 주문 대상 종목 상세 정보 조회 (회사 코드 기준)
• 조회 정보 주문 처리 시 유효성 검증 및 기타 로직에 활용

6️⃣ 거래 내역 관리

• 주문 최종 체결 시 상세 거래 내역 생성 및 DB 기록
• 다양한 조건별 체결 거래 내역 조회 기능 제공

---

🌏 주문 시퀀스

---

🧱 시스템 전환 요약

항목	변경 전 (모놀리식 가정)	변경 후 (마이크로서비스)
구조	단일 서버 내 모듈	분산 서버 (User/Order/Matching 등)
통신 방식	내부 메서드 호출	gRPC (동기) + RabbitMQ (비동기 메시지 큐)
동기/비동기 처리	대부분 동기 처리	주문 생성 동기, 체결 및 후속 처리 비동기
ID 생성 방식	RDBMS AUTO_INCREMENT	TSID (분산 고유 ID)
종가 참조 방식	매 요청 시 DB 직접 조회	인메모리 캐시 적용 (서버 시작 시 로드)

---

🌈 개선 사항

1️⃣ 주문 ID 생성 방식 개선 - 저장 공간 절약 및 고속 삽입 성능 확보

📌 문제점 (기존 AUTO_INCREMENT)

• 분산 환경 확장성 저해: ID 충돌 가능성 및 중앙 ID 관리 시스템 도입의 복잡성.
• 성능 병목: 대량 주문 동시 발생 시, DB의 ID 생성 메커니즘 락으로 인한 동시 삽입 처리량 한계.
• ID 예측 가능성: 순차 증가 ID의 보안 취약성.

✅ 해결 (TSID 도입)

• 분산 환경 고유성 보장: 타임스탬프와 랜덤 노드 조합, 여러 서버 동시 생성 시에도 전역적 고유 ID 보장.
• 저장 공간 효율 및 인덱싱 성능 향상: 64비트 정수(Long 타입) 사용, UUID 대비 저장 공간 약 50% 절약, DB 인덱스 크기 감소로 검색/정렬 성능 기여.
• 시간순 정렬 용이: 생성 시간 정보 내포, ID 자체로 시간순 정렬 가능.
• DB 부하 경감 및 삽입 성능 향상: 애플리케이션 레벨 ID 생성, DB ID 생성 부담 감소.

---

2️⃣ 종가 데이터 인메모리 캐싱 적용 - DB 부하 약 24% 감소

📌 문제점

• 반복적인 DB 접근으로 인한 성능 저하: 매 주문 시 전일 종가 DB 조회, 동시 주문 시 불필요한 DB I/O 유발 및 응답 지연.
• DB 부하 가중: 종목 수 증가에 따른 빈번한 DB 조회 누적, 시스템 성능 병목.

✅ 해결 (인메모리 캐싱 전략)

• 서버 구동 시 종가 데이터 캐싱: Order 서비스 시작 시, 전일 종가 데이터 일괄 조회 후 내부 메모리 적재.
• 주문 검증 시 메모리 우선 조회: DB 조회 없이 캐시된 메모리에서 직접 조회, 응답 속도 대폭 향상.
• 데이터 일관성 관리: 일별 고정 데이터 특성 활용, 서버 재시작 또는 배치로 캐시 갱신 전까지 안전 사용.
• DB 부하 약 24% 감소 효과 확인: 주문 처리 속도 향상 및 시스템 안정성 증대.

📉 개선 전 (DB 직접 조회)

📈 개선 후 (인메모리 캐싱 적용)

---

3️⃣ 서버 간 통신 속도 개선 - gRPC 적용으로 응답 시간 단축

📌 문제점 (MSA 전환 후 HTTP/1.1 통신의 한계)

• 높은 연결 수립 오버헤드: 요청마다 TCP 연결 생성/관리 비용, 잦은 통신 시 3-way handshake 누적으로 지연.
• 비효율적 메시지 형식 및 직렬화 비용: JSON 사용 시 바이너리 대비 큰 메시지 크기, 직렬화/역직렬화 CPU 자원 소모.
• 헤더 중복 및 크기: 매 요청/응답마다 큰 헤더 전송, 네트워크 대역폭 비효율적 사용.
• Head-of-Line Blocking: 단일 연결 내 순차 처리로 인한 후속 요청 대기.
• 요청-응답 로직: User-Service에서 잔액/보유 주식을 확인한 후 로직이 진행되어야 해서 양방향 통신은 불가.

✅ 해결 (gRPC 도입)

• HTTP/2 기반 통신 효율 극대화:
  • 멀티플렉싱: 단일 TCP 연결 상 다수 요청/응답 병렬 스트리밍, HOL Blocking 해결, 연결 재사용성 극대화.
  • 헤더 압축: 헤더 정보 압축, 전송 데이터 크기 감소, 네트워크 효율 증대.
• Protocol Buffers 통한 직렬화 성능 향상:
  • 효율적 바이너리 직렬화: JSON 대비 현저히 작은 데이터 크기, 빠른 직렬화/역직렬화 속도.
  • 엄격한 스키마 관리 및 코드 생성: .proto 파일 통한 명확한 인터페이스 정의, 코드 자동 생성으로 생산성 및 타입 안정성 확보.

⏱ 성능 비교

• RestTemplate (HTTP/1.1)

  

• RestTemplate (HTTP/2)

  

  -> HTTP/2의 헤더 압축 시간이 요청 및 body데이터에 비해 너무 오래 걸려 백로그 큐 이상의 요청 -> 요청 거절

• gRPC