[MICROSERVICES] 메시지 큐 및 REST - Go, NodeJS 및 클린 아키텍처를 사용한 접근 방식

목차

• 1. 간략한 맥락
• 2. 기술 및 일반 아키텍처
• 2.1. 마이크로서비스 아키텍처
• 2.2. 마이크로서비스 간 통신
• 2.2.1. 메시지 대기열(비동기 통신)
• 2.2.2. REST API(동기 통신)
• 2.3. 클린 아키텍처
• 3. 프로젝트 생태계
• 4. 과제 및 최종 고려 사항
• 4.1. 구현의 과제
• 4.2. 다음 단계
• 4.3. 결론
• 5. 참고자료
• 6. 부인 성명

1. 간략한 맥락

최근 몇 년 동안 마이크로서비스 아키텍처는 확장 가능하고 유연하며 유지 관리가 가능한 시스템을 구축하기 위한 인기 있는 선택이 되었습니다. 애플리케이션을 더 작고 독립적인 서비스로 분할함으로써 각 서비스를 자율적으로 유지 관리, 테스트 및 업그레이드할 수 있어 확장성과 새로운 기술의 포함이 용이해집니다.

이 기사에서는 널리 사용되는 두 가지 언어인 Go와 NodeJS를 사용하고 이러한 맥락에서 상호 보완적인 특성을 지닌 마이크로서비스 아키텍처를 생성하는 방법을 살펴보겠습니다. 또한 코드를 깔끔하게 유지하고, 모듈식으로 유지 관리 및 테스트하기 쉽게 하는 것을 목표로 하는 설계 접근 방식인 Clean Architecture의 원칙을 적용하여 비즈니스 로직이 인프라 문제 및/또는 종속성으로부터 격리되도록 할 것입니다.

이 프로젝트의 목표는 제가 최근 공부하고 있는 언어인 Go를 연습하고 마이크로서비스의 기본 개념을 다시 살펴보는 것입니다. 동시에 서비스 개발에 TypeScript를 사용하여 Clean Architecture의 원칙을 적용하여 좋은 소프트웨어 설계 관행을 강화할 것입니다.

이러한 전제를 바탕으로 우리는 이 접근 방식의 긍정적인 점과 과제를 모두 탐구할 기회를 갖게 될 것입니다. 결국 모든 비즈니스에 그렇게 복잡한 구조가 필요한 것은 아니며 실용적인 프로젝트가 실제 요구 사항과 의미를 이해하는 가장 좋은 방법입니다.

2. 기술 및 일반 아키텍처

2.1 마이크로서비스 아키텍처

마이크로서비스 아키텍처는 애플리케이션을 각각 기능의 특정 부분을 담당하는 더 작고 독립적인 서비스로 나눕니다. 이러한 서비스는 유지 관리, 확장성 및 새로운 기술 채택을 용이하게 하는 잘 정의된 API를 통해 통신합니다.

혜택:

모듈화: 각 서비스의 유지 관리 및 독립적인 개발을 촉진합니다.
확장성: 수요에 따라 각 서비스의 개별 확장이 가능합니다.
탄력성: 장애를 격리하고 한 서비스의 문제가 다른 서비스에 미치는 영향을 줄입니다.
모놀리스와의 비교:

모놀리스: 단일 코드 기반으로 통합된 애플리케이션입니다. 처음에는 간단하지만 시간이 지남에 따라 유지 관리 및 확장이 어려워질 수 있습니다.

마이크로서비스: 더 뛰어난 유연성과 확장성을 제공하지만 서비스 간 관리 및 통신이 더욱 복잡해질 수 있습니다.

2.2 마이크로서비스 간 통신

마이크로서비스 아키텍처에서 서비스 간 통신은 두 가지 주요 방식, 즉 메시지 큐를 사용하는 비동기 통신과 REST API를 통한 동기 통신으로 수행될 수 있습니다. 대기열과 휴식 외에 다른 형태의 의사소통도 있다는 점은 주목할 만합니다.

2.2.1 메시지 큐(비동기 통신)

메시지 대기열은 마이크로서비스 간의 비동기 통신을 활성화하는 데 사용됩니다. 서비스가 즉각적인 응답 없이 메시지를 보내고 받을 수 있도록 하여 시스템 복원력과 확장성을 향상시키는 데 도움이 됩니다.

메시지 대기열의 역할:

비동기 통신: 즉각적인 응답 없이 서비스 간 정보 교환을 촉진합니다.
탄력성: 로드 급증과 일시적인 오류를 관리하여 메시지가 최종적으로 처리되도록 합니다.

구현:

도구: RabbitMQ 및 Kafka는 메시지 대기열 관리에 널리 사용되는 옵션입니다.
통합: Go와 NodeJS로 작성된 서비스 간 통신을 위한 메시지 대기열을 구현하여 효율적이고 확장 가능한 데이터 교환을 보장합니다.

2.2.2 REST API(동기 통신)

