마이크로서비스 .net 코어에 Rabbitmq 구현

서보 모터가 마이크로서비스에 연결되는 경우: RabbitMQ를 사용하여 .NET Core 시스템을 "활성"으로 만듭니다.

로봇 팔을 제어하는 ​​서보 모터나 다축 동작을 조정하는 서보 네트워크 등 정교한 기계 시스템을 설계한다고 상상해 보세요. 모든 것이 완벽하게 계산되었고 모든 부분이 계획대로 작동했습니다. 어느 날 특정 모터의 피드백이 0.1초 지연되면서 조립 라인 전체가 갑자기 기어가 멈춘 것처럼 보였고 이후의 모든 작업은 혼란에 빠졌습니다. 서로 다른 모듈 간에는 데이터가 차단되고, 지시사항은 좁은 골목에 교통체증이 발생하는 것처럼 점점 빨라지고 느려진다.

이는 기계 시스템만의 딜레마가 아닙니다. 소프트웨어 세계에서는 대규모 애플리케이션을 여러 개의 독립적인 소규모 서비스, 즉 마이크로서비스로 분할할 때 비슷한 문제가 매일 발생합니다. 서비스는 서로 통신하고, 데이터를 전송하고, 상태를 동기화해야 합니다. 이러한 "대화"가 혼란스럽거나, 손실되거나, 교통 정체에 걸리는 것을 방지하는 방법은 무엇입니까? 많은 사람들이 특히 .NET Core 환경에서 RabbitMQ를 선택합니다. 하지만 선택한 후에 어떻게 하면 실제로 원활하게 작동할 수 있을까요?

왜 RabbitMQ인가? 스마트 우체국 같아요

각 마이크로서비스를 독립적인 워크샵으로 생각할 수 있습니다. A 워크숍에서 부품을 생산한 후 B 워크숍에 가공을 통보해야 합니다. 가장 간단하고 조잡한 방법은 A 작업장에서 심부름을 할 사람을 보내 B 작업장 문에 소리를 지르는 것입니다. 그러나 B 작업장이 바쁘거나 일시적으로 문을 닫으면 메시지가 손실됩니다. 더 나쁜 것은, 통보할 공방이 100개나 된다면 심부름꾼은 지쳐 마비될 것입니다.

RabbitMQ가 하는 일은 이러한 혼란을 없애는 것입니다. 서비스 간 직통 전화선을 구축하는 대신 중간에 '스마트 우체국'을 설치한다. 작업장 A는 메시지(예: "부품 준비 완료")를 우체국에 보내기만 하면 작업장 B를 전혀 기다리지 않고 작업을 계속할 수 있습니다. 워크샵 B가 한가할 때 그는 우체국에서 자신의 편지를 직접 픽업할 것입니다. B 워크숍이 일시적으로 중단되더라도 편지는 회수될 때까지 우체국에 안전하게 보관됩니다.

.NET Core에서 이를 구현하는 것은 서보 제어 시스템에 버퍼 및 라우팅 허브를 추가하는 것과 같습니다. 특정 서비스(주문 처리 등)가 순간적으로 많은 양의 요청을 받았을 때, 이를 자체적으로 처리할 필요는 없습니다. 대신 작업 메시지를 대기열에 넣고 백그라운드 인벤토리 서비스가 자체 기능에 따라 메시지를 천천히 소화하도록 합니다. 한 링크의 짧은 피크로 인해 시스템이 더 이상 완전히 붕괴되지 않습니다.

구체적으로 어떻게 해야 할까요? 시스템이 원활하게 호흡할 수 있도록 하는 몇 가지 단계

RabbitMQ의 "우체국"을 설정해야 합니다. 일반적으로 서버나 컨테이너에서 독립적으로 실행됩니다. 그런 다음 .NET Core 프로젝트에서 NuGet을 통해 RabbitMQ.Client와 같은 클라이언트 라이브러리를 설치합니다. 이는 각 상점에 중앙 우체국을 처리하는 방법을 아는 전문가가 있는 것과 같습니다.

주요 단계는 실제로 매우 명확합니다. 하나는 연결을 정의하고 서비스에 우체국이 어디에 있는지 알려주는 것입니다. 두 번째는 전용 메일링 라인을 개설하는 등의 채널을 만드는 것입니다. 세 번째는 대기열을 선언하고 메시지 사서함에 이름(예: motor_command_queue)을 지정하는 것입니다. 그런 다음 생산자 서비스는 BasicPublish를 사용하여 메시지를 보내고 소비자 서비스는 BasicConsume을 사용하여 이를 수신하고 처리합니다.

