아키텍처 스타일 선택(2부)

안녕하세요, 하브르님. 오늘 나는 새로운 과정의 시작을 위해 특별히 쓴 일련의 출판물을 계속합니다. "소프트웨어 아키텍트".

소개

아키텍처 스타일의 선택은 정보 시스템을 구축할 때 기본적인 기술적 결정 중 하나입니다. 이 기사 시리즈에서는 애플리케이션 구축에 가장 널리 사용되는 아키텍처 스타일을 분석하고 어떤 아키텍처 스타일이 가장 선호되는지에 대한 질문에 답할 것을 제안합니다. 프레젠테이션 과정에서 모놀리스에서 마이크로서비스까지 아키텍처 스타일의 발전을 설명하는 논리적 사슬을 그려보려고 합니다.

В 지난 번에 우리는 모놀리스를 다루었고 모놀리스에는 크기, 연결성, 배포, 확장성, 신뢰성 및 강성 등 여러 가지 문제가 있다는 결론에 도달했습니다.

이번에는 시스템을 모듈/라이브러리(구성 요소 지향 아키텍처) 또는 서비스(서비스 지향 아키텍처) 집합으로 구성하는 가능성에 대해 이야기하겠습니다.

구성요소 지향 아키텍처

구성 요소 지향 아키텍처에는 현재 및 미래 프로젝트 모두에서 사용할 수 있는 구성 요소 집합으로 시스템을 실행하는 작업이 포함됩니다. 시스템을 구성요소로 나눌 때 재사용성, 교체성, 컨텍스트 독립성, 확장성, 캡슐화 및 독립성 등이 고려됩니다.

구성 요소를 올바르게 사용하면 "큰 먼지 덩어리"(큰 크기 + 높은 결합도) 문제가 해결되고 구성 요소 자체가 조립 단위(모듈, 라이브러리)이자 배포 단위(서비스)가 될 수 있습니다. 배포 단위가 항상 실행 중인 프로세스에 매핑되는 것은 아닙니다. 예를 들어 웹 애플리케이션과 데이터베이스는 함께 배포됩니다.

대부분의 경우 모놀리스는 모듈 세트로 개발됩니다. 이 접근 방식은 독립적인 개발로 이어지지만 독립적인 확장 및 배포, 내결함성 및 전체 기술 스택으로부터의 독립성의 문제가 남아 있습니다. 이것이 바로 모듈이 부분적으로 독립적인 구성 요소인 이유입니다.

이러한 단일체의 가장 큰 문제점은 모듈로의 분할이 순전히 논리적이며 개발자가 쉽게 위반할 수 있다는 것입니다. 점차적으로 가비지 덤프로 변하는 핵심 모듈이 나타날 수 있으며, 모듈 간의 종속성 그래프가 커질 수 있습니다. 이러한 문제를 피하기 위해 개발은 매우 성숙한 팀에 의해 수행되거나 풀타임 코드 검토에 참여하고 논리적 구조를 위반하는 개발자의 손을 이기는 "설계자"의 지도하에 수행되어야 합니다.

"이상적인" 모놀리스는 논리적으로 분리된 모듈 세트로, 각 모듈은 자체 데이터베이스를 살펴봅니다.

서비스 지향 아키텍처

시스템이 일련의 서비스 형태로 구성되어야 한다면 서비스 지향 아키텍처에 대해 이야기하고 있습니다. 그 원칙은 사용자 중심 애플리케이션 상호 운용성, 비즈니스 서비스 재사용, 기술 스택 독립성 및 자율성(독립적 진화, 확장성 및 배포)입니다.

서비스 지향 아키텍처(SOA = 서비스 지향 아키텍처)는 확인된 모놀리스의 모든 문제를 해결합니다. 변경이 발생할 때 하나의 서비스만 영향을 받으며, 잘 정의된 API는 구성 요소의 우수한 캡슐화를 지원합니다.

그러나 모든 것이 순조롭게 진행되는 것은 아닙니다. SOA는 새로운 문제를 야기합니다. 원격 호출은 로컬 호출보다 비용이 더 많이 들고 구성 요소 간 책임을 재분배하는 데 훨씬 더 많은 비용이 듭니다.

그런데 독립적인 배포 가능성은 서비스의 매우 중요한 기능입니다. 서비스를 함께 배포해야 하거나 특정 순서로 배포해야 하는 경우 시스템은 서비스 지향적인 것으로 간주될 수 없습니다. 이 경우 그들은 분산형 모놀리스(SOA 관점뿐만 아니라 마이크로서비스 아키텍처 관점에서도 안티 패턴으로 간주됨)에 대해 이야기합니다.

서비스 지향 아키텍처는 아키텍처 커뮤니티와 공급업체에서 잘 지원됩니다. 이는 많은 과정과 인증, 잘 개발된 패턴이 있음을 의미합니다. 후자에는 예를 들어 잘 알려진 엔터프라이즈 서비스 버스(ESB = 엔터프라이즈 서비스 버스)가 포함됩니다. 동시에 ESB는 공급업체의 수하물이므로 SOA에서 반드시 사용할 필요는 없습니다.

서비스 지향 아키텍처의 인기는 2008년경에 최고조에 달한 후 감소하기 시작했으며, 이는 마이크로서비스의 출현(~2015) 이후 훨씬 더 극적으로 나타났습니다.

결론

서비스와 모듈 형태로 정보 시스템을 구성할 수 있는 가능성에 대해 논의한 후, 마지막으로 마이크로서비스 아키텍처의 원칙으로 넘어가 다음 부분에서는 마이크로서비스 아키텍처와 서비스 지향 아키텍처의 차이점에 특별한 주의를 기울일 것을 제안합니다.

출처 : habr.com