서보 모터 프로젝트가 마이크로서비스를 만나는 경우: 메시지 대기열이 필요한 이유와 실습

그림을 그려보세요. 각 관절이 독립적인 서보 모터에 의해 제어되는 로봇 팔을 디버깅하고 있습니다. 이러한 모터는 실시간으로 함께 작동해야 하지만 지침은 서로 다른 마이크로서비스에서 나옵니다. 하나는 궤적을 계산하고, 하나는 센서 피드백을 처리하고, 다른 하나는 안전 로직을 관리합니다. 갑자기 높은 부하로 인해 특정 서비스가 몇 밀리초 동안 속도가 느려지고 전체 작업이 멈추거나 심지어 동기화되지 않게 됩니다. 그 순간, 이러한 서비스를 통해 대화가 좀 더 '원활'해지면 좋겠다고 생각하셨나요?

이는 실제로 기계적 제어에서 발생하는 문제만이 아닙니다. 마이크로서비스로 분할된 모든 시스템은 비슷한 문제에 직면합니다. 서비스 간에 안정적이고 효율적으로 통신하는 방법은 무엇입니까? 데이터가 손실되지 않고, 순서가 엉망이 되지 않으며, 갑작스러운 트래픽을 견딜 수 있는지 어떻게 보장할 수 있습니까?

우리는 몇 년 전 자동 분류 라인을 업그레이드하면서 이 벽에 부딪혔습니다. 직접 HTTP 호출과 같은 전통적인 방법은 서비스가 증가함에 따라 취약해집니다. 한 서비스가 중단되면 링크의 다른 서비스도 영향을 받습니다. 최대 요청이 발생하자마자 시스템이 대기하기 시작하고 실시간 성능은 의문의 여지가 없습니다. 우리에게는 "컨베이어 벨트"와 유사한 메커니즘이 필요합니다. 즉, 데이터를 여기에 저장하고 필요한 장소가 서로를 차단하지 않고 각자의 속도로 데이터에 액세스할 수 있도록 하는 것입니다.

그래서 우리는 찾기 시작했고 결국 Kafka를 소개하게 되었습니다.

카프카란 무엇인가? 고속의 스마트 조립 라인이라고 생각하세요

익숙한 장면을 비유로 사용하면 Kafka는 공장의 끝없는 컨베이어 벨트와 같습니다. 각 마이크로서비스는 워크스테이션으로 간주될 수 있습니다. A 스테이션에서는 반제품(메시지)을 컨베이어 벨트에 올리고, B 스테이션과 C 스테이션에서는 필요에 따라 언제든지 반제품(메시지)을 꺼내어 처리합니다. 컨베이어 벨트 자체는 계속해서 작동합니다. 특정 역이 일시적으로 수리되더라도 반제품은 사라지지 않고 역이 인계될 때까지 줄을 서서 조용히 기다릴 뿐입니다.

이는 여러 가지 문제를 해결합니다.

• 디커플링: 서비스는 더 이상 직접 "전화"하지 않고 컨베이어 벨트를 통해 전달됩니다. 보낸 사람은 메시지를 삭제하고 누가 언제 처리할지 알지 못한 채 자리를 떠납니다.
• 완충기: 업스트림에서 갑자기 많은 양의 데이터(예: 센서의 갑작스런 고주파 신호)가 생성되면 컨베이어 벨트가 이를 일시적으로 운반할 수 있고 다운스트림에서는 자체 능력에 따라 소화하여 압도되지 않도록 할 수 있습니다.
• 신뢰할 수 있음: 메시지는 컨베이어 벨트에 지속되며, 일부 서비스를 다시 시작하더라도 데이터는 손실되지 않습니다.
• 순차적: 컨베이어 벨트에서는 아이템의 순서가 정해져 있습니다. 이는 모터 제어 명령과 같은 순서에 민감한 데이터에 중요합니다.

어떻게 사용하나요? 비선형 실험

처음에는 팀의 일부 사람들이 "이게 너무 복잡한 걸까요? 새로운 미들웨어 세트를 유지 관리해야 합니다."라고 걱정했습니다. 그러나 실제로 우리는 그것이 초고층 건물을 짓는 것보다 빌딩 블록에 더 가깝다는 것을 발견했습니다.

