마이크로서비스: 정의, 이유, 구현 시기

나는 오랫동안 마이크로서비스 아키텍처 주제에 관한 기사를 쓰고 싶었지만 두 가지 문제가 나를 계속 방해했습니다. 주제에 더 깊이 빠져들수록 내가 아는 것은 분명하고, 내가 모르는 것은 더 분명해 보였습니다. 공부하고 공부해야한다는 것을 모릅니다. 한편으로는 이미 폭넓은 청중들 사이에서 논의할 내용이 있다고 생각합니다. 그러니 다른 의견도 환영합니다.

콘웨이의 법칙과 비즈니스, 조직, 정보시스템의 관계

다시 한 번 다음과 같이 인용하겠습니다.

"넓은 의미에서 시스템을 설계하는 모든 조직은 해당 조직의 팀 구조를 복제하는 구조의 설계를 받게 됩니다."
— 멜빈 콘웨이, 1967년

제 생각에는 이 법은 정보 시스템과 직접적으로 관련되기보다는 사업 조직의 타당성과 관련이 있을 가능성이 더 높습니다. 예를 들어 설명하겠습니다. 우리가 기업을 조직하는 것이 타당할 정도로 긴 수명주기를 가진 상당히 안정적인 비즈니스 기회를 가지고 있다고 가정해 보겠습니다.(오타는 아니지만 제가 훔친 이 용어가 정말 마음에 듭니다.) 당연히 이 비즈니스의 지원 시스템은 이 사업에 조직적으로나 프로세스적으로 대응할 것입니다.

정보시스템 사업 방향

예를 들어 설명하겠습니다. 피자를 판매하는 사업을 조직할 수 있는 사업 기회가 있다고 가정해 보겠습니다. V1 버전(사전 정보라고 부르자)에서는 회사가 피자 가게, 금전 등록기, 배달 서비스였습니다. 이 버전은 환경 변동성이 낮은 조건에서 오래 지속되었습니다. 그런 다음 버전 2가 이를 대체하게 되었습니다. 이는 더욱 발전되었으며 모놀리식 아키텍처를 통해 비즈니스의 핵심 정보 시스템을 사용할 수 있게 되었습니다. 그리고 제 생각에는 단일체와 관련하여 끔찍한 불의가 있습니다. 모놀리식 아키텍처는 도메인 비즈니스 모델과 일치하지 않는 것으로 알려져 있습니다.. 예, 만약 그렇다면 시스템은 동일한 콘웨이의 법칙과 상식에 어긋나면서 전혀 작동하지 않을 것입니다. 아니요, 모놀리식 아키텍처는 이 비즈니스 개발 단계의 비즈니스 모델과 완전히 일치합니다. 물론 시스템이 이미 생성되어 실행되는 단계를 의미합니다. 아키텍처 접근 방식에 관계없이 서비스 지향 아키텍처 버전 3과 마이크로서비스 아키텍처 버전 N이 모두 동일하게 잘 작동한다는 것은 정말 놀라운 사실입니다. 문제는 무엇입니까?

모든 것이 흐르고 모든 것이 변화합니까? 아니면 마이크로서비스가 복잡성에 맞서기 위한 수단입니까?

계속하기 전에 마이크로서비스 아키텍처에 대한 몇 가지 오해를 살펴보겠습니다.

마이크로서비스 접근 방식 사용을 지지하는 사람들은 모놀리스를 마이크로서비스로 분리하면 개별 서비스의 코드 기반이 줄어들어 개발 접근 방식이 단순화된다고 주장하는 경우가 많습니다. 제 생각에는 이 진술은 완전히 넌센스입니다. 진지하게, 단일체와 동종 코드 내의 명백한 상호 작용이 복잡해 보입니까? 이것이 실제로 그렇다면 모든 프로젝트는 처음에 마이크로서비스로 구축되었을 것입니다. 반면, 실습에 따르면 모놀리스에서 마이크로서비스로의 마이그레이션이 훨씬 더 일반적입니다. 복잡성은 사라지지 않고 단순히 개별 모듈에서 인터페이스(데이터 버스, RPC, API 및 기타 프로토콜 등)와 조정 시스템으로 이동합니다. 그리고 이것은 어렵습니다!

