서버 시스템이 마이크로서비스를 만났을 때: 그것들을 분할하세요

거대한 기계 시스템에 직면했다고 상상해 보십시오. 모든 모터, 센서, 제어 모듈은 서로 긴밀하게 결합되어 몸 전체에 영향을 미칩니다. 특정 서보의 매개변수를 조정하고 싶으십니까? 전체 제어 프로그램을 재구성해야 할 수도 있습니다. 시계의 기어 하나만 교체하려고 하다가 시계 전체를 분해해야 하는 것과 약간 비슷하지 않나요?

전통적인 아키텍처의 메카트로닉스 프로젝트는 종종 이러한 딜레마에 직면합니다.

위치 피드백을 담당하는 엔코더 모듈, 토크 출력을 관리하는 드라이브 유닛, 모션 궤적 등 시스템의 각 부분을 독립적으로 연습하고 완벽하게 협력할 수 있는 잘 훈련된 밴드처럼 만들 수 있는 방법이 있습니까?

오늘 우리가 이야기할 내용은 바로 하드웨어와 소프트웨어의 교차점에 있는 마이크로서비스 아키텍처의 핵심 구성 요소입니다.

그것은 마술이 아니라 방법입니다. 마이크로서비스에는 정확히 무엇이 있습니까?

많은 사람들이 "마이크로서비스"를 들으면 순수 소프트웨어 분야의 개념이라고 생각합니다. 설마. 이를 서보 모터, 로봇 팔 또는 자동화된 생산 라인의 제어 시나리오에 매핑하면 매우 구체적이 됩니다. 분해해서 살펴보도록 하겠습니다.

첫 번째 핵심: 독립적으로 배포된 사업부.

마이크로서비스의 세계에서는 각 핵심 기능이 독립적인 "서비스"가 됩니다. 예를 들어, "위치 폐쇄 루프 제어"를 특별히 처리하는 서비스와 "온도 모니터링 및 보호"를 특별히 처리하는 서비스는 별개입니다. 이들은 각각 독립적인 프로세스를 갖고 있으며 다양한 프로그래밍 언어나 프레임워크로 작성될 수 있습니다. 그게 무슨 뜻이야? 온도 보호가 필요한 경우 대규모 제어 시스템 전체를 방해하지 않고 소규모 서비스만 업데이트하면 됩니다. 시스템은 다운되지 않으며 다른 모든 작업은 정상적으로 진행됩니다.

마치 복잡한 공작기계와 같습니다. 스핀들 드라이브, 공급 시스템 및 냉각 장치에는 각각 독립적인 제어 캐비닛이 있지만 표준 인터페이스를 통해 통신합니다. 한 장치가 유지 관리되는 동안 다른 부분은 계속 작동할 수 있습니다.

두 번째 핵심: 경량 통신 메커니즘.

서비스는 어떻게 서로 "대화"합니까? 일반적으로 잘 정의된 경량 API(응용 프로그래밍 인터페이스), 종종 HTTP/REST 또는 유사한 메시지 대기열을 통해 통신합니다. 전기기계적 측면에서 이는 표준화된 대기 시간이 짧은 통신 프로토콜로 이해될 수 있습니다. 각 서비스는 필요한 "대화 상자 창"만 노출하고 내부 구현은 숨겨집니다. 안전하고 명확합니다.

세 번째 핵심: 분산형 데이터 관리.

각 마이크로서비스는 일반적으로 자체 전용 데이터베이스 또는 데이터 저장소를 관리합니다. 동작 계획 서비스에는 자체 궤적 데이터베이스가 있고 결함 진단 서비스에는 자체 로그 라이브러리가 있습니다. 이렇게 하면 모든 데이터를 하나의 거대한 데이터베이스에 집어넣는 데 따른 혼잡함과 복잡성을 피할 수 있습니다. 데이터 소유권은 누구에게 빼앗겼는지 명확합니다.

네 번째 핵심: 자동화와 탄력성.

여러 개의 소규모 서비스를 관리하는 방법은 무엇입니까? 이를 위해서는 컨테이너화 기술(예: Docker) 및 조정 도구(예: Kubernetes)의 도움이 필요합니다. 이러한 서비스의 배포, 확장 및 관리를 자동화합니다. 연중무휴 24시간 실행해야 하는 생산 라인의 경우 서비스 인스턴스가 실패하면 오케스트레이션 시스템이 자동으로 서비스 인스턴스를 다시 시작하거나 트래픽을 정상 인스턴스로 전환하여 시스템 복원력을 크게 향상시킬 수 있습니다.

