안녕하세요, 혹시 서보 시스템 아키텍처를 선택하는 방법에 대해 고민하고 계시나요?

이때 많은 분들이 '구조를 조정해야 하나?'라고 생각하실 것입니다.

실제로 시스템 아키텍처는 상당히 추상적으로 들리지만 장비가 안정적으로 작동할 수 있는지, 유연하게 조정할 수 있는지, 어려움을 견딜 수 있는지를 직접적으로 결정합니다. 오늘은 서비스 기반 아키텍처와 마이크로서비스라는 두 가지 일반적인 아이디어에 대해 이야기하겠습니다. 비슷해 보이지만 사용법은 매우 다릅니다.

"서비스 기반 아키텍처"란 정확히 무엇입니까?

명확한 업무 분담을 갖춘 큰 팀이라고 생각하시면 됩니다. 팀의 모든 구성원은 고정된 책임을 갖고 있으며, 의사소통은 주로 조정을 담당하는 여러 "인터페이스 담당자"를 통해 이루어집니다. 전체 시스템은 하나의 전체이지만 내부적으로 기능에 따라 서비스 모듈로 구분됩니다. 예를 들어 자동화된 로봇 팔 시스템에서는 동작 제어, 센서 처리, 데이터 기록이 각각 서비스 모듈을 형성하고 정의된 방식으로 서로 호출합니다.

이점은 무엇입니까? 구조가 명확합니다. 유지 관리에 있어서는 어떤 모듈에 문제가 있는지 알 수 있습니다. 하지만 단점도 분명합니다. 즉, 모듈 간의 결합도가 여전히 높을 수 있다는 것입니다. 어느 날 로봇 팔의 제어를 완전히 변경하고 싶고, 여기에는 다른 서비스 조정도 포함될 수 있습니다.

그렇다면 마이크로서비스에 대한 접근 방식은 무엇입니까?

전자가 대규모 팀과 같다면 마이크로서비스는 유연한 팀 그룹에 가깝습니다. 각 팀은 극도로 독립적이며 자체 비즈니스에 주의를 기울이고 있으며 자체 "언어"(기술 스택)도 사용합니다. 이들은 단순 메시지 전달과 같은 경량 프로토콜을 통해 서로 통신합니다.

로봇 팔을 예로 들어보겠습니다. 마이크로서비스 아키텍처에서 경로 계획은 독립적인 서비스일 수 있고, 공동 운전은 또 다른 서비스이고, 실시간 모니터링은 또 다른 서비스일 수 있습니다. 각 서비스는 독립적으로 개발, 배포, 다시 시작될 수 있으며 심지어 다른 프로그래밍 언어로 작성될 수도 있습니다. 하나의 서비스에 문제가 있다고 해서 반드시 전체 시스템이 다운되는 것은 아닙니다.

그런데 좀… 어긋나는 것 같지 않나요? 관리하기가 더 번거로울까요?

그렇다면 어느 것을 선택해야 할까요?

이는 특정 시나리오에 따라 다릅니다. 의료 장비의 고정밀 스티어링 기어 그룹과 같이 강력한 실시간 성능이 필요한 고도로 통합된 정밀 모션 제어 시스템을 구축하는 경우 서비스 기반 아키텍처가 더 적합할 수 있습니다. 모듈 간의 통신은 직접적이고 빠르며 더욱 통합되어 있어 타이밍이 높고 결정적 요구 사항이 있는 시나리오에 적합합니다.

그러나 빈번한 반복이 필요하거나 시각적 인식을 처리하고 다양한 서보 모터를 제어하며 창고 일정을 통합해야 하는 유연한 조립 라인과 같이 부품이 크게 다른 대규모 자동화 플랫폼을 구축하는 경우 마이크로서비스의 유연성 이점이 드러날 것입니다. 모터 드라이브에 영향을 주지 않고 비전만 업그레이드할 수 있습니다. 신속하게 서비스를 교체하고 새로운 기술을 시험해 볼 수 있습니다.

실용적인 문제에 직면했을 때 어떻게 시작합니까?

일반적인 딜레마에 직면했다고 가정해 보겠습니다. 기존 서보 제어 시스템이 비대해지고 각 디버깅에 오랜 시간이 걸립니다. 리팩터링을 원하지만 기존 프로덕션에 영향을 미칠까 두렵습니다.

