제품이 전선이 엉켜있는 것 같은 경우

이 시나리오를 상상해보세요. 훌륭한 기능과 훌륭한 아이디어로 멋진 제품을 디자인하셨습니다. 처음에는 모든 것이 명확하고 뚜렷합니다. 하나의 단위가 함께 작동하는 것입니다. 그러나 점차 수요가 증가하고 기능이 반복되면서 이 단일 전체가 비대해지기 시작했습니다. 작은 기능을 변경하면 전체 시스템을 다시 테스트해야 합니다. 하나의 모듈에 문제가 있으면 전체 서비스가 다운될 수 있습니다. 작업대 아래 정리하는 것을 잊어버린 데이터 케이블과 전원 케이블 더미처럼 됩니다. 서로 엉켜 있어서 하나를 잡아당기면 다 엉망이 됩니다.

익숙한 느낌이 드나요? 경직되고 취약하며 확장할 수 없는 딜레마입니다. 서보 모터 및 정밀 기계 분야에서 우리는 모듈성의 중요성을 이해하고 있습니다. 복잡한 로봇 팔은 하나의 보드에 모든 컨트롤을 통합하지 않습니다. 조향 기어의 정확한 피드백도 주 제어 시스템과 무관합니다. 소프트웨어 구축의 이러한 "분할 및 정복" 철학이 마이크로서비스 아키텍처입니다.

그런데 문제가 있습니다. “마이크로서비스를 사용해야 한다”는 것과 “마이크로서비스를 잘 사용하는 방법”을 아는 것은 서로 다른 문제입니다. 이러한 독립적인 서비스를 설계하는 방법은 무엇입니까? 그들은 어떻게 우아하게 의사소통을 할까요? 데이터를 어떻게 관리하나요? 이것은 큰 바위를 자갈로 부수는 것만큼 간단하지 않습니다.

우리는 어떻게 "모델링"합니까?

모델링은 매우 공학적인 단어처럼 들립니다. 사실 그다지 신비롭진 않습니다. 빽빽한 회로도라기보다는 도시 청사진을 그리는 것과 비슷합니다. 고려해야 할 사항은 다음과 같습니다. 이 "도시"에는 어떤 기능 블록(서비스)이 있습니까? 그들 사이의 도로(통신)를 어떻게 계획할 것인가? 물과 전원 공급 장치(데이터 흐름)는 어떻게 배열되어 있나요?

기술적인 수준이 아닌 비즈니스 기능부터 시작해야 합니다. 스스로에게 물어보세요: 내 제품의 어떤 기능 단위가 독립적으로 작동하고 명확한 가치를 가질 수 있습니까? 예를 들어 사용자 등록 및 로그인 모듈, 주문 처리 프로세스, 실시간 데이터 대시보드 등이 있습니다. 각각은 자체 논리와 데이터를 갖춘 독립적인 "미니 제품"이어야 합니다.

다음으로, 그들이 어떻게 의사소통하는지 생각해 보세요. 서보가 PWM 신호를 수신하고 위치 피드백을 반환하는 것처럼 서비스 간에도 명확하고 안정적인 인터페이스 프로토콜이 필요합니다. 경량 HTTP API를 사용해야 할까요, 아니면 더 효율적인 RPC를 사용해야 할까요? 서로 이해할 수 있고 모호함이 없도록 요청과 응답의 "언어"를 정의합니다.

“하지만 좀 더 복잡하지 않을까요?” 누군가는 물어볼 수도 있습니다.

물론 언번들링의 초기 작업은 반성을 불러일으킬 것입니다. 하지만 이점을 생각해 보십시오. 주문 시스템을 업그레이드해야 할 때 로그인 서비스는 전혀 영향을 받지 않고 평소대로 실행됩니다. 로봇 팔의 관절에 가장 적합한 서보 모터를 선택하는 것처럼 가장 적절한 언어로 특정 서비스를 프로그래밍할 수 있습니다. 확장도 쉬워집니다. 어떤 서비스가 압박을 받든 전체 애플리케이션을 복제하는 대신 별도로 리소스를 추가하기만 하면 됩니다.

kpower관점: 정밀 기계 조립과 같은 소프트웨어 구축