우리는 완전한 점검으로 시작하지 않았습니다. 대신에 우리는 테스트를 위해 가장 명백한 문제점이 있는 링크, 즉 로봇 팔의 상태 모니터링을 선택했습니다. 상태 데이터는 한 서비스에서 다른 서비스로 푸시되고 네트워크 지터로 인해 종종 손실되어 모니터링 패널이 때때로 "조각화"되는 것으로 나타났습니다. 우리는 단순히 Kafka 토픽(전용 컨베이어 벨트로 이해될 수 있음)을 설정하고 상태 게시 서비스가 여기에 데이터를 쓰도록 하고 모니터링 서비스가 이를 구독하도록 했습니다. 거의 즉시 조각화 문제가 사라졌습니다. 모니터링 서비스가 일시적으로 오프라인 상태이더라도 다시 시작한 후 중단점에서 처리되지 않은 모든 상태 업데이트를 계속 읽을 수 있기 때문입니다.

이 작은 성공이 우리에게 자신감을 주었습니다. 그런 다음 주문 지침 흐름과 알람 이벤트 흐름을 점차적으로 마이그레이션했습니다. 점차적으로, 실시간 물류 지도를 보는 것처럼 전체 시스템의 데이터 흐름이 명확해집니다. 어떤 노선이 혼잡하고 어떤 노선이 유휴 상태인지 한눈에 알 수 있습니다.

실제 단편과 감정

물론 그 과정에서 약간의 탐색도 있었습니다. 예를 들어, 우리는 "컨베이어 벨트(주제)를 몇 개로 나누어야 하는가?"라고 고민한 적이 있습니다. 나중에 우리는 작업장처럼 모든 부분이 한 줄에 섞이지 않을 것이며 데이터 도메인과 긴급성에 따라 별도로 관리하는 것이 더 합리적이라는 것을 알게 되었습니다. 모터 제어 명령에는 낮은 대기 시간이 필요하고 별도의 고속 회선이 필요합니다. 로그 및 감사 데이터는 볼륨이 크지만 실시간 요구 사항이 낮으므로 다른 고용량 라인을 사용하십시오. 서로 간섭하지 않고 각자의 길을 가고 있습니다.

어떤 사람들은 "컨베이어 벨트 자체가 파손되면 어떻게 되나요?"라고 묻기도 합니다. Kafka의 분산 디자인은 본질적으로 중복됩니다. 데이터는 여러 노드에 백업됩니다. 단일 노드에 장애가 발생하면 다른 노드가 즉시 인계받을 수 있으며 서비스는 거의 눈에 띄지 않습니다. 변속기에 예비 엔진을 넣는 것과 같습니다.

지금 돌이켜보면 카프카의 도입은 시스템을 더 '복잡하게' 만든 것이 아니라, 원래 보이지 않았던 혼돈을 질서정연하게 만들었다. 마이크로서비스 간의 긴장된 직접 결합 관계가 완화되었습니다. 각 서비스는 자체 로직에 더 집중할 수 있으며 전체 아키텍처의 유연성이 크게 향상되었습니다. 생산 라인을 확장해야 하고 새로운 검사 스테이션을 추가해야 하는 경우 해당 주제에 대한 새로운 서비스를 구독하기만 하면 됩니다. 이는 다른 부분을 전혀 방해하지 않고 컨베이어 벨트 옆에 새 스테이션을 추가하는 것처럼 간단합니다.

선택에 대해 이야기해보자

시중에는 많은 메시지 대기열 도구가 있는데 Kafka를 선택하는 이유는 무엇입니까? 우리는 높은 처리량, 지속성 및 시퀀스 보장 측면에서 균형 잡힌 성능을 중요하게 생각합니다. 가장 화려한 기능을 갖춘 것은 아닐 수도 있지만, 데이터 스트림의 안정적인 처리가 필요한 산업 시나리오에는 충분히 견고합니다. 물론 만능 도구는 없으며 학습 곡선과 운영 및 유지 관리 비용에 투자가 필요합니다. 그러나 통신 문제로 인해 마이크로서비스가 "조율되지 않은 상태로 작동"하기 시작하는 경우 시스템에 이러한 "지능형 컨베이어 벨트" 세트를 설치하는 것을 고려해 볼 가치가 있습니다.

결국, 좋은 기술은 신뢰할 수 있는 기계식 변속기와 같아 조용하고 정확하며 복잡한 협업을 쉽게 만들어줍니다.

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