이기종 스택을 사용하는 이점도 의심스럽습니다. 나는 이것이 또한 가능하다고 주장하지 않을 것이지만 실제로는 거의 발생하지 않습니다 (미래를 내다 보면 이것이 일어나야하지만 이점보다는 결과로 발생합니다).

제품 수명주기 및 서비스 수명주기

위의 다이어그램을 다시 살펴보세요. 별도의 비즈니스 버전의 수명 주기가 감소하고 있다는 사실을 언급한 것은 우연이 아닙니다. 현대 상황에서는 버전 간 비즈니스 전환이 가속화되는 것이 성공에 결정적인 역할을 합니다. 제품의 성공 여부는 비즈니스 가설을 테스트하는 속도에 따라 결정됩니다.. 제 생각에는 여기에 마이크로서비스 아키텍처의 주요 이점이 있습니다. 하지만 순서대로 가자.

정보 시스템 진화의 다음 단계인 SOA의 서비스 지향 아키텍처로 넘어가겠습니다. 그래서 어느 시점에서 우리는 제품에서 강조했습니다. 장기 서비스 - 제품 버전 간에 이동할 때 서비스 수명 주기가 제품의 다음 버전 수명 주기보다 길어질 가능성이 있다는 점에서 수명이 길다. 전혀 변경하지 않는 것이 논리적입니다. 중요한 것은 다음 버전으로의 전환 속도입니다.. 그러나 아쉽게도 우리는 서비스를 지속적으로 변경해야 합니다. 여기에서는 DevOps 관행, 컨테이너화 등 모든 것이 우리에게 적합합니다. 그러나 이것들은 여전히 ​​마이크로서비스가 아닙니다!

복잡성을 해결하기 위한 수단으로서의 마이크로서비스... 구성 관리

그리고 여기서 마침내 마이크로서비스의 역할 정의로 넘어갈 수 있습니다. 이는 제품 구성 관리를 단순화하는 접근 방식입니다. 더 자세히 설명하면 각 마이크로서비스의 기능은 도메인 모델에 따라 제품 내부의 비즈니스 기능을 정확하게 설명하며 이는 단기 버전이 아닌 장기적인 비즈니스 기회로 살아가는 것입니다. 그리고 제품의 다음 버전으로의 전환은 문자 그대로 눈에 띄지 않게 발생합니다. 하나의 마이크로 서비스와 아마도 상호 작용 계획만 변경/추가하고 갑자기 미래에 자신을 발견하고 버전 사이를 계속 뛰어다니는 울부짖는 경쟁사를 뒤처지게 됩니다. 그들의 단일체. 이제 사전 정의된 인터페이스와 비즈니스 기능을 갖춘 상당히 많은 양의 마이크로서비스가 있다고 상상해 보십시오. 예를 들어 간단히 다이어그램을 그리는 것만으로 기성 마이크로서비스에서 제품 구조를 구축할 수 있습니다. 축하합니다. 귀하에게는 플랫폼이 있으며 이제 스스로 비즈니스를 유치할 수 있습니다. 꿈 꿈.

조사 결과

• 시스템 아키텍처는 구성 요소의 수명 주기에 따라 결정되어야 합니다. 구성 요소가 제품 버전 내에 있는 경우 마이크로서비스 접근 방식을 사용하여 시스템의 복잡성을 높이는 것은 의미가 없습니다.
• 마이크로서비스 아키텍처는 도메인 모델을 기반으로 해야 합니다. 비즈니스 기회는 가장 오래 지속되는 도메인이기 때문입니다.
• 제공 방식(DevOps 방식) 및 오케스트레이션은 마이크로서비스 아키텍처에서 가장 중요한 것 중 하나입니다. 구성 요소 변경 속도가 증가하면 제공 속도와 품질에 대한 요구가 높아지기 때문입니다.

출처 : habr.com