하지만 그것은 단지 해골일 뿐입니다. 정말로 시스템을 우아하게 만드는 것은 세부 사항을 고려하는 것입니다. 예를 들어 메시지 형식을 지정하는 방법은 무엇입니까? JSON 또는 Protobuf를 사용하시겠습니까? 메시지 처리 실패를 처리하는 방법은 무엇입니까? 원래 대기열에 다시 넣어야 합니까, 아니면 후속 조사를 위해 특별한 "데드 레터 대기열"로 전송해야 합니까? 메시지 순서를 어떻게 보장하나요? 이러한 선택에는 절대적인 답이 없습니다. 서보 피드백 곡선을 디버깅하는 것과 마찬가지로 실제 시나리오에 따라 미세 조정해야 합니다.

그것은 무엇을 가져올 수 있습니까? 지연이 없을 뿐만 아니라

RabbitMQ를 .NET Core 마이크로서비스에 통합하면 변경 사항이 실제로 발생합니다. 시스템 탄력성이 향상됩니다. 서비스가 일시적으로 실패하더라도 메시지는 사라지지 않고 복구 대기열에서 대기하게 됩니다. 확장도 쉽게 이루어집니다. 메시지를 처리하는 "B 작업장"이 너무 바쁜 경우 동일한 서비스의 두 번째 및 세 번째 인스턴스를 쉽게 시작하고 대기열에서 작업을 함께 수신하면 자연스럽게 부하가 공유됩니다.

더 중요한 것은 서비스 간의 결합이 느슨해진다는 것입니다. 그들은 더 이상 서로의 구체적인 주소와 건강 상태를 알 필요가 없으며, 중간에 있는 대기열만 식별하면 됩니다. 이를 통해 전체 생산 라인을 중단하지 않고도 서보 모터의 제어 펌웨어를 개별적으로 업그레이드할 수 있는 것처럼 각 서비스를 독립적으로 개발, 배포 및 업그레이드할 수 있습니다.

물론 그것도 마법은 아니다. RabbitMQ 서버 자체의 고가용성을 관리하고, 네트워크 대기 시간을 고려하고, 대기열 깊이를 모니터링하여 메시지 백로그를 방지해야 합니다. 그러나 이러한 문제를 처리할 수 있는 성숙한 모델과 도구가 있습니다.

일반적인 함정을 피하세요

처음 시도할 때 메시지가 전송되었으나 왜 수신되지 않았는지 느낄 수 있습니다. 확인 결과 큐 이름이 일치하지 않거나 메시지가 지속되지 않고 서버를 다시 시작하면 손실되는 경우가 많습니다. 또는 소비자가 메시지를 처리한 후 확인(ACK)하는 것을 잊어서 메시지가 반복적으로 전달됩니다.

또한 모든 메시지를 동일한 대기열에 넣지 마십시오. 하나의 사서함에 전송 부서와 제어 부서에 대한 지침을 혼합하지 않는 것과 같습니다. 메시지 유형과 긴급성에 따라 시스템 컨텍스트를 더 명확하게 만들기 위해 다양한 대기열 및 라우팅 규칙이 설계되었습니다.

감정

기술 도구의 가치는 궁극적으로 시스템을 우리가 원하는 시스템, 즉 신뢰성, 유연성, 탐색 용이성에 더 가깝게 만드는 방법에 반영됩니다. RabbitMQ를 마이크로서비스 아키텍처에 도입하는 것은 복잡한 기계 시스템에 정교한 버퍼링 및 피드백 메커니즘을 추가하는 것과 같습니다. 주인공이 아닌, 주인공들이 원활하게 조화를 이룰 수 있게 해주는 핵심 조연 역할이다.

좋은 구현을 통해 이러한 기술적 세부 사항이 점차 백그라운드로 사라지고 원활한 비즈니스 프로세스만 남게 됩니다. 더 이상 서비스 간 통신에 대해 걱정하지 않고 비즈니스 논리 자체에 더 집중할 수 있게 되면 이 메커니즘을 적절하게 설계해야 할 때일 것입니다. 잘 조정된 모션 제어 시스템과 마찬가지로 복잡한 PID가 항상 작동하는 것을 느끼지 못할 것입니다. 로봇 팔이 정확한 호를 부드럽게 그리는 모습만 볼 수 있습니다.

2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다.kpower스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론, 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.