개요 :
하나의 서비스가 요청을 전달받고 이를 처리한다.
그런데 이때 요청을 처리하는 과정은 모두 외부 api를 호출해야하는, 즉 외부 서비스와 연동이 필요한 상황이다.
실제로 외부 서비스가 먹통이 된적이 있었고 이때 서비스가 정상 동작하지못해서 서버도 정상 동작이 안되는 상황을 겪었다
그래서 내가 생각한 방법은
- 요청을 전달받는 서비스
- 요청을 처리하는 서비스
두 서비스로 분리시키는것
서비스만 분리시키면 끝인가?
만약 이 경우 서비스간 동기 통신을 수행한다면 a 서비스-> b 서비스로 요청 처리를 부탁하면 a 서비스는 b 서비스에게 응답을 받아야하는데
이때 b서비스가 연결한 외부 서비스가 고장나면?
결국 b 서비스의 실패가 a까지 영향을 끼친다.
따라서 나는 서비스간 의존성을 끊어내고자 중간에 브로커를 고려했다
내가 생각하는 브로커는 중간에서 요청을 전달해주는 역할을 하는 놈인데
이게 왜 필요할까 생각해봤다.
서비스간 의존성이 무엇이고 이를 끊어낸다는게 무엇일까?
내가 생각하는 서비스간 의존성이란 b서비스의 동작 및 변경이 a 서비스까지 영향을 끼친다는것
앞선 상황에서 b 서비스가 외부 api 호출시 문제가 생기는 경우가 존재한다고 했다.
이때 a 서비스와 b 서비스 사이 브로커가 존재한다면?
a 서비스는 자신이 전달받은 요청을 처리해야한다는 메세지를 브로커에 넘기고 자신의 역할은 끝이다.
b 서비스가 망가지더라도 a 서비스는 여전히 브로커에 메세지를 담을 수 있다.
이것이 서비스간 의존성을 끊어낸다는 예시라고 생각할 수 있었다.
추가로 a 서비스도 scale-out / b 서비스도 scale-out 상태인 경우도 존재할 수 있다.
브로커가 없는 경우 a 서비스는 동작중인 모든 b 서비스를 기억해야한다.
b 서비스에 해당하는 서버가 추가되면 a 서비스들은 모두 그 서버를 기억해야하고
b 서비스에 해당하는 서버가 삭제되면 a 서비스들은 모두 그 서버를 제거해야한다.
하지만 브로커가 있는 경우 a 서비스는 모두 브로커만 기억하면 되고 b도 마찬가지다
브로커는 장점만 존재할까?
절대 아니라고 생각한다.
당장 브로커가 고장나면?
단일 장애 지점이 될 수 있다.
당연히 시스템이 추가되는만큼 추가 학습도 필요하다
그리고 그럼 결국 a 서비스는 브로커에 의존하는게 아닌가? 라는 생각도 들었다.
아직 더 공부가 필요하다
서비스간 의존성이란 무엇일까?
서비스만 분리시키면 끝인가?
따라서 나는 서비스간 의존성을 끊어내고자 중간에 브로커를 고려했다
브로커는 장점만 존재할까?