우리 안에kpower, 서보 모터와 스티어링 기어를 다루는 것이 일상입니다. 우리가 보는 것은 블랙박스가 아니라 모터, 컨트롤러, 센서, 감속기의 정밀한 협업이다. 각 구성 요소는 전문적이고 독립적이며 표준 인터페이스를 통해 완벽하게 연결되어 있습니다. 이런 종류의 사고는 우리가 소프트웨어 아키텍처에 대해 생각하는 방식에 깊은 영향을 미칩니다.

좋은 마이크로서비스는 잘 설계된 모듈식 기계 시스템과 같아야 합니다. 각 서비스(구성 요소)에는 단일 책임이 있으며 강력하고 안정적입니다. 인터페이스(커넥터)가 표준적이고 견고하며 통신이 원활합니다. 내결함성 메커니즘(중복 설계)은 로컬 오류가 전체에 영향을 미치지 않도록 보장합니다. 모니터링 시스템(센서 네트워크)은 각 구성 요소의 상태에 대한 개요를 제공합니다.

우리는 이론적으로 이야기하는 것을 좋아하지 않습니다. 따라서 실제로 마이크로서비스를 구축할 때 우리는 몇 가지 매우 실용적인 사항에 주의를 기울입니다.

• 경계가 명확합니까?데이터베이스가 여전히 서비스 간에 비밀리에 공유되어 혼란스럽고 혼란스럽습니까?
• 의사소통이 탄탄한가요?네트워크가 가끔 흔들리면 서비스가 "손실"되나요?
• 독립 실행형 배포가 실제로 가능합니까?즉, 서비스를 출시하려면 한밤중에 다른 팀의 파트너를 깨워야 하는 걸까요?

이러한 세부 사항은 아름다운 아키텍처 다이어그램에 살고 있는지 아니면 현실 세계에서 원활하게 실행되는지를 결정합니다.

도면에서 현실로: 몇 단계

모든 상황에 맞는 일률적인 단계는 없지만 몇 가지 생각은 일반적입니다.

1. 핵심가치부터 시작하세요.처음부터 찢으려고 하지 마세요. 제품에서 가장 핵심적이고 가장 자주 변경되거나 가장 높은 성능 요구 사항을 갖는 기능 한두 개를 찾아서 분리해 보십시오. 이는 기계 시스템의 핵심 전력 및 전송 모듈을 먼저 식별하는 것과 같습니다.
2. 구현에 집중하기보다는 "계약"을 정의하십시오.먼저 서비스 간 API 인터페이스 프로토콜을 명확하게 정의하고 문서화하는 데 시간을 투자하세요. 이는 기계적 인터페이스의 치수와 공차를 정의하는 것과 동일하며, 후속 내부 구현(어떤 모터를 사용할지, 어떤 알고리즘을 사용할지)을 유연하게 배열할 수 있습니다.
3. 불완전함을 허용하고 진화를 포용하십시오.첫 번째 모델은 거의 완벽하지 않습니다. 특정 서비스가 나중에 너무 비대해져서 해체되어야 할 수도 있습니다. 그것은 중요하지 않습니다. 핵심은 마이크로서비스 아키텍처가 바퀴를 다시 만들 필요 없이 지속적으로 발전하고 재구성할 수 있는 능력을 제공한다는 것입니다. 팔 몸체 전체를 교체하지 않고도 더 빠른 서보로 로봇 팔을 업그레이드할 수 있는 것과 같습니다.

결국 이 모든 노력은 무엇을 위한 것인가? 제품을 만들고 운영하는 사람들이 더 이상 그 '엉킨 선'에 갇히지 않기 위해서입니다. 새로운 아이디어가 생겼을 때 기존 '기능 블록'을 빠르게 결합해 빌딩 블록처럼 혁신할 수 있도록 하기 위함이다. 시스템이 다음과 같이 작동하도록 만드는 것입니다.kpower정밀 부품으로 구동되는 기계처럼 반응이 빠르고 안정적으로 작동하며 자유롭게 확장됩니다.

그것은 단지 기술적인 선택이 아니라, 복잡하고 아름다운 것을 만드는 것에 대한 생각의 방식입니다. 각 부분이 적절하게 독립적이고 암묵적으로 시너지를 발휘할 때 전체 시스템은 단순한 중첩을 넘어 활력을 발산하게 됩니다.

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