<김용욱> 마이크로서비스 아키텍처 구축 가이드: 설계원칙

서비스의 의존관계

• 코드 레벨의 참조
  • 코드 레벨의 참조는 다른 서비스의 API나 이벤트 정의를 따르는 것이다.
  • 참조하는 서비스의 스펙이 변경되면, 자신도 같이 변경되어야 한다. 
• 런타임 레벨 참조
  • 실행 중에 다른 서비스의 API나 이벤트를 호출하는 것이다
  • 런타임 레벨에서 다른 서비스의 기능을 호출한다면, 해당 서비스에 장애가 발생했을 때 영향을 받을 수 있다.

설계원칙

(1) 참조 방향을 역전하자!

코드 레벨의 참조와 런타임 레벨의 참조는 보통 동일한 방향을 가진다. 하지만 코드 레벨의 참조를 역전시키는 경우, 둘의 방향이 반대가 된다. 

예제로 살펴본 참조의 역전: Callback API

callback API가 코드 레벨 참조와 런타임 레벨 참조의 방향이 바뀌는 대표적인 사례이다.
Payment server가 callback API의 인터페이스를 변경하면, Tracker server도 이에 맞게 요청 인터페이스를 변경해야한다. 이렇듯 코드 레벨에서는 Tracker server가 Payment server를 참조한다.
반대로 Payment server가 장애나더라도, Tracker Server에는 장애가 전파되지 않는다. 반대로 Tracker server에 장애가 나면, Payment server에 장애가 전파된다. 이렇듯 런타임 레벨에서는 Payment server가 Tracker server를 참조한다. 

실무로 살펴본 참조 역전 사례

결제 PG사에 webhook api를 등록하고, 이를 호출받는 것을 참조 역전 사례로 볼 수 있다. 다음과 같이 이벤트/요청 스펙을 webhook api를 호출하는 애플리케이션에서 미리 정의한다. webhook api를 구현해야하는 애플리케이션은 PG사에 webhook api을 등록한다. 

토스의 웹훅 연동 가이드:&amp;nbsp;https://docs.tosspayments.com/common/webhook

 

(2) 순환 참조를 피하자!

순환참조는 서비스의 변경을 어렵게 만든다. 서비스가 변경되면, 이를 참조하는 서비스가 변경되어야하고, 또 이를 참조하는 서비스가 변경되어야한다. 
예시 사례를 살펴보자. 이 경우, 서버가 서로 의존하고 있어서, 각 애플리케이션이 같은 날에 동시에 배포 해야한다.

그리고 순환참조가 발생하면, 서로 API를 불필요하게 계속 호출하게 될 수 있다. 

이 경우, 순환 참조를 제거하면 변경을 더 쉽게 할 수 있다. 자신을 참조하는 애플리케이션에 미치는 영향만 신경쓰면 된다.
 

(3) 참조를 적게 받자.

그래야 서비스를 자주 변경할 수 있다.