SOA vs MSA

Soa는 서비스의 플로우가 중요하기 때문에 숙박/여행단위로 구분하고 두 서비스의 예약을 공통화 하여 공유할수 있으며 ~msa도 서비스 중심이나 서비스내 기능의 구분및 독립이 중요하기때문에 숙박자와 여행자는 다르며 예약자체의 서비스로 구분하고 도메인의 구분을 다시해 숙박예약과 여행예약으로 경계 구분하는것을 의미할듯합니다.

그래서 soa에서는 여행팀/숙박팀에서 공통db/모듈화를 준수하며 결제/예약등을 다하지만 msa에서는 예약팀에서 여행예약/숙박예약기능을 서비스개발팀에 제공하는 형태일것같습니다. 이렇게 됨으로 서비스개발팀은 검색전문팀의 검색기능도 사용하고 AI 팀의 추천기능도 이용하게 되는것 같습니다. 물론 이러한 전문팀이 없다면 pass를활용해 독립적인 전문 기능을 별도로 이용할수도 있어보입니다.

팀과 저장소 경계를 구분하는 방법은 DDD의 BondedContext편에서 MSA에서 도움되는 구체적인 방법과 전략및 구현체에서도 도움될것으로 보입니다. ( 책은 선박하물 시스템을 예로 구현체가 존재합니다.)

추가참고링크 : https://wiki.webnori.com/plugins/servlet/mobile?contentId=47513616#content/view/47513616

안녕하세요, 이도원입니다.

SOA와 MSA 모두 서비스를 중심으로 설계됩니다. 다만, 서비스라는 기준이 각각의 아키텍쳐에서 다르게 적용되는데, 일반적으로 서비스의 크기, 재사용 방식, 서비스의 스펙과 통신 규격, 개발 방법에 따라 구분될 수 있습니다. 가장 쉽게는 서비스의 재사용 범위 및 데이터의 공유 여유와 서비스가 갖는 경계(크기)를 가지고 구분할 수도 있습니다. MSA에서는 서비스의 개발/빌드/배포가 다른 서비스의 영향을 최소화할 수 있도록 종속성을 줄이려고 합니다. 이렇게 서비스들의 세분화가 이뤄지고 경계 부분이 종속성을 최소화하면서 분리되면, MSA에서 말하는 장점을 충분히 살릴 수 있지만, 반대로 서비스 간의 잦은 호출로 인해 네트워크 트랙픽이 증가하고, 서비스 구현에 어려움이 생길 수 있고, 분리 된 서비스간의 이슈 트랙킹을 하기 까다로울 수도 있습니다. 따라서, MSA 도입을 위해 Pros/Cons를 도입하려는 충분히 고려하고, 서비스의 분리 여부 및 경계를 설정하거나 도입여부를 재고려 하는 것도 필요할 수 있습니다.

MSA Pros & Cons

• Pros

  • Loose coupling

  • Knowledge maintenance

  • Less undesirable change

  • Limited tech stack

  • Easy to scale

• Cons

  • Network latency

  • Reduced availability

  • Data consistency

  • Object design complexity

추가 질문사항 있으시면 다시 글 남겨 주세요.

감사합니다.