Transaction-Other-Service

MSA 환경에서 다른 서비스간의 통신

설명

MSA 환경에서는 각 서비스에 Connection 되어 있는 DB 도 다르다.

서비스간의 데이터 결합이 완전이 끊긴 상태

클라이언트 요청을 처리하기 위해서, 다른 서비스의 데이터 조회나 처리 또한 필요할 수 있다.

• 반드시 처리되어야 할 경우
  1. 일반적인 API 호출을 통해 조회, 처리 요청한다.
  2. API G/W 등의 layer 를 통할 수 있으므로 성능 저하 등의 문제가 발생 가능하다.
  3. 특정 컨테이너 등을 Service Mesh 라는 G/W 성격의 플랫폼을 통해 보완가능해보인다. Istio(Service Mesh)
• 즉시 처리까지는 필요없는 경우
  1. 주로 다른 서비스의 데이터를 참조할 때 사용
  2. 데이터 변경시점의 Event 정보를 사전에 적재
  3. 클라이언트의 요청에 2.의 데이터를 참조해 해결

Sequence Diagram

주의

두 가지 방법은 Trade-Off 가 있다… 비즈니스나 요청에 따라 구현할 필요가 있어보인다.

반드시 처리되어야 할 경우

• 장점😃
  • 서비스간의 데이터 정합성이 보장될 수 있다
• 단점🧐
  • MSA 임에 불구하고, 서비스간의 의존성이 발생할 수 있다 (물론 비즈니스 처리 수준에서)
  • 마찬가지로 Time out, 장애전파 등의 이슈가 발생가능하다!

---

즉시 처리까지는 필요없는 경우

• 장점😃
  • 클라이언트의 요청을 서비스 단독으로 처리가능하다!
  • 속도도 당연히 빠를것이여..
• 단점🧐
  • 개발이 너무 어렵다..(어렵다기보다 귀찮은 부분이 많아진다.)
  • 데이터 복제에 따른 스토리지 비용이 수반된다
  • Data Sync 처리와, 클라이언트 요청의 시점에 따라 다른 결과값이 나올 수 있다

---

🤨 단순히 생각해보면

데이터 변경이 자주 없는 경우 → “즉시 처리까지는 필요없는 경우”

아니라면 → “반드시 처리되어야 하는 경우”로 실시간으로 처리해도 되지 않을까??..

서비스를 독립적인 비즈니스 운영이 가능하게끔 분리가 불가능하다면, 위의 케이스를 적절하게 섞어서 처리할 수 밖에 없어 보인다…

일단 해보면서, 많이 쓰이는 데이터라면 가져와서 보관하도록 해보자..무책임해도 어쩔 수 없다

• msa
• transaction