서버 시스템이 "이상해지기" 시작할 때: 마이크로서비스 REST API에 대한 이야기

이런 상황을 겪어본 적이 있나요? 작업장에 있던 세 살짜리 로봇 팔이 어느 날 아침 갑자기 느려졌습니다. 그것은 여전히 ​​움직이고 있었지만, 그 반응은 마치 아직 깨어나지 않은 것처럼 항상 반박자 느렸습니다. 여러 서보 간의 조정도 약간 잘못 정렬된 것처럼 보이기 시작했습니다. 전체적인 동작에는 영향을 미치지 않았지만, 가공된 부분의 정확도가 조금 떨어져 있었습니다.

문제는 하드웨어 자체에 있지 않은 경우가 많습니다.

우리는 모터, 센서, 변속기 구조를 확인하는 데 많은 시간을 보냈습니다. 모든 것이 정상이었습니다. 그러나 문제는 남아 있습니다. 나중에 이면의 제어 소프트웨어의 내부 통신이 지연되기 시작했다는 사실이 발견되었습니다. 다양한 기능 모듈 간의 데이터 교환은 눈에 보이지 않는 곳에 막힌 오래된 교통 허브와 같습니다.

사실 이는 매우 전형적인 현상이다. 많은 기계 및 자동화 시스템은 처음에는 잘 작동하지만 기능이 증가하고 데이터 양이 증가함에 따라 내부 정보 전송의 효율성은 조용히 감소합니다. 특히 시스템이 다축 협업, 실시간 피드백 및 동적 조정을 처리해야 하는 경우 기존의 모놀리식 아키텍처 소프트웨어는 병목 현상이 발생하는 경우가 많습니다.

이때는 생각을 바꿔서 문제를 살펴봐야 할 수도 있습니다.

마이크로서비스 및 REST API: 대규모 시스템을 작고 유연한 팀으로 분할

작업장의 모든 기계 장치가 암묵적인 이해를 갖고 있는 소규모 독립 팀과 같다고 상상해 보십시오. 잡는 역할을 맡은 사람은 잡는 것에만 집중하고, 회전하는 역할을 맡은 사람은 회전에만 집중하고, 위치 지정을 담당하는 사람은 위치 지정에만 집중합니다. 그들은 각각 자신만의 "브레인"(서비스)을 가지고 있지만 간단한 표준 언어(REST API)를 사용하여 언제든지 서로 통신합니다.

그렇게 하면 가장 직접적인 이점은 유연성입니다. 특정 장치를 업그레이드하거나 유지 관리해야 하는 경우 다른 장치의 정상적인 작동에는 영향을 미치지 않습니다. 마치 밴드에서 뮤지션을 바꿔도 음악은 계속될 수 있는 것과 같습니다. 시스템의 유지보수성이 크게 향상되었습니다.

명확성입니다. 각 서비스에는 명확한 책임 경계가 있습니다. 뭔가 잘못되면 누구에게 가야 할지 알 수 있습니다. 디버깅할 때 더 집중할 수 있고 몸 전체가 어떤 것에도 영향을 받지 않게 됩니다.

셋째, 확장성이 있다. 어느 날 시각적 검사 모듈을 추가하거나 새 데이터 대시보드를 연결해야 하는 경우 이는 기존 팀에 새 역할을 추가하는 것과 같습니다. 동일한 통신 언어(API)를 사용하여 연결하기만 하면 되며 뒤집어서 다시 시작할 필요가 없습니다.

하지만 '해체'가 목표가 아니라 '더 나은 협력'이 목표다.

많은 사람들이 "마이크로서비스"라는 말을 들으면 소프트웨어가 망가질수록 더 좋다고 생각합니다. 설마. 분할의 기초는 비즈니스 기능의 자연스러운 경계여야 합니다. 기계 제어 시스템의 경우 "모션 제어", "상태 모니터링", "프로세스 로직" 및 "데이터 지속성"의 핵심 영역일 수 있습니다.

분할 후에는 효율적이고 안정적으로 통신할 수 있는 방법이 핵심입니다. 이것이 REST API가 해결하도록 설계된 문제입니다.

좋은 API 디자인은 팀을 위한 효율적인 통신 프로토콜을 개발하는 것과 비슷합니다. 그것은 다음과 같아야 합니다:

• 직관적이고 이해하기 쉽다: 인터페이스 주소와 메소드를 보면 어떤 일을 하는지 짐작할 수 있습니다. 예를 들어/api/모터/상태모터 상태를 얻는 데 사용됩니다.POST /api/작업새 작업을 발행하는 데 사용됩니다.
• 안정적이고 일관성 있음: 오늘도 내일도 마찬가지입니다. 반환된 데이터의 형식과 오류 코드의 의미는 통일된 상태로 유지되므로 호출자가 안심할 수 있습니다.
• 필요한 정보만 전달: 더도 말고 덜도 말고 딱 필요한 만큼만 협업에 필요한 수준입니다. 네트워크 부담과 구문 분석 비용을 증가시키는 서비스 간 대량의 중복 데이터 이동을 피하세요.
• 우수한 "내결함성"을 갖습니다.: 간헐적으로 네트워크 연결이 끊어지고 특정 서비스가 일시적으로 응답하지 않는 경우가 있습니다. 좋은 API 디자인은 시스템이 직접 충돌하는 대신 우아하게 성능을 저하하거나 빠르게 복구하는 데 도움이 될 수 있습니다.

개념부터 실천까지: 피할 수 없는 구체적인 생각들

실제로 그러한 시스템을 구축할 때 우리는 무엇에 중점을 둘 것인가?

첫째, 서비스의 세분화입니다. 각 모터의 제어를 독립적인 서비스로 만들어야 할까요, 아니면 전체 축의 모션 제어를 서비스로 사용해야 할까요? 이를 위해서는 절충이 필요합니다. 너무 자세하면 관리가 복잡해집니다. 너무 거칠면 마이크로서비스의 장점이 사라집니다. 우리의 경험은 핵심 비즈니스 역량에서 시작하여 상대적으로 독립적이고 자율적인 기능 단위를 찾는 것입니다.

둘째, 의사소통의 신뢰성이다. 산업 환경에서 네트워크는 항상 완벽하지는 않습니다. API 호출이 실패할 수 있습니다. 따라서 재시도 메커니즘을 설계하는 것 외에도 때로는 중요한 명령이 손실되는 것을 방지하기 위해 비동기 메시지 큐를 도입해야 하는 경우도 있습니다. 명령을 제어하려면 "최소 한 번 전달"을 보장하는 것이 중요합니다.

셋째, 모니터링과 통찰력입니다. 시스템이 분해되면 전체 시스템이 건강한지 어떻게 알 수 있습니까? 통합된 로깅, 모니터링 및 링크 추적 메커니즘이 필요합니다. 특정 공작물 처리 시간이 초과되면 모든 하드웨어를 맹목적으로 확인하는 대신 어떤 서비스(예: 경로 계획 서비스)가 느리게 응답하는지 빠르게 추적할 수 있습니다.

넷째, 국경을 확보하라. 각 서비스에는 고유한 입구와 세부적인 보안 정책이 있습니다. 모션 제어 인터페이스에 접근할 수 있는 사람은 누구입니까? 누가 상태를 읽을 수만 있나요? 역할 기반 API 권한 관리는 산업 시스템에서 선택이 아닌 필수입니다.

이는 단순한 소프트웨어 아키텍처의 변화가 아닙니다.

더 깊이 살펴보면 마이크로서비스와 명확한 REST API를 채택하면 실제로 시스템이 발전하는 방식이 바뀌고 있습니다. 자동화 시스템을 비즈니스 요구에 따라 결합, 교체, 업그레이드할 수 있는 레고 ​​벽돌처럼 만들어줍니다. 오늘날 정밀 가공에 집중할 수 있으므로 모션 제어 서비스가 핵심입니다. 내일은 빅 데이터 예측 유지 관리를 추가해야 할 수도 있습니다. 그런 다음 데이터 수집 및 분석 서비스만 향상하면 되며 원래 제어 흐름을 크게 변경할 필요가 없습니다.

이러한 종류의 유연성은 장기적인 운영과 새로운 프로세스 및 신제품에 대한 지속적인 적응이 필요한 제조 환경에 숨겨진 엄청난 가치를 가지고 있습니다. 기술적 부채와 향후 변경에 대한 위험을 줄여줍니다.

존재하다kpower, 우리는 서보 모터, 스티어링 기어 및 다양한 기계 시스템의 통합 응용 분야에 깊이 관여하고 있습니다. 소프트웨어 아키텍처 제한으로 인해 후기 단계에서 병목 현상이 발생하는 경우가 너무 많습니다. 우리는 기계 시스템의 물리적 특성과 제어 논리를 정확하게 이해하고 있기 때문에 소프트웨어 수준에서 "강력하고 유연한" 통신 골격을 구축하는 데 더 많은 관심을 기울이고 있습니다.

좋은 기술은 사람들이 그것이 복잡하다고 느끼게 해서는 안 됩니다. 우수한 마이크로서비스 REST API 세트와 마찬가지로 궁극적으로 사용자에게 제공되는 것은 더 부드러운 제어 경험, 더 안정적인 생산 리듬, 더 여유로운 확장 기능입니다. 작업장의 장비가 "암묵적인 이해"를 갖고 있는 것처럼 보이면 자연스럽게 문제가 줄어들 것입니다.

모든 것은 "대화"하는 방법에 대한 명확한 설계로 시작됩니다.

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