[MICROSERVICES] Message Queues and REST – An Approach with Go, NodeJS and Clean Architecture-Golang-php.cn

1. A Brief Context
2. Technologies and General Architecture
2.1. Microservices Architecture
2.2. Communication between Microservices
2.2.1. Message Queues (Asynchronous Communication)
2.2.2. REST APIs (Synchronous Communication)
2.3. Clean Architecture
3. The Project Ecosystem
4. Challenges and Final Considerations
4.1. Challenges in Implementation
4.2. Next Steps
4.3. Conclusion
5. References
6. Disclaimer

1. A brief context

In recent years, microservices architecture has become a popular choice for building scalable, flexible, and maintainable systems. By dividing an application into smaller and independent services, it is possible to maintain, test and upgrade each service autonomously, facilitating scalability and the inclusion of new technologies.

In this article, we will explore the creation of a microservices architecture using Go and NodeJS, two widely used languages and, in this context, with complementary characteristics. Additionally, we will apply the principles of Clean Architecture, a design approach that aims to keep code clean, modular, and easy to maintain and test, ensuring that business logic is isolated from infrastructure concerns and/or dependencies.

The objective of this project is to practice Go, a language that I have been studying recently, and revisit fundamental concepts of microservices. At the same time, we will use TypeScript in the development of services, applying the principles of Clean Architecture to reinforce good software design practices.

Based on these premises, we will have the opportunity to explore both the positive points and challenges of this approach. After all, not every business requires such a complex structure, and a practical project is the best way to understand its real needs and implications.

2. Technologies and General Architecture

2.1 Microservices Architecture

Microservices architecture divides an application into smaller, independent services, each responsible for a specific part of the functionality. These services communicate through well-defined APIs, which facilitates maintenance, scalability and adoption of new technologies.

Benefits:

Modularity: Facilitates the maintenance and independent development of each service.
Scalability: Allows individual scalability of each service according to demand.
Resilience: Isolates failures and reduces the impact of problems in one service on others.
Comparison with Monoliths:

Monoliths: Applications integrated into a single code base. Although simple initially, they can become difficult to maintain and scale over time.

Microservices: They offer greater flexibility and scalability, but can create additional complexity in management and communication between services.

2.2 Communication between Microservices

In a microservices architecture, communication between services can be done in two main ways: asynchronous communication, using message queues for examples, and synchronous communication, through REST APIs. It is worth highlighting that there are other forms of communication besides queue and rest.

2.2.1 Message Queues (Asynchronous Communication)

Message queues are used to enable asynchronous communication between microservices. They allow services to send and receive messages without requiring an immediate response, which helps improve system resilience and scalability.

Role of Message Queues:

Asynchronous Communication: Facilitates the exchange of information between services without the need for instant response.
Resilience: Manages load spikes and temporary failures, ensuring messages are eventually processed.

Implementation:

Tools: RabbitMQ and Kafka are popular options for managing message queues.
Integration: Implement message queues for communication between services written in Go and NodeJS, ensuring efficient and scalable data exchange.

2.2.2 REST APIs (Synchronous Communication)

RESTful APIs are used for synchronous communication between services. They are based on HTTP principles and allow services to interact in a standardized and efficient way.

2.3 Clean Architecture

Clean Architecture is a design approach that aims to create systems with a well-organized code base that is easy to maintain and/or test. It emphasizes separation of concerns and independence of layers.

Clean Architecture Principles:

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

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

3. 프로젝트 생태계

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

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

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

최종 그림:

[MICROSERVICES] Message Queues e REST – Uma Abordagem com Go, NodeJS e Clean Architecture

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

4. 과제 및 최종 고려사항

4.1 구현의 과제

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

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

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

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

4.2 다음 단계

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

모니터링 및 관측 가능성 리소스 포함: 모니터링 및 관측 가능성 도구를 구현하는 것은 시스템 상태와 성능을 보장하는 데 필수적입니다. 측정항목, 로그 및 추적 기능이 포함되어 있어 문제를 식별하고 생산 시 시스템 동작을 분석하는 데 도움이 됩니다.
사용 불가에 대한 처리 추가: 시스템의 복원력을 높이고 서비스 연속성을 보장하려면 재시도, 회로 차단기, 대체 전략과 같은 오류 및 비가용성을 처리하는 메커니즘을 포함하는 것이 중요합니다.# #
단위 및 통합 테스트 수행: 테스트는 코드의 품질과 구성 요소의 올바른 통합을 보장하는 데 필수적입니다. 단위 테스트는 코드의 분리된 부분의 기능을 확인하는 반면, 통합 테스트는 시스템의 다양한 구성 요소가 함께 올바르게 작동하는지 확인합니다.
리팩터링 서비스 및 모듈: 기존 서비스 및 모듈을 검토하고 리팩터링하여 코드가 깔끔하고 읽기 쉬우며 Clean Architecture 원칙에 부합하는지 확인하는 것은 시스템의 유지 관리성과 확장성을 향상시키는 지속적인 작업입니다.# #

이 프로젝트는 잘 계획된 아키텍처의 효율성과 클린 아키텍처 원칙의 신중한 구현의 중요성을 보여주었습니다. 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

에서 검색함

부인 성명

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

The above is the detailed content of [MICROSERVICES] Message Queues and REST – An Approach with Go, NodeJS and Clean Architecture. For more information, please follow other related articles on the PHP Chinese website!