마이크로서비스에 대한 과대광고의 정점은 지나간 것 같습니다. 우리는 더 이상 "내 단일체를 150개 서비스로 이동한 방법"이라는 게시물을 일주일에 여러 번 읽지 않습니다. 이제 나는 더 많은 상식적인 생각을 듣습니다. "나는 단일체를 싫어하지 않고 단지 효율성에 관심이 있습니다." 우리는 심지어 여러 번의 마이그레이션을 관찰했습니다. 마이크로서비스에서 모놀리스로. 하나의 대규모 애플리케이션에서 여러 개의 소규모 서비스로 이동할 때 몇 가지 새로운 문제를 해결해야 합니다. 가능한 한 간략하게 나열해 보겠습니다.

설정 : 기초화학부터 양자역학까지

백그라운드 프로세스로 기본 데이터베이스와 애플리케이션을 설정하는 것은 매우 간단한 프로세스였습니다. 저는 Github에 Readme를 게시합니다. 보통 한 시간, 최대 두 시간 내에 모든 것이 작동하고 새 프로젝트를 시작합니다. 적어도 초기 환경에 대한 코드 추가 및 실행은 첫날에 완료됩니다. 그러나 마이크로서비스에 도전하면 초기 출시 시간이 급격하게 늘어납니다. 예, 이제 오케스트레이션이 포함된 Docker와 K8 시스템 클러스터가 있지만 초보 프로그래머에게는 이 모든 것이 훨씬 더 복잡합니다. 많은 후배들에게 이는 그야말로 불필요한 합병증인 부담이다.

시스템을 이해하기가 쉽지 않습니다.

잠시 우리 후배에게 집중해보자. 모놀리식 애플리케이션을 사용하면 오류가 발생하면 쉽게 추적하고 즉시 디버깅으로 이동할 수 있습니다. 이제 다른 서비스를 처리하는 메시지 버스의 대기열에 있는 다른 서비스와 통신하는 서비스가 생겼습니다. 그러면 오류가 발생합니다. 서비스 A가 버전 11을 실행하고 있고 서비스 E가 이미 버전 12를 기다리고 있다는 것을 확인하려면 이 모든 부분을 모아야 합니다. 이는 표준 통합 로그와는 매우 다릅니다. 대화형 터미널/디버거를 사용하여 이동해야 합니다. 단계별 과정을 통해. 디버깅과 이해는 본질적으로 더욱 어려워졌습니다.

디버깅할 수 없다면 테스트해 보겠습니다.

지속적인 통합과 지속적인 개발은 이제 일반화되고 있습니다. 내가 본 대부분의 새로운 앱은 새 릴리스가 나올 때마다 자동으로 테스트를 생성하고 실행하며 등록 전에 테스트를 수행하고 검토해야 합니다. 이는 포기해서는 안 되는 훌륭한 프로세스이며 많은 기업에 큰 변화를 가져왔습니다. 하지만 이제 서비스를 실제로 테스트하려면 애플리케이션의 전체 작동 버전을 가져와야 합니다. 8개 서비스로 구성된 K150 클러스터를 갖춘 새로운 엔지니어를 기억하시나요? 자, 이제 우리는 모든 시스템이 실제로 작동하는지 확인하기 위해 이러한 모든 시스템을 불러오는 방법을 CI 시스템에 가르칠 것입니다. 이는 너무 많은 노력이 소요될 수 있으므로 각 부분을 개별적으로 테스트하겠습니다. 사양이 충분하고 API가 깨끗하며 서비스 오류가 격리되어 다른 부분에 영향을 미치지 않을 것이라고 확신합니다.

모든 타협에는 그럴 만한 이유가 있습니다. 오른쪽?

마이크로서비스로 전환하는 데에는 여러 가지 이유가 있습니다. 저는 이것이 더 큰 유연성, 팀 확장, 성과, 더 나은 지속 가능성 제공을 위해 수행되는 것을 보았습니다. 그러나 실제로 우리는 계속 진화하는 모놀리스를 개발하기 위한 도구와 관행에 수십 년을 투자했습니다. 저는 다양한 기술 분야의 전문가들과 함께 일하고 있습니다. 우리는 일반적으로 단일 Postgres 데이터베이스 노드의 한계에 도달하기 때문에 확장에 대해 이야기합니다. 대부분의 대화는 다음과 같습니다. 데이터베이스 확장.

하지만 나는 항상 그들의 아키텍처에 대해 배우는 데 관심이 있습니다. 마이크로서비스로의 전환 중 어느 단계에 있습니까? 더 많은 엔지니어가 모놀리식 애플리케이션에 만족한다고 말하는 것은 흥미로운 일입니다. 많은 사람들이 마이크로서비스의 이점을 누릴 것이며 마이그레이션 경로의 어려움보다 이점이 더 클 것입니다. 하지만 개인적으로 해변에 있는 모놀리식 애플리케이션을 제공해 주시면 매우 기쁩니다.

출처 : habr.com