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

안녕하세요, 하브르님. 지금 OTUS에서 새로운 강좌 스트림 등록이 시작되었습니다. "소프트웨어 아키텍트". 강좌 시작 전날, 제가 쓴 원본 기사를 여러분과 공유하고 싶습니다.

소개

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

역사의 비트

개발자에게 “마이크로서비스가 왜 필요한가요?”라고 물어보면 다양한 대답이 나올 것입니다. 마이크로서비스가 확장성을 향상시키고, 코드를 더 쉽게 이해하게 하며, 내결함성을 개선하고, 때로는 "코드 정리"를 가능하게 한다는 말을 듣게 될 것입니다. 마이크로서비스 출현의 목적을 이해하기 위해 역사를 살펴보겠습니다.

요컨대, 우리가 현재 이해하고 있는 마이크로서비스는 다음과 같이 나타났습니다. 2011년 James Lewis는 다양한 회사의 작업을 분석하면서 배포 가속화 측면에서 SOA를 최적화하는 새로운 "마이크로 앱" 패턴의 출현에 주목했습니다. 서비스. 얼마 후인 2012년 아키텍처 서밋에서 패턴의 이름이 마이크로서비스로 변경되었습니다. 따라서 마이크로서비스 도입의 초기 목표는 악명 높은 서비스를 개선하는 것이었습니다. 시장 출시.

2015년에는 마이크로서비스가 큰 인기를 끌었습니다. 일부 연구에 따르면 마이크로서비스 주제에 대한 보고서 없이는 단 한 번의 컨퍼런스도 완료되지 않았습니다. 게다가 일부 컨퍼런스는 마이크로서비스에만 전념했습니다. 요즘에는 많은 프로젝트에서 이 아키텍처 스타일을 사용하기 시작하며, 프로젝트에 수많은 레거시 코드가 포함되어 있다면 마이크로서비스로의 마이그레이션이 활발하게 진행되고 있을 것입니다.

위의 모든 사항에도 불구하고 여전히 "마이크로서비스" 개념을 정의할 수 있는 개발자는 상당히 적습니다. 하지만 이에 대해서는 조금 나중에 이야기하겠습니다.

하나로 된 돌

마이크로서비스와 대조되는 아키텍처 스타일은 모놀리스(또는 올인원)입니다. 모놀리스가 무엇인지 말하는 것은 아마도 의미가 없을 것이므로 아키텍처 스타일의 추가 개발을 촉발한 이 아키텍처 스타일의 단점(크기, 연결성, 배포, 확장성, 안정성 및 강성)을 즉시 나열하겠습니다. 아래에서는 각 단점을 개별적으로 살펴볼 것을 제안합니다.

크기

단일체는 매우 큽니다. 그리고 일반적으로 매우 큰 데이터베이스와 통신합니다. 한 개발자가 전혀 이해할 수 없을 정도로 애플리케이션이 너무 커집니다. 이 코드를 작업하는 데 많은 시간을 투자한 사람만이 모놀리스를 잘 다룰 수 있는 반면, 초보자는 모놀리스를 알아내려고 많은 시간을 할애할 것이므로 알아낼 것이라는 보장은 없습니다. 일반적으로 모놀리스로 작업할 때 모놀리스에 대해 어느 정도 잘 알고 XNUMX년 반 이내에 다른 신규 개발자의 손을 능가하는 "조건부" 선배가 항상 있습니다. 당연히 그러한 조건부 선배는 단일 실패 지점이며 그의 출발은 단일체의 죽음으로 이어질 수 있습니다.

연결성

모놀리스는 "큰 진흙 공"으로서, 변화가 예측할 수 없는 결과를 초래할 수 있습니다. 한 곳을 변경하면 다른 곳의 모놀리스가 손상될 수 있습니다("귀를 긁어서 *@ 떨어졌습니다"와 동일). 이는 모놀리스의 구성 요소가 매우 복잡하고 가장 중요하게는 명확하지 않은 관계를 가지고 있기 때문입니다.

전개

구성 요소 간의 복잡한 관계로 인해 모놀리스를 배포하는 것은 고유한 의식을 포함하는 긴 프로세스입니다. 그러한 의식은 일반적으로 완전히 표준화되지 않았으며 "구두로" 전달됩니다.

확장성

모놀리식 모듈에는 리소스 요구 사항이 상충될 수 있으므로 하드웨어 측면에서 절충이 필요합니다. 서비스 A와 B로 구성된 단일체가 있다고 상상해 보십시오. 서비스 A는 하드 드라이브 크기를 요구하고 서비스 B는 RAM을 요구합니다. 이 경우 모놀리스가 설치된 머신이 두 서비스의 요구 사항을 모두 지원해야 하거나 서비스 중 하나를 수동으로 인위적으로 비활성화해야 합니다.

또 다른 예(보다 고전적): 서비스 A는 서비스 B보다 훨씬 더 인기가 있으므로 서비스 A는 100개, 서비스 B는 10개가 있어야 합니다. 다시 말하지만, 두 가지 옵션이 있습니다. 100개의 완전한 모놀리스를 배포하거나 일부에 배포합니다. 서비스 B를 수동으로 비활성화해야 합니다.

신뢰성

모든 서비스가 함께 위치하므로 모놀리스가 무너지면 모든 서비스가 한꺼번에 무너집니다. 사실 이것은 그다지 나쁘지 않을 수도 있습니다. 적어도 분산 시스템에서는 부분적인 오류가 없을 것입니다. 그러나 반면에 0.001%의 사용자가 사용하는 기능의 버그로 인해 모든 사용자를 잃을 수도 있습니다. 귀하의 시스템.

관성

모놀리스의 크기로 인해 새로운 기술로의 전환이 어렵습니다. 결과적으로 같은 선배를 유지하는 것은 별개의 일이다. 프로젝트 시작 시 선택한 기술 스택은 제품 개발을 방해하는 블록이 될 수 있습니다.

결론

다음번에는 사람들이 컴포넌트와 SOA로 전환하여 이러한 문제를 해결하려고 어떻게 노력했는지에 대해 이야기하겠습니다.

더 읽어보기:

• SQL Server가 ORDER BY 없이 결과 정렬을 보장하지 않는 이유
• 개발자와 관리자를 위한 아키텍처: 누구에게 어떤 기술이 필요한가요?

출처 : habr.com