RESTful API는 서비스 간 동기 통신에 사용됩니다. 이는 HTTP 원칙을 기반으로 하며 서비스가 표준화되고 효율적인 방식으로 상호 작용할 수 있도록 합니다.

2.3 클린 아키텍처

클린 아키텍처는 유지 관리 및/또는 테스트가 용이하고 잘 구성된 코드 기반으로 시스템을 만드는 것을 목표로 하는 설계 접근 방식입니다. 관심사의 분리와 레이어의 독립성을 강조합니다.

클린 아키텍처 원칙:

레이어 분리: 코드를 별개의 레이어(도메인, 애플리케이션, 인프라)로 나누어 비즈니스 로직을 기술적 문제로부터 분리합니다.
프레임워크 및 라이브러리로부터의 독립성: 비즈니스 로직이 특정 프레임워크나 기술에 종속되지 않도록 합니다.
마이크로서비스 애플리케이션:

코드 구성: 클린 아키텍처 원칙에 따라 각 마이크로서비스를 구조화하여 모듈식이고 테스트 가능하며 유지 관리가 쉬운 코드를 보장합니다.
유지 관리 및 발전: 시스템 무결성을 손상시키지 않으면서 새로운 기능을 추가하고 기존 기능을 수정할 수 있습니다.

3. 프로젝트 생태계

마이크로서비스 생태계에서 HTTP 엔드포인트는 문서 워크플로를 조정하는 데 중요한 역할을 하며, 이러한 맥락에서 모든 것이 시작됩니다. 이 끝점은 새 문서를 생성하라는 요청을 수신하고 처리하는 일을 담당합니다. 요청을 받으면 문서 생성 및 처리를 담당하는 Go 작업자에게 문서를 대기열에 넣습니다. 또한 끝점은 메시지 대기열을 통해 문서 서비스에 알림을 보내 새 리소스, 즉 문서가 처리를 위해 대기열에 입력되었음을 알립니다. 이 접근 방식은 시스템 구성 요소 간의 효율적인 통합을 보장하여 엔드포인트가 조정되고 비동기적인 방식으로 문서 생성 및 추적을 관리할 수 있도록 하며, Go 작업자는 실제 문서 생성을 처리하고 문서 서비스는 새 항목에 대해 업데이트됩니다. 대기열.

HTTP 엔드포인트 외에도 시스템에는 서로 다른 역할을 가진 두 명의 작업자가 있습니다. Go로 구현된 첫 번째는 문서 생성을 담당합니다. 메시지 큐의 작업을 사용하고, 데이터를 처리하고, 처리가 완료되면 특정 엔드포인트에 완료를 알립니다. Go의 효율성은 빠르고 강력한 처리를 보장합니다. NodeJS에서 개발된 두 번째 작업자는 문서의 초기 상태 생성을 처리하고 시스템에 삽입될 때 "처리되지 않음"으로 정의합니다. NodeJS의 민첩성 덕분에 워크플로 시작부터 문서 상태를 빠르고 효율적으로 관리할 수 있습니다.

요약하자면, 설명된 시스템은 문서 관리를 위한 잘 조율된 흐름을 보여줍니다. Go 및 NodeJS 작업자와 함께 HTTP 엔드포인트는 통합되고 효율적인 솔루션을 제공하여 생성부터 완료까지 문서 처리를 보장합니다. 작업자와 REST 간의 상호 작용은 아래 아키텍처 이미지에 반영되어 있습니다. 이는 아키텍처가 어떻게 확장성과 모듈성을 촉진하여 강력하고 조정된 워크플로를 보장하는지 보여줍니다. 이 접근 방식은 운영 효율성을 향상시킬 뿐만 아니라 다양한 사용 시나리오에 맞게 조정하여 유연성과 향후 성장을 제공할 수 있습니다.

최종 도면:

프로젝트 저장소: https://github.com/williamMDsilva/microservice-poc

4. 과제 및 최종 고려사항

4.1 구현의 과제

Clean Architecture로 마이크로서비스 아키텍처를 구현하면 몇 가지 과제가 발생할 수 있습니다. 주요 과제 중 하나는 진정으로 확장 가능하고 비즈니스 로직의 무결성을 유지하는 코드를 만들기 위해 비즈니스를 깊이 이해하는 것입니다. 클린 아키텍처에서는 문제를 명확하게 분리하는 방식으로 코드를 구성해야 하며, 추상화와 분리가 효과적이려면 도메인에 대한 자세한 지식이 필요합니다.

또한 SOLID 원칙에 대한 지식도 중요합니다. 이러한 원칙은 더욱 응집력 있고 덜 결합된 코드를 만드는 데 도움이 되며, 이를 확실히 이해하면 연구 및 문제 해결에 소요되는 시간을 크게 절약할 수 있습니다. SOLID 원칙을 적용하면 코드 품질이 향상될 뿐만 아니라 시스템 유지 관리 및 확장성이 용이해집니다.

