시스템 설계, 웹 서비스에서 마이크로 서비스로의 진화

이전 기사 에서 우리는 Nirvana of Independence, 즉 개발, 기술, 배포 가능성, 확장 성 및 팀 구조 (자율성)의 독립성을 찾아 '시스템 설계 및 구조'의 진화를위한 여러 가능한 여정 중 하나에 대해 논의했습니다.

지금까지 여정 전체를 엮어 보면, 노력과 방향은 항상 시스템 설계의 기본적이고 중요한 목표 를 달성하는 것이 었습니다 .

• 구현을 깨끗하고 읽기 쉽게 유지하여 쉽게 유지 관리하고 확장 할 수 있습니다 . 크기 , SPR, 이름 지정 규칙을 사용한 명확한 의도, 올바른 패키지 / 프로젝트 구조, 유틸리티, 구성 요소
• 모듈 형 구조, 도메인 중심 — 소규모 자율 팀이 독립적으로 개발할 수있는 소규모 자체 포함 코드 단위
• 독립적으로 릴리스 가능 — 코드, 데이터는 상호 종속성없이 함께 번들로 제공됩니다.
• 독립적으로 확장 가능하고 내결함성- 따라서 전체 생태계가 아닌 특정 구현 단위를 쉽게 확장 할 수 있습니다.
• 모든 기술 및 통신 프로토콜 사용의 자유 — 기술 중립적 인터페이스 및 검색 메커니즘이므로 개별 장치의 구현은 기술에 구애받지 않을 수 있습니다.

• 이름은 마이크로 서비스가 소형 서비스보다 작아야 함을 의미합니다 .
• 그리고 그것은 서비스 여야합니다.

'Micro'(small)는 크기에 대해 정의 된 매개 변수가 없기 때문에 약간 모호합니다. 이 시리즈의 이전 기사 에서 논의했듯이 함수 또는 클래스의 크기와 비슷합니다 . 크기에 대한 올바른 매개 변수는 단일 책임 원칙과 결합 된 명확한 의도 여야합니다. 따라서 다른 서비스 패턴과 마찬가지로 마이크로 서비스는 단일 책임과 의도의 명확성을 포함하는 명확한 경계를 가져야합니다.

코드 줄은 크기에 적합한 매개 변수가 아닙니다. 가이드 레일 역할을 할 수 있지만.

그러나 위의 두 속성은 마이크로 서비스 패턴뿐만 아니라 모든 서비스에 적용됩니다. 그렇다면 마이크로 서비스의 특별한 점은 무엇입니까? 이것을 이해하기 위해 이름을 넘어서 봅시다.

다음은 이전 기사에서 시스템 설계 진화의 여정을 시작한 몇 가지 목표입니다.

• 모듈 형 구조, 깨끗한 코드, 명확한 의도, 단일 책임
• 유지 보수 용이성, 이해 용이성
• 코드 단위 (이 경우 서비스)는 독립적으로 소유 할 수 있습니다.
• 독립적으로 배포 가능, 독립적으로 릴리스 가능
• 독립적으로 확장 가능
• 기술 불가지론

나머지 포인트 는 웹 서비스 (또는 SOA의 다른 서비스 메커니즘) 로 ' 만족할 수 있습니다' . 웹 서비스는 독립적으로 배포 가능하고 확장 가능하며 기술에 구애받지 않습니다. 인터페이스는 WSDL을 사용하여 노출되며 통신은 XML (대부분 SOAP over HTTP)을 사용하는 개방형 표준을 통해 이루어집니다. 또한 다양한 서비스 레지스트리 및 프로토콜 (예 : UDDI)을 사용하여 검색 할 수도 있습니다.

웹 서비스가 모든 요구 사항을 충족한다면 왜 마이크로 서비스가 필요한가요? 서비스와 함께 '마이크로'단어가 만들어내는 작은 차이가 의도에 큰 영향을 미칩니다. 웹 서비스는 대부분 다른 응용 프로그램에 대한 한 응용 프로그램의 인터페이스로 사용됩니다. 세분화 된 더 작은 구현에 초점을 맞추지 않고 대부분 성능에 초점을 맞추고 복잡성을 숨기는 조잡한 구조 ( Session Facade Pattern )를 따릅니다 . 차이는 표준 / 패턴의 동기에 있습니다.

웹 서비스의 동기는 장치 간, 시스템 간 통신을 가능하게하는 것이 었습니다. 시스템에 대한 인터페이스를 노출하는 방법 중 하나와 같습니다. 하나의 시스템에 여러 인터페이스가있어 서로 다른 컨텍스트로 서로 다른 기능을 노출 할 수 있으며 웹 서비스도 마찬가지였습니다. 이것이 웹 서비스가 사용 된 것입니다. 모놀리스 애플리케이션을위한 인터페이스를 노출하는 기술 중립적 인 방법이었습니다.

그러나 마이크로 서비스 패턴의 동기는 작고 미세하며 가벼운 느슨하게 결합 된 서비스를 수집 할 수있는 구조를 촉진하는 것입니다. 마이크로 서비스 패턴은 위에서 언급 한 명확한 의도, 독립적 개발 및 배포의 모든 목표를 권장합니다. 따라서 자연스럽게 모든 프레임 워크와 에코 시스템은 소규모 구현, 경량 상호 작용 프로토콜 (예 : REST), 독립 개발 / 배포 / 출시 등을 가능하게합니다. 크기 (마이크로) 및 단일 책임과 명확한 의도로 독립적으로 배포 할 수있는 서비스를 보유하려는 의도는 애플리케이션을 설계하기위한 방향과 전체 사고 프로세스를 설정하는 데 큰 역할을했으며, 이는 다시 단일 책임 원칙 (SRP)에 의해 주도됩니다.

다음 다이어그램은 마이크로 서비스의 그림보기를 나타냅니다.

웹 서비스 (및 유사)는 위의 목표를 달성하기 위해 기술 관점에서 모든 요소를 ​​가질 수 있습니다. 그러나 패턴 또는 표준으로서 '마이크로 서비스'는이를 촉진하도록 설계되었습니다.

간단히 말해 마이크로 서비스 아키텍처는 다음을 촉진합니다.

• 더 작은 크기의 느슨하게 결합 된 서비스
• 주로 자율적 인 소규모 팀에 의해 독립적으로 개발 될 수 있습니다.
• 독립적으로 배포 (및 릴리스) 가능
• 독립적으로 확장 가능하고 내결함성
• 모든 기술을 사용하여 구축 가능, 통신 프로토콜은 기술 중립적 임

그러나 아아 ..이 세상에서 완벽한 것은 없으며 모든 사용 사례에 대한 마이크로 서비스도 아닙니다. 마이크로 서비스에도 다양한 단점과 과제가 있습니다 (분산 애플리케이션 패턴과 유사 함). 이는 마이크로 서비스 아키텍처를 선택할 때 고려하는 것이 중요합니다.

다음 기사에서 마이크로 서비스, 다양한 과제 등에 대해 자세히 설명하겠습니다.

그때까지 계속 지켜봐주세요 ..