안에 이전 블로그, 우리는 Conway의 법칙이 우세할 것이고 마이크로서비스는 Enterprise DevOps의 세계에서 필수적이라는 결론을 내렸습니다. 즉, DevOps에 대해 진지한 사람은 누구나 마이크로서비스를 정의하는 방법, 관리하는 방법, 이점을 극대화하는 방법, 문제를 최소화하는 방법을 배워야 합니다. 다양한 기술과 다양한 사용 사례에 이상적인 마이크로서비스를 설계하는 방법을 아는 것이 중요합니다. 이 블로그는 마이크로서비스가 최적의 방식으로 비즈니스를 지원하는 방법에 대한 개요를 제공합니다.
마이크로서비스 아키텍처란 무엇인가요?
James Lewis와 Martin Fowler는 마이크로서비스 아키텍처에 대한 최상의 정의를 제공합니다.
마이크로서비스 아키텍처 스타일은 더 작은 서비스(IT 구성 요소 또는 앱)의 모음으로 더 큰 애플리케이션을 구축하는 접근 방식을 제공하며 각 서비스는 다음과 같습니다.
- 비즈니스 역량을 중심으로 구축됩니다
- 자체 프로세스를 실행합니다
- 가벼운 메커니즘을 통해 통신합니다.
- 자동화된 배치 장비에 의해 독립적으로 배치 가능
결국 마이크로서비스는 비즈니스 유연성을 촉진해야 합니다. 이는 새로운 기능 요청이 단 하나의 마이크로서비스에만 영향을 미칠 가능성이 최대일 때 달성되며, DevOps 팀이 문제를 빠르게 해결하고, 자동화를 통해 빠르게 재테스트하고, 마이크로서비스를 다시 배포할 수 있게 합니다.
기능적 마이크로서비스란 무엇인가요?
대부분의 기능 요청은 최종 사용자로부터 오기 때문에 대부분의 마이크로서비스는 기능 지향적입니다. 기능 요청은 일반적으로 GUI, 로직, 워크플로 및 데이터를 변경하는 것을 포함하므로 이러한 모든 부분을 동일한 배포 가능한 항목에 포함하는 마이크로서비스를 설계하면 변경의 영향을 최소화할 수 있습니다.
설계에는 기술적 고려 사항보다 훨씬 더 많은 것이 포함될 것입니다. 우리는 비즈니스 프로세스가 일반적으로 기능적 범위를 좋은 마이크로서비스로 나누는 데 가장 좋은 기반이라는 것을 보았습니다. 이는 비즈니스 소유자와 프로세스 아키텍트를 참여시켜 아키텍처를 정의해야 함을 의미합니다.
아직도 기술적인 마이크로서비스가 필요한가?
몇몇 마이크로서비스는 명확하고 안정적인 요청-응답 인터페이스를 통해 기술적으로 지향적이고 호출 가능합니다. 기능의 일부가 여러 목적에 대해 동일해야 하고, 자주 변경되지 않는 경우, 별도의 보다 '기술적인' 마이크로서비스로 나눌 수 있습니다.
다른 마이크로서비스는 다른 서비스를 조정하기 위해 통합 지향적일 수도 있고, 다른 대규모 시스템 및/또는 외부 당사자와의 연결을 담당할 수도 있습니다. 중앙 ESB는 종종 서비스의 효율성을 높이는 경우 자체 비즈니스 데이터를 보유할 수 있는 분산된 전문 마이크로서비스로 대체됩니다.
기업은 마이크로서비스가 무엇을 할 수 있고 무엇을 해야 하는지에 대해 열린 마음을 가져야 합니다. 한 사업 영역에 가장 적합한 마이크로서비스 아키텍처가 다른 영역에도 항상 이상적인 것은 아닙니다. 이는 대부분 팀 수준에서 디자인 결정을 위임하는 DevOps와 일치합니다.
너무 많이 재사용하거나 이것이 SOA 버전 2.0이라고 생각하지 않는 것이 중요합니다. 곧 나올 별도의 블로그에서 이 중요한 주제에 대해 더 자세히 설명하겠습니다.
구성요소의 크기는 비즈니스 민첩성에 어떤 영향을 미칩니까?
마이크로서비스의 경우, 대부분의 사람들은 10~XNUMX명으로 구성된 DevOps 팀이 약 XNUMX~XNUMX개의 마이크로서비스를 소유하고, 구축하고, 운영하고, 관리해야 한다고 말합니다. 마이크로서비스를 설계하는 데 있어서 크기는 비교적 유연합니다.
작은 범위에서 비교적 큰 범위의 경우, 비즈니스가 요구하는 것보다 더 작은 부분으로 나눌 필요가 없습니다. 예를 들어, 팀과 아키텍처는 지원하는 비즈니스 기능과 일치하여 최대 자율성을 달성하여 쉽게 진화하고 가치를 창출할 수 있습니다.
그러나 "시스템"의 범위가 매우 큰 경우 기능을 별도의 마이크로서비스로 분할하는 것이 항상 더 좋습니다. 수년간의 시간적 제약이 있는 수정 및 단축키로 인해 원치 않는 종속성이 발생하면 내부 및 외부 종속성이 커집니다. 시스템을 변경하기 어렵고 모든 릴리스 및 배포에 대한 상당한 회귀 테스트는 비용이 많이 들고 위험합니다.
그림 2: 모놀리스 아키텍처에서는 사용자 그룹이 관심을 끌기 위해 싸우고 개발자들은 서로의 발을 밟습니다.
마이크로서비스의 이상적인 크기는 개발자 수와 관련이 있습니다. 즉, HPA 플랫폼은 나중에 분할할 수 있고, 더 큰 마이크로서비스를 가질 수 있고, 더 작은 팀을 가질 수 있기 때문에 오픈 소스보다 유리합니다.
지원 마이크로서비스?
마이크로서비스에 대한 유연한 관점을 홍보했으므로 다음과 비교하는 것이 합리적입니다. 지원 마이크로서비스:
- 모놀리스는 너무 크기 때문에 마이크로서비스가 아닙니다. 10명 이상의 개발팀이 필요하고 (일반적으로) 동일한 배포 가능한 파일에 기능적으로 분리된 프로세스가 많이 있습니다. 여기에는 더 많은 회귀 테스트와 더 긴 릴리스 주기가 필요합니다. 종속성은 크기와 시간에 따라 커지고 마이크로서비스 아키텍처와 같이 서비스 호출을 통해 명시적으로 제공되지 않습니다.
- 비즈니스 데이터가 ESB 아래에 있는 계층형 SOA 아키텍처도 마이크로서비스가 아닙니다. 동일한 배포 가능한 비즈니스 기능에 필요한 데이터와 기능을 포함하지 않습니다. 대신 거의 모든 비즈니스 기능은 공유 배포 가능한 단위의 여러 기술적으로 집중된 "계층"에 걸쳐 있습니다. NGINX에 따르면: "SOA는 가능한 한 많이 공유하는 아키텍처 스타일이라는 개념에 기반을 두고 있는 반면, 마이크로서비스는 가능한 한 적게 공유하는 아키텍처 스타일이라는 개념에 기반을 두고 있습니다." 마이크로서비스는 자율적이어야 하며 비즈니스 기능을 충족해야 하므로 GUI, 로직, 워크플로우, 필요할 때 항목을 저장할 데이터베이스가 필요합니다.
그림 4: 마이크로서비스는 다른 패턴보다 더 나은 유연성과 비즈니스-IT 협력을 촉진합니다.
우리의 견해: 마이크로서비스의 공통적인 특징
마이크로서비스는 비즈니스 기능을 수행하고 일반적인 비즈니스 프로세스의 일부로 서로 통신하여 비기술적인 사람들이 이해하기 쉽게 만듭니다. 이는 DevOps와 팀 의사 결정에 좋은 것입니다. 우리의 견해로는 좋은 마이크로서비스는 다음과 같은 공통적인 특성을 가져야 합니다.
1. 프로세스 지향적
기능적 마이크로서비스는 일반적으로 비즈니스 프로세스의 단계 또는 전체 비즈니스 기능을 구현합니다. "서비스"라는 이름은 오해의 소지가 있습니다. 마이크로서비스는 호출 가능한 서비스일 수 있지만 최종 사용자 기능에 초점을 맞춘 앱일 수도 있습니다.
2. 자율성과 유연성
마이크로서비스는 별도로 개발하고, 별도로 배포하고, 자체 데이터를 포함해야 합니다. 시간이 지남에 따라 진화해야 하며 변경 및 재배포가 쉬워야 합니다.
3. 자동화 및 제어
마이크로서비스는 우수한 테스트 및 배포 자동화, 오류 처리, 모니터링 및 알림 기능을 갖춰야 하며 사용자로부터 피드백을 허용해야 합니다.
4. 적절한 크기
"마이크로"라는 단어도 다소 오해의 소지가 있습니다. 마이크로서비스는 너무 작거나 너무 커서는 안 됩니다. 서비스는 최대 10명의 개발자가 있으면 비교적 커질 수 있습니다. 모놀리스보다 작지만 일반 앱보다 작을 필요는 없습니다. 다음과 같은 고생산성 플랫폼을 사용하는 경우 Mendix마이크로서비스는 중견기업의 핵심 시스템이 될 수 있습니다.
마이크로서비스는 당신에게 무엇을 의미할까요?
마이크로서비스는 올바르게 수행하면 비즈니스와 IT의 정렬을 촉진하고 운영 프로세스의 유연성을 개선합니다. 이전 패러다임에서는 비즈니스 프로세스를 변경하기가 매우 어려웠기 때문에 대부분의 현직자에게 디지털화가 매우 어려웠습니다. DevOps와 마이크로서비스 아키텍처는 의사 결정과 개발을 현지화하여 이 문제를 해결합니다. DevOps 팀은 비즈니스와 직접 협력하며 의사 결정을 내릴 수 있는 자율성을 가지고 있습니다. 마이크로서비스는 최소한의 종속성으로 별도로 개발되며 자율적인 단위로 별도로 배포됩니다.
Mendix 마이크로서비스에 대한 현장 워크숍과 교육을 제공합니다. 우리는 많은 수의 고객에게 새로운 프로그램과 이니셔티브를 도왔고, 의사 결정에 대한 지원을 제공하고 각 비즈니스 문제에 대한 가장 최적의 솔루션을 모색했습니다. 자세한 내용은 문의하십시오..