마이크로서비스 간 통신 방식

기계 장치가 "말하기" 시작할 때: 마이크로서비스 간의 통신 기술

이것을 상상해 보십시오: 당신은 정교한 로봇 팔을 디자인하고 있습니다. 각 관절의 서보 모터는 완벽하게 반응하며 스티어링 기어의 각도 제어는 밀리미터 단위까지 정확합니다. 그러나 전체 시스템을 조정하려고 하면 팔의 움직임이 멈췄고 동기화되지 않았으며 때때로 "싸움"을 하기도 합니다. 무엇이 문제인가요? 단일 모터의 문제는 아니지만 모터 간의 "대화"가 혼란스러운 경우가 많습니다. 기계 부품이 함께 작동해야 하는 것처럼 최신 소프트웨어 아키텍처의 마이크로서비스에도 명확하고 안정적인 통신 방법이 필요합니다.

이는 단지 코드의 문제가 아니라 시스템이 어떻게 "살고" 함께 작동하는지의 문제입니다.

마이크로서비스 간의 통신이 "체인 삭제"되기 쉬운 이유는 무엇입니까?

과거에는 많은 시스템이 모든 로직이 함께 묶인 통합된 기계 어셈블리와 같았습니다. 작은 기어가 변경되면 조정을 위해 전체 기계를 정지해야 할 수도 있습니다. 마이크로서비스 아키텍처는 복잡한 기계를 표준 모터, 센서 및 컨트롤러로 모듈화하는 것과 마찬가지로 시스템을 독립적이고 작고 기능에 초점을 맞춘 여러 단위로 분할합니다. 이는 유연성과 유지 관리성을 제공하지만 새로운 과제도 제시합니다. 분산된 "소형 모듈"이 어떻게 정보를 효율적이고 정확하며 안정적으로 교환할 수 있습니까?

일반적인 상황은 다음과 같습니다.

• 정보가 지연되거나 손실됨: 한 서비스에서 명령을 보냈으나 다른 서비스에서 이를 받지 못했거나, 응답하는데 오랜 시간이 걸려 프로세스가 중단되었습니다.
• 데이터가 일관되지 않습니다.: 서비스 A는 상태를 업데이트하지만 서비스 B는 여전히 이전 데이터로 작동하며 결과가 모순됩니다.
• 커플링이 너무 빡빡함: 서비스 간 의존도가 너무 깊습니다. 그 중 하나가 잘못되면 연쇄 반응으로 시스템 전체가 무너지고 마이크로서비스의 '독립'의 의미가 상실됩니다.
• 추적이 어렵다: 문제가 발생했지만 어떤 "대화"에서 오류가 발생했는지 알 수 없습니다. 문제 해결은 미로에서 회전하는 것과 같습니다.

이는 통합 통신 프로토콜을 사용하지 않고 분산된 기계 장치 그룹에 지시를 내리는 것과 같습니다. 일부는 기어 전송 신호에 의존하고 일부는 공기압 전송을 사용하며 일부는 플래시 조명에 의존하기도 합니다. 혼란스럽지 않다면 이상할 것이다.

대화 흐름 만들기: 몇 가지 핵심 의사소통 "언어"

잘 훈련된 기계 팀처럼 이러한 마이크로서비스가 원활하게 협업하도록 만드는 방법은 무엇입니까? 핵심은 올바른 커뮤니케이션 모델을 선택하는 것입니다. 그것들은 신호를 전송하는 다른 커넥터나 방법과 같습니다.

1. 동시 통화: 직접 질문하고 답변을 기다립니다. 가장 일반적인 것은 HTTP API와 유사한 요청-응답 모드입니다. 서비스 A는 서비스 B에 직접 요청을 보내고 작업을 계속하기 전에 명확한 응답을 기다립니다. 이는 제어판의 버튼을 누르고 다음 단계로 진행하기 전에 표시등이 켜지거나 모터가 회전하여 피드백을 받을 때까지 기다리는 것과 같습니다.

• 혜택: 단순하고 직관적이며 논리가 명확합니다.
• 주의가 필요하다: 상대방의 서비스가 느리거나 끊기면 발신자도 "걸려" 체인 전체가 대기하게 되기 쉽습니다. 실시간 요구 사항이 높고 안정적인 다운스트림 서비스가 필요한 시나리오에 적합합니다.

