'크고 작은 모든' 서비스들

• 서비스 지향 아키텍처 / 마이크로서비스 아키텍처가 유행이다.
• 다음과 같은 이유로.
  • 상호 결합이 철저하게 분리된다.
  • 개발과 배포 독립성을 지원한다.
• 그러나 이 두가지 이유는 일부만 맞는 말이다.

서비스 아키텍처란?

💡 시스템의 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로 분리하는 경게에 의해 정의된다.

• 서비스의 역할이 단순히 애플리케이션의 행위를 분리하는 것이라면 값비싼 함수를 호출하는 것에 불과하다.
• 따라서 서비스를 사용한다는 것 자체가 아키텍처를 나타내는 것은 아니다.
• 그렇다면 아키텍처적으로 중요한 서비스는 무엇인가?
  • 어떻게 하면 완벽한 Dev-Ops 가 될 수 있느냐 하는 질문인가..

서비스의 이점?

결합 분리의 오류

• 시스템이 서비스로 분리되면 각각 여러 프로세스 및 프로세서에서 실행되기 때문에, 다른 서비스의 변수에 직접 접근할 수 없다. 따라서 모든 서비스의 인터페이스가 잘 정의되어야 한다. → 이러한 점에서 서비스 사용을 통해 상호 결합이 철저하게 분리될 수 있다고 본다.
  
• 그러나 프로세서 내의 또는 네트워크 상의 공유 자원 때문에 결합될 가능성이 여전히 존재한다. 오히려 서로 공유하는 데이터에 의해 이들 서비스가 강력히 결합되기도 한다.

개발 및 배포 독립성의 오류

• 대규모 엔터프라이즈 시스템을 독립적으로 개발하고 배포 가능한 수십, 수백, 수천 개의 서비스들을 이용하여 만들 수 있다. 이러한 개발 및 배포 독립성은 확장 가능한 것으로 간주된다.
• 그러나,
  • 첫째로 대규모 엔터프라이즈 시스템은 서비스 기반 시스템 이외에도, 모노리틱 시스템이나 컴포넌트 기반 시스템으로도 구축할 수 있다는 사실은 역사적으로 증명되어 왔다.
  • 둘째 결합 분리의 오류에 따르면 서비스라고 해서 항상 독립적으로 개발하고, 배포하며, 운영할 수 있는 것은 아니다.

야옹이 문제

• 택시 통합 시스템이 아래와 같이 각각의 서비스별로 나뉘어 개발 운영되고 있다고 생각해보자.

이미지 출처 : https://hwannny.tistory.com/46

• 그러나 여기서 야옹이 배달 서비스를 제공하겠다고 한다면 어떻게 될까?
• 이 서비스들은 모두 결합되어 있어서 새로운 기능을 추가하기가 매우 어려움.

객체가 구출하다

• 이 문제는 컴포넌트 기반 아키텍처에서 해결 가능하다.
• 다형적으로 확장할 수 있는 클래스 집합을 생성해 새로운 기능을 처리하도록 하는 것이다.

컴포넌트 기반 서비스

• 서비스도 SOLID 원칙대로 설계할 수 있으며 컴포넌트 구조를 갖출 수도 있다.
• 이를 통해 서비스 내의 기존 컴포넌트들을 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다.

횡단 관심사

• 횡단 관심사를 처리하려면 다이어그램처럼 서비스 내부의 의존성 규칙을 준수하는 컴포넌트 아키텍처로 설계되어야함.
• 아키텍처경계는 서비스 사이에 존재하지 않으며, 아키텍처 경계를 정의하는것은 서비스 내에 위치한 컴포넌트임.