마이크로서비스 아키텍처 구축(전면 개정판)

83

2

장

마이크로서비스 모델링 방법

원해서다. 여러 곳에서 그 행동을 변경해야 한다면 이 변경 사항을 제공하기 위해 많은 다른 서

비스를 (아마도 동시에) 릴리스해야 할 것이다. 여러 곳에서 변경하는 것은 느리고 한 번에 많

은 서비스를 배포하는 것은 위험하므로 두 가지 다 피하고 싶다.

따라서 문제 영역 내에서 관련 동작을 한 곳으로 모으며, 다른 경계와 가능한 한 느슨하게 통신

할 수 있는 경계를 찾길 원한다. 관련된 기능이 시스템 전체에 분산돼 있으면 응집력이 약하다

고 말할 수 있지만, 마이크로서비스 아키텍처는 강한 응집력을 목표로 한다.

2.2.32.2.3

결합 결합

서비스가 느슨하게 결합됐다면 한 서비스를 변경할 때 다른 서비스를 변경할 필요가 없다. 마

이크로서비스의 핵심은 시스템의 다른 부분을 변경하지 않고도 한 서비스를 변경하고 배포할

수 있다는 것이며, 이 점은 매우 중요하다.

그렇다면 어떤 종류가 강한 결합을 유발할까? 이와 관련된 전형적인 실수는 한 서비스를 다른

서비스에 단단히 결합하는 통합 방식을 선택해 서비스 내부가 변경되면 소비자도 변경하도록

요구하는 것이다.

느슨하게 결합된 서비스는 함께 협업하는 서비스들에 대해 꼭 필요한 만큼만 알고 있다. 또한

우리는 한 서비스에서 다른 서비스로 다양한 유형의 호출 수를 제한하려 하는데, 이는 잠재적

인 성능 문제 외에도 과도한 커뮤니케이션이 강한 결합을 초래할 수 있기 때문이다.

하지만 결합은 다양한 형태로 발생되므로 서비스 기반 아키텍처와 관련된 특성을 잘못 이해하

는 ...