2. 비동기 메시지: 메모를 남기고 메시지 대기열(예: RabbitMQ, Kafka 개념) 또는 이벤트 버스를 통해 개별적으로 처리합니다. 서비스 A가 무언가를 완료하면 이벤트나 메시지를 "메시지 릴레이"에 게시하고 잊어버립니다. 이벤트를 담당하는 서비스 B와 C는 스스로 이벤트를 획득하고 처리합니다. 이는 기계 장치가 작업을 완료한 후 공유 게시판에 완료 메모를 게시하는 것과 같습니다. 다른 관련 부서가 직접 보고 어떻게 할지 결정할 수 있습니다.

• 혜택: 완벽한 분리, 발신자는 수신자의 실시간 상태에 의존하지 않습니다. 이는 압력을 완화하고 갑작스러운 요청으로 인해 시스템이 압도되는 것을 방지할 수 있습니다.
• 주의가 필요하다: 아키텍처가 복잡해지고 안정적인 메시지 전달이 필요하며 이벤트 처리 순서를 고려해야 합니다.

3. 게시/구독: 알림을 방송하면 누구나 필요한 것을 얻을 수 있습니다. 이는 비동기 메시지의 일반적인 패턴입니다. 서비스는 게시자 역할을 하며 주제 채널에 이벤트를 게시합니다. 이 주제를 구독하는 모든 서비스는 사본을 받게 됩니다. 작업장의 중앙 방송 시스템에서 "파트 A가 준비되었습니다"라고 알리는 것처럼 이 정보가 필요한 모든 워크스테이션이 동시에 이를 듣고 자율적으로 응답할 수 있습니다.

어떤 "언어"를 선택할지에 대한 절대적인 답은 없습니다. 이는 시스템의 "개성"에 따라 다릅니다. 단단하고 즉각적인 적합이 필요합니까, 아니면 탄력성과 처리량을 더 중시합니까? 여러 모드가 시스템에 혼합되어 있는 경우가 많습니다.

kpower관점: 정밀 기계와 같은 디자인 커뮤니케이션

우리 안에kpower다양한 하드웨어 통합 및 모션 제어를 다룬 경험을 통해 우리는 소프트웨어 마이크로서비스 간의 통신이 물리적 기계 시스템의 조정과 놀라운 유사성을 가지고 있음을 발견했습니다. 신뢰성, 실시간, 내결함성 - 이러한 요구 사항은 일반적입니다.

이 문제를 살펴볼 때 단순히 소프트웨어 수준에서만 시작하지는 않을 것입니다. 예를 들어, 메시지가 전기 신호만큼 안정적으로 전송되도록 하려면 어떻게 해야 할까요? 일부 장치에 오류가 발생하는 경우 시스템이 기계적 이중화 설계와 같은 저하된 수준에서 계속 작동하도록 하려면 어떻게 해야 합니까? 센서를 사용하여 각 구동축의 속도와 토크를 모니터링하는 등 정보의 흐름을 모니터링하는 방법은 무엇입니까?

몇 가지 간단한 질문에 대해 생각해 보면 생각을 명확하게 하는 데 도움이 될 수 있습니다.

• 서비스 간에 엄격한 "작업 확인"이 필요합니까, 아니면 "트리거하고 잊어버릴" 수 있습니까?
• 정보 전송 지연이 비즈니스에 얼마나 큰 영향을 미치나요?
• 서비스가 일시적으로 중단되면 메시지를 대기열에 넣어야 합니까, 아니면 당분간 무시할 수 있습니까?

마이크로서비스가 원활하게 통신하도록 하세요. 목표는 가장 유행하는 기술을 추구하는 것이 아니라 시스템의 "생리적 구조"에 가장 적합한 신경망을 찾는 것입니다. 데이터 흐름을 기름칠이 잘 된 베어링처럼 원활하게 만들고, 서비스가 독립적이면서 협력적으로 작동할 수 있도록 해야 하며, 궁극적으로 물리적 기계를 구동하든 디지털 트랜잭션을 처리하든 상관없이 전체 애플리케이션이 유연하고 강력하며 효율적으로 실행될 수 있도록 해야 합니다.

좋은 아키텍처는 그 자체로 정교한 기계와 같으며 모든 커뮤니케이션 세부 사항은 주의 깊게 다듬을 필요가 있습니다. 서비스 간 통신 문제를 해결하면 복잡하고 안정적인 시스템 구축이 갑자기 훨씬 더 명확해지고 제어하기 쉬워진다는 것을 알게 될 것입니다.

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