혼자서 시스템을 개발할 때 마이크로 서비스를 사용해야합니까?


30

저는 새 프로젝트를 시작하고 있으며 프로젝트의 거의 유일한 개발자 일 것입니다. 그러나 한두 명의 다른 개발자가 기존 응용 프로그램이나 간단한 스크립트를 기본 프로젝트에 통합해야합니다. 이 프로젝트는 소규모 대량 및 스트리밍 데이터 수집 / 처리, 이벤트 중심 및 주문형 코드 실행을 모두 처리해야합니다. 프레임 워크의 일부 부분은 CPU에 바운드되고 일부 부분은 I / O에 바운드 될 수 있습니다. 대부분의 데이터는 단일 머신에 있어야하지만 사용 가능한 컴퓨팅 성능을 높이기 위해 클러스터를 생성하고 VM을 연결할 수 있습니다. 이 핵심 프레임 워크가 제공하는 서비스에 의존하는 하나 이상의 소규모 웹 응용 프로그램이있을 수 있습니다. 주요 언어는 거의 모든 것을위한 Python입니다.

내 질문은 내가 직접 개발의 대부분을 할 것이라는 점을 감안할 때 이와 같은 노력에 마이크로 서비스 접근 방식을 취해야하는지 아니면 모 놀리 식 응용 프로그램을 사용 해야하는지 여부입니다. 제 생각에는 마이크로 서비스 (Nameko를 사용)가 서로 다른 실행 모델 (데이터 파이프 라인, 이벤트 시작, 주문형, 웹 애플리케이션 등)이있는 프레임 워크 요소와 작업 부하를 분산시키는 명확한 방법을 자연스럽게 분리 할 수 ​​있다는 것입니다. 여러 프로세스에 걸친 커뮤니케이션. 내 걱정은 아마도 Kubernetes 클러스터로 끝날 것입니다 (나는 Docker에 익숙하지만 Kubernetes에 상당히 익숙합니다), 시스템 실행을 촉진하기 위해 필요한 여러 서비스 (rabbitmq, redis 등), 잠재적으로 필요한 모든 기능을 실제로 구현하기위한 많은 양의 작은 코드 덩어리

개발자가 한 명 이상인 프로젝트의 경우에도 이와 같은 복잡한 시스템의 개발 및 유지 관리를 마이크로 서비스가 단순화합니까? 대신 사용하거나 시스템 설계와 관련된 오버 헤드를 줄이기 위해 고려해야 할 방법 / 시스템 / 프레임 워크가 있습니까?


10
마이크로 서비스가 제공하는 혜택이 필요할 때 마이크로 서비스를 사용하며 이러한 혜택이 비용을 능가합니다. 개인적으로, 자신을 가르치거나 더 큰 응용 프로그램에 대한 장기적인 전망이 없다면 한 사람이 작성한 개별 응용 프로그램에서 마이크로 서비스가 필요한 이유를 알 수 없습니다.
Robert Harvey

답변:


49

마이크로 서비스는 일반적으로 소프트웨어를 분산 시스템으로 전환하기 때문에 바람직하지 않으며 분산 시스템은 모든 것을 훨씬 어렵게 만듭니다. 그러나 서비스 지향 아키텍처에는 몇 가지 중요한 이점이 있습니다.

  • 다른 팀이 독립적으로 다른 서비스를 개발 및 배포 할 수 있음
  • 다양한 서비스를 독립적으로 확장 가능

유일한 개발자가되므로 서비스를 독립적으로 개발할 수있는 유연성이 필요하지 않습니다.

그러나 일부 부품은 CPU에 바인딩되어있을 수 있습니다. 따라서 나머지 응용 프로그램과 독립적으로 확장하는 것이 바람직 할 수 있습니다. 이 경우 전체 프로젝트를 마이크로 서비스 아키텍처로 전환해야한다는 의미는 아닙니다. CPU를 많이 사용하는 부분을 자체 서비스로 옮기면 나머지는 편리한 모놀리스로 유지할 수 있습니다. 시스템을 분할해야하는 행과 함께 말하기는 어렵지만 일반적으로“바운드 컨텍스트”에 대한 DDD 아이디어는 좋은 지침입니다.

