모 놀리 식 접근법에 익숙하기 때문에 여전히 마이크로 서비스 아키텍처에 대해 머리를 감싸려고합니다.
매우 단순화 된 Uber 예약 시스템 을 구축하려고한다고 가정 합니다. : 일을 단순화하기 위해 우리의 우리가 3 개 서비스 및 클라이언트에 대한 게이트웨이 API가 있다고 가정 해 봅시다 Booking, Drivers, Notification우리는 다음과 같은 워크 플로우를 가지고 :
새로운 예약을 만들 때 :
- 기존 사용자가 이미 예약했는지 확인
- 사용 가능한 드라이버 목록 가져 오기
- 운전자에게 예약 알림을 보냅니다.
- 운전자가 예약을받습니다
모든 메시지가 kafka와 같은 메시징 버스가 아닌 http 호출을 통해 수행되어 간단하게 유지한다고 가정 해 봅시다.
이 경우 Booking서비스가 기존 예약을 확인할 수 있다고 생각했습니다 . 그렇다면 누가 사용 가능한 드라이버 목록과 알림을 받아야합니까? 게이트웨이 수준에서 수행하려고 생각하고 있지만 이제 논리는 두 부분으로 나뉩니다.
Gateway-사용 가능한 드라이버 목록 및 알림 보내기Booking-기존 예약 확인
그리고 게이트웨이가 올바른 장소가 아니라고 확신하지만 Booking서비스 에서 게이트웨이를 사용하고 있다면 밀접하게 연결되고 있다고 생각합니까?
더 복잡하게하기 위해 예약 시스템을 재사용하고 싶지만 자체 비즈니스 로직을 갖춘 다른 프로젝트가있는 경우 어떻게됩니까? 그렇기 때문에 새 프로젝트 게이트웨이가 기존 비즈니스 로직과 별도로 자체 비즈니스 로직을 가질 수 있도록 게이트웨이 레벨에서 수행하려고 생각했습니다.
그것을 수행하는 또 다른 방법은 각 프로젝트에 자체 예약 서비스가있어 핵심 예약 서비스와 대화하는 것이지만 여기서 가장 좋은 방법은 무엇인지 잘 모르겠습니다 :-)
2
전체 상황이 없으면 대답하기가 정말 어렵습니다. 그리고 이것을 아는 것조차도, 마이크로 서비스에 비즈니스 로직을 전파하는 프로젝트를 시작하는 것이 항상 좋은 생각은 아니며 일부 사람들이 "Monolith First"를 채택하는 이유입니다. 너의 어플리케이션. 이것은 나중에 만 명확 해집니다.
—
Dherik