Sidecar pattern
모든 서비스에는 핵심 기능이 있음(서비스의 존재 이유)
ex) 고객 서비스 : 고객 정보 저장
ex) 결제 서비스 : 결제 내역 저장 및 결제 처리 등
하지만, 각 서비는 핵심 기능 외에 다른 기능도 해야함
예를 들면 metric을 모니터링 서비스에 전송한다던지..
구성 파일을 가져와 파싱하고 비지니스 로직에 적용한다던지..
MSA에서는 각기 다른 프로그래밍 언어를 사용할 때가 있는데 이럴 때는 같은 기능을 구현하기 위해 각기 언어에 맞는 다른 Library를 사용해야 함 (확장성이 낮음)
동일한 라이브러리를 다른 언어로 구현하는것은 상호 호환성과 일관성을 떨어뜨림 (데이터 유형 등 차이로 다양한 문제 발생 가능)
이러한 문제를 해결하는것이 Sidecar pattern
애플리케이션에 필요한 추가 기능을 메인 애플리케잇녀과 동일한 서버에 개별 프로세스 (혹은 컨테이너)로 실행
사이드카 프로세스와 메인 프로세스를 분리하는것(같은 서버에서)
개별 프로세스로 사이드카 프로세스를 만들면, 하나의 언어로 사이드카를 만들고 이를 재활용할 수 있음
핵심 서비스의 구현 및 테스트에 집중할 수 있음
(공통 기능 및 기타 기능을 사이드카에 몰아놨으니까)
Ambassador(특사) pattern
ambassador pattern은 sidecar pattern의 special case임
ex)서비스를 대신해 모든 네트워크 활동을 전송하는 사이드카
이 경우 서비스 책임 범위 밖으로 복잡한 네트워크 통신 로직을 빼낼 수 있음
-> 이렇게하면 진짜 핵심 비즈니스 로직만 애플리케이션 프로세스에 남게 됨
모든 서비스의 통신이 같은 위치에 있는 특사 사이드카에서 이루어지므로 쉽게 네트워크 통신 실행 및 분산 추적 가능
결국 핵심은 공통 기능과 핵심 기능의 분리를 코드 레벨이 아닌
아키텍쳐 레벨에서 구현한 것이라 볼 수 있을 것 같다.
(약간 Spring AOP 생각난다.)