다섯 번째 핵심: 독립적인 진화 능력.

이것이 마이크로서비스의 가장 큰 매력 중 하나입니다. 팀은 자신이 담당하는 서비스를 독립적으로 개발하고 출시할 수 있으며 반복 속도가 매우 빠릅니다. 귀하의 서보 드라이브에 새로운 필터를 사용해보고 싶으십니까? 다른 기능 모듈에 영향을 주지 않고 독립적인 제어 서비스에서 테스트하고 배포하기만 하면 됩니다.

긴밀한 결합에서 자유로운 협업으로: 전환은 어떻게 이루어지나요?

이것을 보면서 여러분은 "이거 좋은 것 같은데, 우리의 특정 프로젝트에 어떻게 도움이 될까?"라고 생각할 수도 있습니다.

예를 들어보세요. 과거에는 여러 개의 서보 축과 로봇이 있는 전체 조립 라인을 제어하기 위해 거대한 PLC 프로그램을 사용했을 수도 있습니다. 워크스테이션의 작업 논리를 수정하려면 전체 프로그램에 대한 회귀 테스트가 필요할 수 있으며 이는 위험도가 높고 시간이 많이 소요됩니다.

마이크로서비스 아키텍처를 채택한 후에는 "시각적 위치 확인 서비스", "그리퍼 제어 서비스" 및 "조임축 토크 관리 서비스"를 독립적으로 분리할 수 있습니다. 시각적 위치가 업그레이드되었나요? 해당 서비스만 배포하세요. 그리퍼 모델이 변경되었습니다. 제어 로직을 조정해야 합니까? 해당 서비스만 터치하세요. 그들은 명확한 인터페이스 계약을 통해 협력합니다. 예를 들어 비전 서비스 측위가 완료된 후 그리퍼 제어 서비스에 좌표 메시지를 보내면 됩니다.

이렇게 분할하면 복잡성이 줄어들고 기술 선택이 더욱 유연해집니다. 특정 서비스는 매우 높은 컴퓨팅 속도를 요구하며 C++로 작성될 수 있습니다. 다른 서비스는 상위 계층 MES 시스템에 빠르게 연결해야 하며 Go 또는 Python으로 작성할 수 있습니다. 서로에게는 문제가 되지 않습니다.

선택 및 구현: 하루아침에 달성되지 않음

물론 마이크로서비스가 만능은 아닙니다. 이는 서비스 간 네트워크 통신의 대기 시간과 분산 시스템의 데이터 일관성과 같은 새로운 문제를 야기합니다. 매우 높은 실시간 요구 사항(아마도 마이크로초 수준)이 있는 서보 폐쇄 루프 제어의 경우 신중한 설계가 필요합니다. 핵심 실시간 제어 루프는 하나 이상의 소형 모듈에 유지될 수 있으며 모니터링, 관리, 로깅과 같은 비실시간 기능은 마이크로서비스될 수 있습니다.

이를 위해서는 숙련된 기계 설계자와 같은 기술 의사 결정자가 견고한 연결이 필요한 위치와 유연한 조인트를 대신 사용할 수 있는 위치를 알아야 합니다.

존재하다kpower우리가 참여하고 지원한 많은 메카트로닉스 및 자동화 프로젝트에서 이러한 아키텍처적 사고가 엔지니어가 보다 유연하고 강력하며 진화하기 쉬운 시스템을 구축하는 데 도움이 된다는 것을 확인했습니다. 전복하고 다시 시작하는 것이 아니라, 쪼개지고 재편하는 단계별 예술이다.

궁극적으로 모든 기술 아키텍처는 동일한 목표를 달성합니다. 즉, 시스템을 보다 안정적으로 만들고, 개발을 보다 효율적으로 만들고, 변경을 더 쉽게 만듭니다. 다음에 복잡한 제어 시스템에 직면하게 되면 어떤 부분이 독립적으로 호흡하고 자유롭게 성장할 수 있는 "마이크로서비스"가 될 수 있는지 생각해 볼 수 있을 것입니다. 프로세스 자체는 흥미로운 엔지니어링 퍼즐을 푸는 것과 같습니다.

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