마이크로서비스는 대규모 애플리케이션을 간단한 API를 통해 서로 통신하는 느슨하게 연결된 모듈로 나누는 방법입니다.
최근에는 멍청한 사람들만이 마이크로서비스에 대해 이야기하지 않았습니다. 이것은 점점 더 대중화되고 있습니다. 모듈식 아키텍처 스타일은 특히 클라우드 기반 환경에 적합한 것으로 보이며 인기가 높아지고 있습니다. 세부 사항에 들어가기 전에 모든 것을 조감도로 살펴보겠습니다 . 따라서 마이크로서비스는 대규모 프로젝트를 작고 독립적이며 느슨하게 결합된 모듈로 나누는 방법입니다. 독립 모듈은 명확하게 정의된 개별 작업을 담당하며 간단하고 액세스 가능한 API를 통해 서로 통신합니다. 즉, 마이크로서비스는 복잡한 주로 웹 애플리케이션을 설계하기 위한 단순히 다른 아키텍처 스타일입니다. 그런데 SOA(서비스 지향 아키텍처)와 같은 기존 아키텍처 솔루션의 문제점은 무엇입니까? SOA를 사용하여 작성된 대부분의 최신 엔터프라이즈 솔루션은 꽤 잘 작동하는 것 같습니다. 요즘 업계가 직면하고 있는 몇 가지 과제에 대해 이야기할 수 있는 좋은 기회가 될 것입니다. 간단한 예부터 시작해 보겠습니다. Java로 작성된 클래식 애플리케이션을 실행해야 한다고 가정해 보겠습니다. 먼저 사용자 인터페이스를 개발한 다음 UI와 상호 작용하는 여러 구성 요소가 포함된 비즈니스 논리 계층, 마지막으로 영구 데이터베이스에 액세스할 수 있는 데이터베이스 계층을 개발할 것입니다. 이제 애플리케이션을 실행하고 싶다는 사실에 따라 WAR/EAR/JAR을 생성하고 이를 서버(예: JBoss, Tomcat 또는 WebLogic)에 마운트하겠습니다. 이 작업은 모두 하나로 수행되므로 모놀리식 애플리케이션을 얻게 됩니다. 즉, 모든 구성 요소가 한 곳에 있다는 의미입니다... 그림의 예:
아마도 여러분은 이미 이 접근 방식에 익숙하고 사용해 본 적이 있을 것입니다. 하지만 이 예제를 사용하여 개발자가 이 아키텍처 솔루션을 사용하면서 직면하게 될 과제가 무엇인지 보여 주는 것이 좋습니다. 모놀리식 애플리케이션: 과제 과제
애플리케이션이 커짐에 따라 작성되는 코드의 양도 늘어나고, 이로 인해 애플리케이션을 열어야 할 때마다 개발 환경에 과부하가 걸릴 수 있습니다. 이는 확실히 개발자의 효율성을 감소시킵니다.
모든 것을 한 곳에 마운트해야 하기 때문에 다른 프로그래밍 언어로 전환하거나 다른 기술로 전환하는 것이 큰 문제로 이어진다. 예를 들어, Java로 애플리케이션을 작성했는데 얼마 후 Kotlin이 나왔고 Kotlin이 더 멋지고, 더 좋고, 더 빠르다는 이유로 다시 작성하고 싶어 했습니다 . 모놀리식 애플리케이션을 사용하면 프로세스 자체는 말할 것도 없고 리팩토링을 고려하는 것조차 큰 고통을 초래할 것입니다. 현재 이런 방식으로 만들어진 많은 응용 프로그램이 있으며 코드 줄의 수도 정말 놀랍습니다.
어떤 이유로 든 구성 요소 중 하나라도 작동이 중지되면 전체 응용 프로그램도 충돌합니다. 승인, 결제, 기록 등과 같은 모듈이 있는 웹 애플리케이션이 있다고 상상해 보세요. 그리고 어떤 이유로 그들 중 하나가 깨졌습니다. 이는 비즈니스와 결과적으로 개발자에게 충격입니다.
모놀리식 애플리케이션의 확장은 동일한 유형의 다른 애플리케이션을 발생시켜야만 달성할 수 있습니다. 하지만 전체 애플리케이션이 아닌 하나의 구성 요소만 확장해야 한다면 어떻게 될까요? 얼마나 많은 자원이 낭비될 것인가?...
이는 애플리케이션 개발 프로세스와 설치 프로세스에 큰 영향을 미칠 수 있습니다. 애플리케이션이 클수록 개발자가 애플리케이션을 더 작은 작업 부분으로 나눌 수 있다는 것이 더 중요합니다. 모놀리식 애플리케이션의 모든 모듈은 서로 연결되어 있으므로 개발자는 이러한 모듈을 서로 독립적으로 작업/마운트할 수 없습니다. 개발자들이 서로 의존하기 때문에 개발 시간이 늘어납니다.
동시에 우리는 마이크로서비스의 의미, 즉 마이크로서비스를 사용하여 SOA 스타일에서 잃어버린 유연성을 복원하는 방법을 고려하고 이해할 준비가 되어 있습니다. God 마이크로서비스가 구조해 드립니다. 모든 아키텍처 솔루션의 가장 중요한 특징 중 하나는 확장성입니다. 마이크로서비스를 처음 배우면서 모든 것이 "The Art of Scalability"라는 책에 나오는 인용문과 너무 비슷하다는 것을 알았습니다. 이것은 토론을 위한 훌륭한 시작이자 장소입니다. 이 책은 3차원 확장성 시스템을 설명하는 소위 "확장성 큐브" 모델을 정의합니다.
보시다시피 X축은 "수평 확장"(모놀리식 아키텍처에도 사용 가능함)을 나타내고, Y축은 서로 다른 서비스 구성 요소를 분리한다는 의미에서 확장을 나타냅니다 . Z축의 개념은 데이터를 분할하고 애플리케이션이 데이터가 있는 정확한 위치로 요청을 보내면 이해됩니다. 즉, 모두 한곳에 있지 않습니다. Y축에 대한 개념은 우리가 더 자세히 집중할 개념입니다. 이 축은 기능적 분해를 나타냅니다 . 이 전략에서는 다양한 기능을 독립적인 서비스로 간주할 수 있습니다. 따라서 모든 작업이 완료된 경우에만 전체 애플리케이션을 마운트함으로써 개발자는 개별 서비스를 서로 독립적으로 마운트할 수 있으며 다른 사람이 모듈 작업을 마칠 때까지 기다리지 않아도 됩니다. 이는 개발 시간을 단축할 뿐만 아니라 나머지 애플리케이션 구성 요소에 대해 걱정할 필요 없이 변경하고 다시 연결할 수 있는 유연성을 제공합니다. 이 다이어그램을 이전 모놀리식 다이어그램과 비교해 보겠습니다.
마이크로서비스: 이점 마이크로서비스의 이점은 Amazon, Netflix, Ebay와 같은 엔터프라이즈 개발자가 이 접근 방식을 사용하도록 설득하기에 충분한 것 같습니다. 모놀리식 아키텍처 애플리케이션과 달리 마이크로서비스는 다음을 수행합니다.
구성 요소 오류 격리 개선: 단일 모듈에 오류가 발생하더라도 대규모 애플리케이션을 계속해서 효율적으로 실행할 수 있습니다.
하나의 기술 스택에 대한 애플리케이션의 헌신을 제거합니다. 일부 서비스에서 새로운 기술 스택을 시도하고 싶다면 계속하세요. 종속성은 모놀리식 종속성보다 훨씬 가벼우며 모든 것을 롤백하는 것도 훨씬 쉽습니다. 하나의 애플리케이션에 코드가 적을수록 작업이 더 쉬워집니다.
신규 직원이 서비스 기능을 훨씬 쉽게 이해할 수 있습니다.
마이크로서비스: 탑재 및 가상화 기능 이제 우리는 마이크로서비스가 무엇인지 이해했습니다. 그리고 가장 큰 장점은 하나 이상의 WAR/EAR/JAR 아카이브에 의해 마운트된다는 것입니다. 그런데 어떻게 설치되나요? 컨테이너 내부에 마이크로서비스를 탑재하는 가장 좋은 방법입니다. 컨테이너는 필요한 환경이 구성된 완전히 구성된 가상 운영 체제로, 컨테이너가 설치된 하드웨어 시스템의 리소스에 대한 액세스를 격리하는 데 도움이 됩니다. 시장에서 가장 유명한 솔루션은 물론 Docker 입니다 . AWS와 같은 IaaS(Infrastructure as a Service)의 가상 머신도 마이크로서비스 탑재에 적합하지만 상대적으로 가벼운 마이크로서비스는 가상 머신에 있는 리소스를 모두 사용하지 않아 사용 수익성이 떨어질 수 있습니다. OSGI (Open Service Gateway Initiative) 패키지를 사용하여 마이크로서비스를 탑재할 수도 있습니다 . 이 경우 모든 마이크로서비스는 단일 JVM에서 실행되지만 이는 제어와 격리 간의 균형 문제를 수반합니다. 마이크로서비스: 단점 단지 "이거 다 멋지다", "이전에는 본 적이 없다"고 해서 단점이 없다는 뜻은 아닙니다. 다음은 마이크로서비스 아키텍처로 인해 발생할 수 있는 문제 영역 목록입니다.
분산 시스템을 개발하는 것은 어려울 수 있습니다. 이는 이제 모든 구성 요소가 독립적인 서비스라는 것을 의미합니다. 모듈 간에 전달되는 요청을 매우 신중하게 처리해야 합니다. 하나의 모듈이 응답하지 않아 시스템 충돌을 방지하기 위해 추가 코드를 작성해야 하는 시나리오가 있을 수 있습니다. 원격 호출이 대기 시간 에 민감한 경우 이는 더 어려울 수 있습니다 .
여러 데이터베이스와 트랜잭션 관리는 정말 어려울 수 있습니다.
마이크로서비스 애플리케이션을 테스트하는 것은 번거로울 수 있습니다. 모놀리식 애플리케이션을 사용하면 서버에서 WAR/EAR/JAR 아카이브를 실행하고 데이터베이스에 연결되어 있는지 확인하기만 하면 됩니다. 그리고 마이크로서비스에서는 테스트를 시작하기 전에 각 개별 서비스를 시작해야 합니다.
장착 애플리케이션은 까다로울 수 있습니다. WAR 컨테이너만큼 탑재하기 쉽지 않을 수 있는 여러 서비스에 대한 조정이 필요할 수 있습니다.
.... 물론 올바른 도구와 접근 방식을 사용하면 이러한 단점을 피할 수 있습니다. 그러나 그 자체로는 지원이 필요하며 모든 문제를 완전히 해결하지는 않습니다. 기사는 CloudAcademy 웹사이트 에서 번역되었습니다 . 무료 번역. 누구나 댓글을 통해 자신의 생각을 자유롭게 표현할 수 있습니다. 확실히 읽힐 것입니다. 원본 기사 내 Github 계정
GO TO FULL VERSION