서보 모터가 마이크로서비스를 만났을 때: 편안한 아키텍처 대화

비슷한 일을 겪은 적이 있나요? 모터는 안정적이지만 수십 개의 다른 장치와 함께 작동하면 시스템을 예측할 수 없게 됩니까? 오늘은 고급 이론을 이야기하는 대신, 빌딩 블록과 같은 제어 시스템의 구성을 다시 생각하는 방법에 대해 이야기해 보겠습니다.

문제는 세부사항에 숨겨져 있다

당신이 조립 라인을 담당하고 있다고 상상해보십시오. 6개의 서보 모터는 정확한 위치 지정을 담당하고, 3개의 서보는 완벽한 각도 미세 조정을 담당하며, 로봇 팔은 고정된 리듬으로 부품을 운반합니다. 처음에는 모든 제어 로직이 중앙 컨트롤러에 작성되었습니다. 이는 모든 가구를 방에 밀어넣는 것과 같이 매우 일반적이었습니다. 처음에는 깔끔해 보였지만 요구사항이 바뀌면서 조정할 때마다 여기저기 뒤져야 했습니다.

어느 날 패키징 섹션의 속도를 일시적으로 20% 늘려야 하는데 매개변수를 조정하면 실제로 업스트림 위치 정확도에 영향을 미친다는 사실을 알게 되었습니다. 혹은 특정 센서 데이터에 이상이 있을 경우 전체 시스템 로그가 엉망이 되어 문제의 원인을 추적하기 어려운 경우도 있다. 보다 일반적으로는 모터 모델 중 하나를 변경하려는 경우 관련 코드를 많이 다시 작성해야 합니다.

이것은 "결함"이 아니라 시스템을 다르게 구성해야 할 때라는 아키텍처의 속삭임입니다.

마이크로서비스: 각 기능에 별도의 공간 제공

우리는 생각을 바꿀 수 있습니다. 각 모터의 제어 논리가 독립적으로 실행될 수 있다면 어떨까요? 예를 들어:

• 포지셔닝 서보 모터는 목표 명령에 어떻게 응답할지 자체적으로 결정하고, 명확한 인터페이스를 통해 시스템에 "나는 위치에 있습니다"만 알려줍니다.
• 압력 감지 장치는 센서 데이터 분석에 중점을 두고 이상이 발생하면 표준 형식 알림을 발행합니다.
• 모션 계획 모듈은 최적의 경로를 계산하는 데 중점을 두고 있으며 다른 모듈의 코드 변경에 영향을 받지 않습니다.

이 접근 방식에는 마이크로서비스 아키텍처라는 이름이 있습니다. 용어에 겁먹지 마세요. 그 본질은 간단합니다. 대규모 시스템을 독립적으로 개발, 배포 및 확장할 수 있는 작은 서비스 세트로 나누는 것입니다. 레고 브릭과 마찬가지로 각 부품은 기능이 명확하지만 결합 방법을 유연하게 조정할 수 있습니다.

누군가는 "이것이 복잡성을 더하는가?"라고 물을 수도 있습니다. 좋은 질문입니다. 단기적으로는 서비스 간 통신을 위한 일부 표준(예: 명확하게 정의된 데이터 형식)을 설계해야 하지만 장기적으로는 시스템의 의도하지 않은 결합을 줄여줍니다. 모듈 업그레이드가 필요할 때 모든 기능을 테스트하기 위해 전체 생산 라인을 중단할 필요가 없습니다.

이 아이디어가 하드웨어 제어 시나리오에 적합한 이유는 무엇입니까?

서보 모터와 기계 시스템은 오랜 시간 동안 작동하는 경향이 있다는 특징이 있습니다. 생산 라인은 5년 또는 10년 동안 계속 작동할 수 있으며, 그 동안 수많은 부분 및 구성 요소 교체와 새로운 기능이 발생하게 됩니다. 전통적인 모놀리식 아키텍처는 거대한 유화와 같으며 세부 사항을 수정하려면 전체 캔버스를 다시 그려야 할 수도 있습니다.

마이크로서비스 아키텍처는 각 시트에 특정 기능이 기록된 스케치북 세트와 같습니다. 로봇 팔의 잡기 논리를 수정하시겠습니까? 서비스의 해당 부분만 업데이트하고 인터페이스가 변경되지 않은 상태에서 다른 모듈과 정상적으로 통신하는지 확인하기만 하면 됩니다.