모놀리스는 나쁘지 않습니다. 모놀리스는 유지하기 어려운 거대한 프로젝트와 같지 않습니다. 시스템을 여러 마이크로 서비스로 분할 할 수있는 경우 시스템을 단일체 내의 다른 구성 요소로 분할 할 수도 있습니다. 이러한 구성 요소 간의 분리는 서비스 지향 아키텍처에서 더 잘 보이고 더 명확하게 적용됩니다. 이는 또한 잘 설계된 시스템의 경우 나중에 나중에 구성 요소를 서비스로 전환하는 것이 매우 쉽다는 것을 의미합니다. 따라서 지금 결정하지 않아도됩니다. 단일체가 적합하지 않은 것으로 판명되면 마이크로 서비스로 전환 할 수 있습니다.

Martin Fowler의 Microservice Premium (2015) 개념을 고려하십시오 . 마이크로 서비스는 시스템의 기본 복잡성 외에도 자체 복잡성이 상당히 복잡합니다. 생산성 감소 측면에서이“프리미엄”을 지불해야합니다. 즉, 간단한 프로젝트의 경우 마이크로 서비스가 생산성을 떨어 뜨립니다. 이는보다 복잡한 프로젝트를 위해 변화합니다. 단일 솔루션으로 작업하기가 점점 어려워 질 수 있지만, 마이크로 서비스 아키텍처는 훨씬 더 잘 확장되며 거의 지속적인 노력이 필요합니다. 소프트웨어 시스템에 마이크로 서비스의 초기 노력이 가치가 있는지를 알아야합니다. 이 질문을하고 있기 때문에 아마도“아니오”일 것입니다. 파울러는 계속합니다.

따라서 내 기본 지침은 단일 시스템으로 관리하기에는 너무 복잡한 시스템이 없다면 마이크로 서비스를 고려하지 않을 것입니다. 대부분의 소프트웨어 시스템은 단일 모 놀리 식 응용 프로그램으로 구축해야합니다. 해당 단일체 내에서 우수한 모듈성에주의를 기울이지 만 별도의 서비스로 분리하지 마십시오.


31
TL; DR 버전 : 실제 문제를 해결할 때만 복잡성을 추가하십시오.
jpmc26

1
나중에 마이크로 서비스 아키텍처로보다 쉽게 ​​마이그레이션 할 수 있도록 설계하십시오. 예를 들어, 우려의 분리 대 큰 진흙 공은 지금 유지하기가 더 쉽고 나중에 분리 서비스를 위해 부분을 옮기는 것이 더 쉬울 것입니다. 다른 서비스에 전화를 걸거나 메시지를 보내지 않고도 마이크로 서비스에서 영감을받은 업무 / 도메인을 계속 유지할 수 있습니다.
ps2goat

1
분산 객체의 파울러의 제 1 법칙 : 안
K. 앨런 베이츠

1
OP와 유사하게 쓸모가 없지만 세 번째 이점이 있습니다. 어쨌든 분산 시스템을 구축해야하고 이미 분산 시스템을위한 우수한 툴링을 구축하거나 계획 할 경우 마이크로 서비스는 해당 툴링과보다 쉽게 ​​통합됩니다. 여러 측면에서 세밀한 제어가 가능합니다. 이는 문제 해결, 프로파일 링, 통합 테스트, 추적 등을 단순화 할 수 있습니다. 그러나 이는 기존의 마이크로 서비스 아키텍처를 지원하고 지원하는 도구에 달려 있습니다. 이러한 지원 에코 시스템이 없으면 마이크로 서비스는 복잡성을 증가시킵니다.
Kevin

2
네, 좋은 대답입니다. 사람들은 마이크로 서비스가 실제로 복잡성을 추가 한다는 사실을 잊는 것 같습니다. 따라서 더 많은 복잡성 을 제거 하지 않으면 가치가 없습니다. 거의 모든 경우에 단일 개발자는 MSA를 수행 할 수있는 충분한 이점이 없습니다.
enderland
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.