knowledge

Wiki

• API Gateway — 모든 요청이 지나는 단일 현관서비스가 수십 개로 쪼개지면 클라이언트는 그 주소를 다 알아야 하고, 인증·CORS 같은 공통 처리가 서비스마다 중복된다. 모든 외부 요청을 받아 적절한 서비스로 넘기는 단일 입구 — API Gateway가 무엇을 대신해 주는지 따라간다백엔드MSA네트워크→
• Config Server — 흩어진 설정을 한 곳에서 뿌리기DB 주소·키·플래그가 서비스마다 흩어지면, 값 하나 바꾸는 데 전부 재배포해야 한다. 설정을 중앙에 모아 각 서비스에 내려보내는 Config Server가 무엇을 풀어주는지, 부팅 시점의 흐름과 갱신·암호화까지 따라간다백엔드MSASpring→
• Eureka — 서비스들이 서로를 이름으로 찾는 전화번호부서비스가 수시로 죽고 살아나고 늘어나는 환경에서, IP를 코드에 박으면 곧 깨진다. 서비스가 자기 위치를 등록하고 서로를 이름으로 찾게 해주는 서비스 디스커버리 — Eureka의 등록·발견·헬스체크 흐름을 따라간다백엔드MSASpring→
• 메시지 큐(MQ) — 서비스를 직접 부르지 않고 메시지로 잇기서비스가 서로를 직접 호출하면 상대가 느리거나 죽을 때 같이 무너진다. 사이에 큐를 두면 보낸 쪽은 던지고 떠나고, 받는 쪽은 자기 속도로 처리한다. 비동기 메시징의 원리와, 대표 구현인 Kafka가 무엇이 다른지까지 따라간다백엔드MSA데이터→
• SAGA — 여러 서비스에 걸친 일을 어떻게 '한 번에' 처리할까DB 하나면 트랜잭션으로 '전부 되거나 전부 안 되거나'가 공짜였다. 주문·결제·재고가 각자 다른 DB로 쪼개지면 그 보장이 깨진다. 중간에 실패하면 앞서 한 일을 되돌리는 보상 트랜잭션 — SAGA 패턴을 따라간다백엔드MSA데이터→
• Spring Cloud — 흩어진 서비스를 하나처럼 묶는 도구 모음서비스를 여러 개로 쪼개면 생기는 공통 문제들 — 설정 관리, 서로 찾기, 입구 통일, 장애 격리 — 을 스프링이 한 묶음으로 풀어주는 게 Spring Cloud다. 각 조각이 무슨 문제를 맡는지 지도부터 그려본다백엔드MSASpring→