첫 번째 단계는 서둘러 모든 것을 전복시키는 것이 아닙니다. 상대적으로 독립적인 기능 모듈로 시작하여 이를 독립적인 서비스로 분할해 보세요. 예를 들어 먼저 상태 모니터링 부분을 분리하고 표준 인터페이스를 통해 메인 시스템과 통신하도록 합니다. 작업을 관찰하십시오. 지연이 허용됩니까? 결함이 격리되었습니까?

두 번째 단계는 명확한 의사소통 기준을 확립하는 것입니다. 서비스가 서로 "대화"하는 방법이 중요합니다. 경량 메시지 대기열을 사용해야 할까요, 아니면 직접 API 호출을 사용해야 할까요? 프로토콜을 잘 정의하면 나중에 많은 혼란을 피할 수 있습니다.

세 번째 단계는 배포 및 모니터링을 고려하는 것입니다. 서비스가 많아지면 관리 복잡성도 자연스럽게 증가합니다. 특히 안정성이 매우 중요한 산업 환경에서는 각 서비스의 상태를 추적할 수 있는 방법이 필요합니다.

이러한 아키텍처적 사고가 기계 및 서보 세계와 특히 관련이 있는 이유는 무엇입니까?

하드웨어와 소프트웨어가 점점 더 깊이 통합되고 있기 때문입니다. 오늘날의 서보 모터는 간단한 회전 명령을 실행할 뿐만 아니라 토크 데이터, 온도 정보를 피드백하고 심지어 수명을 실시간으로 예측할 수도 있습니다. 서보는 단지 PWM 신호를 받아들이는 것이 아니라 로컬 경로 계획 기능도 가질 수 있습니다. 각 하드웨어 장치가 더욱 "지능화"되면 그 뒤에 있는 소프트웨어 아키텍처가 이러한 분산 지능을 지원할 수 있습니다.

좋은 아키텍처는 하드웨어의 잠재력을 실제로 발휘할 수 있습니다. 이는 시스템을 단단한 부분의 집합이라기보다는 유기체에 더 가깝게 만듭니다.

이에 대해 말하면 다음과 같이 생각할 수 있습니다. 실제로 이러한 개념을 실천하는 사람이 있습니까?

서보 및 기계제어 분야에서는kpower많은 솔루션이 실제로 이러한 종류의 아키텍처적 사고를 반영합니다. 그들은 시스템을 단일체로 간주하지 않고 모듈의 자율성과 협업을 강조합니다. 예를 들어 일부 다축 동기화 애플리케이션에서는 각 드라이브 장치가 로컬 폐쇄 루프 제어를 독립적으로 처리하고 고속 버스를 통해 전체 조정에 참여하는 것을 볼 수 있습니다. 그 이면에는 독립성과 성실성의 균형을 이루는 서비스 지향적 사고가 구현되어 있습니다.

물론 구현에 있어서는kpower귀하의 애플리케이션 시나리오에 따라 보다 적합한 경로를 추천해 드립니다. 고도로 통합된 통합 솔루션을 구축해야 할까요, 아니면 좀 더 느슨하게 결합된 마이크로서비스 클러스터를 구축해야 할까요? 절대적인 좋음이나 나쁨은 없으며 일치 여부만 있을 뿐입니다.

생각해 볼 만한 몇 가지 작은 질문

• 시스템의 어느 부분이 가장 자주 변경됩니까? 먼저 서비스로 전환할 수 있나요?
• 특정 기능에 문제가 발생하는 경우 현재 문제 해결 범위는 얼마나 광범위합니까? 줄일 수 있나요?
• 향후에 새로운 센서나 액추에이터를 추가하려는 경우 이를 시스템에 통합하는 것이 얼마나 어려울까요?

아키텍처 변경은 하루아침에 이루어지지 않습니다. 이는 지속적인 마음의 습관에 가깝습니다. 주기적으로 시스템을 살펴보고 스스로에게 물어보세요. 이러한 구성 요소 간의 경계가 명확한가요? 커플링이 너무 빡빡한가요? 독립적인 배포 및 업그레이드가 가능합니까?

목표는 유행어를 쫓는 것이 아니라 향후 변화에 더욱 강력하고 유연하며 탄력적인 시스템을 구축하는 것임을 기억하세요. 결국, 기계와 자동화의 세계에서 유일한 상수는 변화 그 자체일 수 있습니다.

이러한 흩어진 생각들이 여러분에게 조금 다른 관점을 가져다 줄 수 있기를 바랍니다. 다음 번에 수많은 서보 구성과 코드에 직면하게 되면 잠시 멈춰서 아키텍처 관점에서 생각해 볼 수 있습니다. 어떻게 하면 더 잘 "잘 지낼" 수 있을까요?

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