서버 시스템이 "말하기" 시작할 때: 웹 서비스, 마이크로서비스 및 API는 무엇에 대해 논쟁하고 있습니까?
작업장에서 가장 안정적인 서보가 갑자기 말하기 시작한다고 상상해 보십시오. 결함 보고가 아니라 불만 사항입니다. "옆집 컨베이어 벨트는 항상 잘못된 명령 형식을 보내고 여기 기어는 거의 회전하고 있습니다." 이 장면은 약간 공상과학 같죠? 그러나 다른 관점에서 생각해 보면 기계 시스템의 다양한 구성 요소는 실제로 매일 자신의 언어로 "통신"하지만 단어가 아닌 데이터 패킷, 신호 및 프로토콜을 사용합니다.
이것이 일부 사람들이 궁금해하기 시작한 이유입니다. 기계가 더 원활하게 "대화"할 수 있다면 더 아름다운 작업을 수행할 수 있을까요?
1. 질문이 생깁니다. 기계에 "서비스"가 필요한 이유는 무엇입니까?
자동화 작업을 할 때 캐비닛은 PLC로 가득 차 있었고 배선은 마치 거미줄 같았습니다. 기능은 구현되었지만 매개변수를 변경하거나 로봇팔이 더 많은 작업을 하게 하려면 프로그램을 다시 배선하고 다시 작성해야 하므로 시간이 오래 걸립니다. 이는 마치 집에 있던 오래된 라디오와 같습니다. 채널을 변경하려면 손을 뻗어 손잡이를 돌려야 합니다.
지금은 다릅니다. 장비는 점점 더 스마트해지고 있으며 프로젝트에서는 서보 모터, 스티어링 기어, 공압 구성 요소 및 여러 센서를 동시에 사용할 수 있습니다. 그들은 어떻게 서로 "대화"합니까? 데이터는 어떻게 흐르나요? 누가 명령을 듣나요? 이때 '서비스'라는 개념이 끼어들었다.
하지만 잠깐만요. 시장에서 자주 듣는 단어는 웹 서비스, 마이크로서비스, API입니다. 세 형제처럼 들리고, 조금 비슷해 보이지만 전혀 기질이 다릅니다.
- 웹 서비스꾸준한 집사처럼. SOAP나 REST와 같은 일련의 표준 "에티켓"을 사용하여 네트워크에서 정보를 주고받으므로 서로 다른 시스템이 하나는 Java로 작성되고 다른 하나는 C++로 작성되어도 서로를 이해할 수 있습니다. 그것은 일을 공식화하고 표준화하는 것을 좋아합니다.
- 마이크로서비스유연한 특수부대 집단 같아요. 이는 대규모 소프트웨어 애플리케이션을 여러 개의 독립적인 소규모 서비스로 나누고 각 소규모 서비스는 한 가지 작업(예: 구체적으로 위치 확인 처리 또는 구체적으로 모터 상태 관리)에만 중점을 둡니다. 그들은 가벼운 방식으로 서로 통신합니다. 업그레이드가 필요하거나 문제가 있는 항목은 다른 "팀 구성원"에게 영향을 미치지 않습니다.
- 그리고 API(응용 프로그래밍 인터페이스)는 가장 간단한 "대화 목록"입니다. 이는 다음과 같이 정의됩니다. "나(일부 소프트웨어 또는 하드웨어)가 무언가를 하도록 하려면 다음 형식으로 이 키워드를 사용하여 나에게 전화해야 합니다." 해당 기능에 접근하기 위한 열쇠 구멍입니다.
"어느 것이 필요한가요? 아니면 모두 필요한가요?"라고 물을 수도 있습니다.
걱정하지 마십시오. 도구 상자에 도구를 선택하는 것과 같습니다. 당신은 어느 것이 "최고"인지 선택하는 것이 아니라, 당신이 구성하는 기계적 퍼즐에 대해 "최고"인 것을 선택하는 것입니다.
2. 올바른 "서비스"가 올바른 일을 하게 하세요
비유를 사용하려면. 코어를 사용하여 자동 분류 장치를 설계합니다.kpower고정밀 서보 모터가 로봇 팔을 구동합니다.
- 이 분류 장치의 상태를 원격 사무실의 대형 컴퓨터 화면에 실시간으로 표시해야 하거나 회사의 중앙 주문 시스템에서 작업을 받기 위해 필요한 경우웹 서비스그러한 표준, 크로스 플랫폼 통신 방법은 매우 유용합니다. 이는 작업장에서 사무실까지 안정적인 "데이터 고속도로"를 구축하는 데 도움이 됩니다.
- 로봇 팔 제어, 시각적 인식, 경로 계획, 오류 로그가 서로 독립적이고 빈번한 조정이나 별도의 업그레이드가 필요한 전체 분류 시스템이 특히 복잡하다면 다음을 사용하십시오.마이크로서비스소프트웨어 부품을 구축하는 아키텍처는 나중에 유지 관리 및 확장을 훨씬 쉽게 만듭니다. 특정 기능을 개선해야 한다면 전체에 영향을 줄 수는 없습니다.
- 그리고API, 거의 모든 곳에서. 서보 드라이브가 상위 제어 프로그램에 빠르게 접근할 수 있도록 하는 "단축 명령"입니다. 예를 들어kpower일부 드라이버 제품은 명확하고 안정적인 API를 제공하므로 기본 복잡한 레지스터 주소를 조사할 필요 없이 고급 언어(예: Python)를 사용하여 정확한 이동 명령을 직접 보낼 수 있습니다. 통합이 마치 빌딩 블록처럼 느껴집니다.
보시다시피, 그들은 서로를 대체하는 것이 아니라 종종 함께 작동합니다. 웹 서비스 또는 마이크로서비스 간에 서로 호출하는 것은 종종 명시적 API를 통해 수행됩니다.
3. 기계 프로젝트에서 "좋은 대화"가 왜 그렇게 중요한가요?
올바른 "서비스" 아키텍처를 선택하면 다음과 같은 실질적인 이점을 얻을 수 있습니다.
- 유연성 향상. 오늘은 로봇 팔에 힘 감지 피드백을 추가하고 내일은 전체 스테이션을 공장 사물 인터넷에 연결하고 싶습니다. 모듈식 서비스 아키텍처를 사용하면 바퀴를 다시 만드는 대신 플러그인과 같은 기능을 추가할 수 있습니다.
- 유지 관리가 쉽습니다.. 어떤 모듈에 문제가 있는지, 문제 해결 및 수리 범위가 더 집중됩니다. 한 서비스가 업데이트되면 다른 서비스도 평소대로 실행되므로 시스템 가동 중지 위험이 크게 줄어듭니다.
- 반복이 더 빠릅니다.. 여러 팀에서 서로 다른 마이크로서비스를 병렬로 개발하고 최종적으로 테스트를 위해 결합하도록 할 수 있습니다. 제품 기능의 진화 속도는 자연스럽게 따라잡을 것입니다.
- 통합이 더 원활해졌습니다.. 표준 API와 통신 방식을 통해kpower고급 서보 시스템, 타사 비전 센서 및 자체 제어 소프트웨어를 결합하면 기술 임계값과 디버깅 시간이 단축됩니다.
이것은 단지 소프트웨어 수준의 문제가 아닙니다. 이는 하드웨어 장치의 잠재력에 직접적인 영향을 미치며 완전히 활용할 수 없습니다. 밀리초 단위의 응답 속도를 가진 서보 모터가 느리고 비대해진 중앙 시스템의 지시를 기다리다 성능을 낭비한다면 안타까운 일이다.
4. 첫 번째 단계는 어디에서 시작해야 합니까?
기계 자동화 프로젝트를 계획하거나 전환하는 경우 다음 사항에 대해 생각해 볼 수 있습니다.
- 경계를 그리다: 귀하의 시스템에서 어떤 기능이 긴밀하게 결합되어 전체적으로 작동해야 합니까? 상대적으로 독립적이며 독립적으로 개발 및 배포할 수 있는 것은 무엇입니까? 독립적인 서비스는 마이크로서비스의 후보입니다.
- 대화 정의: 이러한 독립적인 기능 간에 어떤 정보를 교환해야 합니까? 얼마나 자주? 얼마나 많은 데이터가 있나요? 이러한 "대화 내용"과 "규칙"을 명확하게 정의하는 것이 API를 설계하는 과정입니다.
- 프로토콜 선택: 원격 및 크로스 네트워크 통신이 필요한 부분에는 RESTful API와 같은 경량 프로토콜을 사용해야 할까요, 아니면 더 엄격한 트랜잭션 보장이 필요한 프로토콜을 사용해야 할까요? 이는 웹 서비스의 스타일을 결정합니다.
- 당신의 파트너를 봐: 선택한 하드웨어 공급업체에서 제공하는 지원에 주의하세요. 예를 들어 Kpower가 제품 생태계에서 어떤 편리한 통합 인터페이스와 통신 지원을 제공하는지 이해하면 절반의 노력으로 두 배의 결과를 얻을 수 있습니다.
기술은 그 자체로 목적이 아닙니다. 이는 기계를 위한 효율적이고 마찰 없는 "작업 언어"를 설계하는 것과 같습니다. 궁극적인 목표는 그들이 함께 일하여 귀하가 할당한 작업을 보다 조용하고 안정적이며 더 잘 완료하도록 하는 것입니다. 모든 기어가 돌아가고, 모든 프로그램이 실행될 때 마치 원활한 대화를 거쳐 합의에 도달하는 것과 같습니다. 그 효율성과 신뢰성은 프로젝트에서 가장 감동적인 부분입니다.
아마도 다음번에 작업장에서 장비가 정상적으로 작동하는 소리를 듣게 된다면 질서있고 효율적인 대화라고 생각하시면 될 것 같습니다. 당신이 해야 할 일은 그들을 위해 이 대화의 규칙을 디자인하는 것입니다.
2005년에 설립된 Kpower는 중국 광둥성 둥관에 본사를 둔 소형 모션 유닛 전문 제조업체입니다. Kpower는 모듈형 드라이브 기술의 혁신을 활용하여 고성능 모터, 정밀 감속기 및 다중 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다. Kpower는 스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론 및 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.