kpower고객이 이러한 유형의 아키텍처를 구현하도록 지원할 때 다음과 같은 몇 가지 흥미로운 변경 사항을 자주 볼 수 있습니다.

• 로그가 서비스별로 자연스럽게 분리되어 문제 해결 시간이 평균 40% 단축됩니다.
• 하드웨어 반복 주기가 더욱 유연해졌으며, 모터 모델을 변경하려면 해당 서비스만 조정하면 되는 경우가 많습니다.
• 새로운 기능을 테스트하는 데 드는 비용이 줄어들고 전체 라인에 영향을 주지 않고 격리된 환경에서 특정 모듈을 테스트할 수 있습니다.

개념부터 실습까지 3단계

이 아키텍처가 흥미롭다면 다음 세 단계를 거쳐 시도해 볼 수 있습니다.

1단계: 기능적 경계를 그립니다. 종이 한 장을 꺼내서 물리적 기능에 따라 제어 시스템을 분할하세요. 어떤 부분이 긴밀하게 결합되어 있습니까(예: 동일한 모터의 구동 및 피드백 처리)? 가끔씩만 데이터를 교환하는 부품은 무엇입니까(예: 공급 메커니즘 및 품질 검사 장치)? 자연스러운 물리적 경계는 마이크로서비스 파티셔닝의 좋은 출발점이 되는 경우가 많습니다.

2단계: 대화 규칙 정의 생산 라인의 작업자가 반제품을 넘겨야 하는 것처럼 서비스도 의사소통이 필요합니다. 데이터 형식에 동의합니다. 예를 들어 모든 위치 정보에는 타임스탬프, 단위 및 신뢰 수준이 포함됩니다. 모든 지침에는 쉽게 추적할 수 있도록 고유 번호가 있습니다. 이러한 규칙은 처음부터 완벽할 필요는 없지만 명확한 규칙을 사용하면 나중에 혼란을 피할 수 있습니다.

3단계: 처음부터 리팩터링 전체 시스템을 한 번에 다시 작성할 필요가 없습니다. 최근 개선이 필요한 모듈(예: 골치 아픈 패키징 섹션 서보 모터)을 선택하여 먼저 독립 서비스로 변환합니다. 동작이 안정적인지 확인한 후 점차적으로 확장해 나가세요. 이러한 점진적인 변화는 생산 라인의 지속적인 운영에 더욱 친화적입니다.

때로는 답이 질문 밖에 있을 때도 있다

저는 처음에 언급한 친구가 자주 생각납니다. 그는 마이크로서비스 아이디어를 사용해 제어 로직의 일부를 재구성하기 시작하면서 응답 지연 문제를 해결했을 뿐만 아니라, 자신의 팀이 보다 자연스럽게 노동을 나누기 시작했다는 사실을 뜻밖에도 발견했습니다. 기계구조를 담당하는 엔지니어는 모션 플래닝 서비스에 집중하고, 전기엔지니어는 드라이브 제어 모듈에 깊이 관여합니다. 둘은 동일한 코드 파일에서 서로 주석을 달기보다는 명확하게 정의된 인터페이스를 통해 협업합니다.

이것은 아키텍처의 또 다른 선물일 수 있습니다. 코드를 정리할 뿐만 아니라 사람들이 협업하는 방식도 정리합니다. 각 기능 모듈에 명확한 책임 경계가 있으면 유지 관리가 동시에 추진될 수 있습니다.

물론 어떤 아키텍처도 만능은 아닙니다. 마이크로서비스는 서비스 간 네트워크 통신을 고려하게 되며 보다 자세한 모니터링 설계가 필요합니다. 그러나 장기적인 발전과 빈번한 현지화를 요구하는 하드웨어 제어 시스템의 경우 이러한 "분할 및 정복" 철학은 종종 예상치 못한 용이성을 가져올 수 있습니다.

결국 기술 아키텍처는 방 레이아웃과 같습니다. 어떤 사람들은 모든 것을 열린 공간에 두는 것을 좋아하는데, 이는 한눈에 명확하지만 현지에서 조정하기가 어렵습니다. 어떤 사람들은 각 기능에 별도의 공간을 제공하는 것을 선호합니다. 이렇게 하려면 초기 단계에서 몇 가지 단계를 더 거쳐야 하지만 각 공간은 각자의 속도에 맞춰 개조될 수 있습니다.

현재 귀하의 시스템은 어떤 종류의 방처럼 보입니까?

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