구체적인 Go의 경우 언어의 탄탄한 기반이 코드 가독성과 유지 관리성을 향상시킬 수 있습니다. Go는 코드를 깔끔하고 효율적으로 유지하는 데 도움이 되는 도구와 사례를 제공하며, 복잡한 서비스를 구현할 때 더 깊은 지식이 차이를 만들 수 있습니다.

마지막으로, 좋은 상용구를 사용하는 것은 매우 유익할 수 있습니다. 클린 아키텍처를 위해 잘 설계된 상용구는 개발 시작 속도를 높일 뿐만 아니라 처음에 제안된 표준에 새로운 기능이 추가되도록 보장합니다. 프로젝트 전반에 걸쳐 코드 일관성과 품질을 유지하는 데 도움이 되는 구조를 제공합니다.

4.2 다음 단계

설명된 아키텍처를 발전시키고 개선하려면 다음 단계를 권장합니다.

1. 모니터링 및 관찰 리소스 포함: 모니터링 및 관찰 도구 구현은 시스템 상태와 성능을 보장하는 데 필수적입니다. 측정항목, 로그 및 추적 기능이 포함되어 있어 문제를 식별하고 생산 시 시스템 동작을 분석하는 데 도움이 됩니다.

2. 가용성 저하에 대한 처리 추가: 시스템의 복원력을 높이고 서비스 연속성을 보장하려면 재시도, 회로 차단기, 폴백 전략 등 장애 및 비가용성을 처리하는 메커니즘을 포함하는 것이 중요합니다.

3. 단위 및 통합 테스트 수행: 테스트는 코드 품질과 구성 요소의 올바른 통합을 보장하는 데 필수적입니다. 단위 테스트는 코드의 분리된 부분의 기능을 확인하는 반면, 통합 테스트는 시스템의 다양한 구성 요소가 함께 올바르게 작동하는지 확인합니다.

4. 서비스 및 모듈 리팩터링: 기존 서비스 및 모듈을 검토하고 리팩토링하여 코드가 깔끔하고 읽기 쉬우며 Clean Architecture 원칙에 부합하는지 확인하는 것은 시스템의 유지 관리 가능성과 확장성을 향상시키는 지속적인 작업입니다.

5. Kafka를 사용한 개념 증명: RabbitMQ를 Kafka로 대체하기 위한 개념 증명을 고려하면 다양한 도구가 프로젝트에 어떤 영향을 미치는지에 대한 통찰력을 얻을 수 있습니다. 서비스 디자인 및 전체 아키텍처에 대한 영향 분석은 향후 기술 결정에 대한 귀중한 통찰력을 제공할 수 있습니다.

4.3 결론

이 프로젝트는 잘 계획된 건축의 효과와 클린 건축 원칙의 신중한 구현의 중요성을 보여주었습니다. SOLID, 메시지 대기열 및 REST API 사용과 같은 방식과 결합된 Go 및 NodeJS의 사용은 강력하고 확장 가능한 시스템에 기여했습니다. 그러나 마이크로서비스 아키텍처를 개발하고 유지 관리하려면 비즈니스와 기술에 대한 심층적인 지식이 필요한 과제가 있습니다. 적절한 계획과 모범 사례 채택을 통해 이러한 문제를 해결하면 효율적이고 지속 가능한 시스템을 구축하는 데 도움이 됩니다. 앞으로 나아갈 길에는 고급 모니터링, 새로운 개념 증명과 같은 지속적인 개선을 통합하여 비즈니스의 요구 사항과 발전에 맞춰 아키텍처를 유지하는 것이 포함됩니다.

5. 참고자료

마틴, R.C.(2008). 클린 코드: 실용적이고 민첩한 소프트웨어 기술. 알타북스.

마틴, R.C.(2017). 클린 아키텍처: 소프트웨어 설계를 위한 프레임워크 및 원칙. 알타북스.

RabbitMQ. (n.d.). 튜토리얼 2 - 자바스크립트. https://www.rabbitmq.com/tutorials/tutorial-two-javascript

에서 가져옴

RabbitMQ. (n.d.). 튜토리얼 2 - https://www.rabbitmq.com/tutorials/tutorial-two-go에서 가져옴

부인 성명

이 프로젝트의 학문적 및 개념 증명 특성으로 인해 일부 기능은 구현되지 않았으며 향후 연구를 위한 기술 부채로 남아 있습니다. 자동화된 테스트, 오류 처리, 리소스 스트리밍, 서비스 인증 및 관찰 가능성과 같은 영역은 여전히 ​​탐구해야 할 주제입니다. 모든 건설적인 비판은 이러한 중요한 영역에 대한 지속적인 개선과 지식 심화에 기여하므로 환영하고 장려됩니다.

위 내용은 [MICROSERVICES] 메시지 큐 및 REST - Go, NodeJS 및 클린 아키텍처를 사용한 접근 방식의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!