> 마이크로서비스는 모든 기업에 훌륭한 프레임워크이지만 서로 원활하게 통신하지 못하면 아무 소용이 없습니다. 모놀리식 애플리케이션에 대해 이야기할 때 모놀리식 애플리케이션의 통신은 프로세스 간

> 마이크로서비스는 모든 기업에 훌륭한 프레임워크이지만 서로 원활하게 통신하지 못하면 아무 소용이 없습니다. 모놀리식 애플리케이션에 대해 이야기할 때 모놀리식 애플리케이션의 통신은 프로세스 간 통신이라고 말했습니다. 즉, 메서드 호출을 사용하여 서로를 호출하는 단일 프로세스에서 작업하고 있음을 의미합니다. 클래스를 만들고 대상 모듈 내부에서 메서드를 호출하기만 하면 됩니다. 모두 동일한 프로세스를 실행합니다. 마이크로서비스 기반 애플리케이션으로 이동할 때 가장 큰 문제 중 하나는 통신 메커니즘을 변경하는 것입니다. 마이크로 서비스는 분산되어 있고 마이크로 서비스는 네트워크 수준의 서비스 간 통신으로 서로 통신하기 때문입니다. 각 마이크로 서비스에는 고유한 인스턴스와 프로세스가 있습니다. 따라서 서비스는 HTTP, gRPC 또는 메시지 브로커 AMQP 프로토콜 과 같은 서비스 간 통신 프로토콜을 사용하여 상호 작용해야 합니다 . > ❗️ 동기 프로토콜 : 동기 통신 프로토콜은 HTTP 또는 HTTPS일 수 있습니다. 동기 통신에서 클라이언트는 http 프로토콜을 사용하여 요청을 보내고 서비스의 응답을 기다립니다. 즉, 클라이언트가 서버를 호출하고 클라이언트의 작업을 차단합니다. 클라이언트 코드는 HTTP 서버 응답을 받으면 작업을 계속합니다. 그래서 이 작업을 동기 통신이라고 합니다. 이 방법을 선택할 때 고려해야 할 장단점이 있습니다. ❗️ 비동기식 프로토콜 : 비동기식 통신에서 클라이언트는 요청을 보내지만 서비스의 응답을 기다리지 않습니다. 따라서 여기서 핵심은 클라이언트가 응답을 기다리는 동안 스레드를 차단해서는 안 된다는 것입니다. 이 비동기식 통신에 가장 많이 사용되는 프로토콜은 AMQP(Advanced Message Queuing Protocol)입니다. 따라서 AMQP 프로토콜을 사용하면 클라이언트는 Kafka 및 RabbitMQ 대기열과 같은 메시지 브로커 시스템을 사용하여 메시지를 보냅니다. ⭐️ 고려해야 할 또 다른 점은 통신에 단일 수신기 또는 다중 수신기가 있는지 여부입니다. ❗️ 단일 수신자 : 각 요청은 정확히 하나의 수신자 또는 서비스에 의해 처리되어야 합니다. 이 통신의 예는 명령 패턴입니다. ❗️ 다중 수신자: 각 요청은 0에서 다중 수신자에 의해 처리될 수 있습니다. 이러한 유형의 통신은 비동기식이어야 합니다. 이벤트 기반 아키텍처와 같은 패턴에서 사용되는 게시/구독 메커니즘이 한 예입니다. > 사용하려는 통신 유형에 따라 통신에 사용할 수 있는 프로토콜과 선택 사항이 많이 있습니다. 내부적으로(Docker 호스트 또는 마이크로서비스 클러스터 내) 서비스 간에 통신하는 경우 TCP 및 이진 형식을 사용하는 WCF와 같은 이진 형식 통신 메커니즘을 사용할 수도 있습니다. JSON 또는 XML과 같은 여러 메시지 형식 또는 더 효율적일 수 있는 바이너리 형식도 있습니다. AMQP와 같은 메시지 기반 통신 메커니즘을 사용할 수 있습니다. SignalR 은 백 엔드 서버에서 클라이언트로 콘텐츠를 푸시하기 위한 실시간 통신을 달성하는 좋은 방법입니다. 통신은 실시간이므로 클라이언트 앱은 거의 즉시 변경 사항을 표시합니다. 이것은 일반적으로 많은 WebSocket 연결(클라이언트당 하나씩)을 사용하여 WebSocket과 같은 프로토콜에 의해 처리됩니다. > ❗️ 쿼리 요청과 같은 마이크로 서비스 간의 다중 동기 종속성을 피하려고 하면 클라이언트 앱의 전체 응답 시간이 악화됩니다. ❗️ 마이크로서비스의 오케스트레이션은 프로세스와 도구 모두에서 성공의 핵심 요소입니다. ❗️ 느슨한 결합을 달성하려면 비동기식 통신을 사용하십시오. ❗️ API 변경 사항이 이전 버전과 호환되는지 확인합니다. ❗️ 내결함성을 달성하기 위해 회로 차단기를 사용하여 빠르게 실패합니다. ❗️ 마이크로서비스 에 적합한 메시징 패턴 을 식별합니다 .