마이크로 서비스 REST 또는 AMQP

마이크로 서비스 아키텍처에 관한 많은 기사를 읽었으며 AMQP 또는 REST를 언제 사용해야하는지 궁금했습니다.

서비스 간 느슨한 연결이 좋은 것이며 AMQP가 좋은 선택 인 것 같습니다. 그러나 AMQP를 사용하면 REST 엔드 포인트가 더 이상 필요하지 않다는 의미입니다 (그러나 HATEOAS 개념을 잃어버린 것입니다).

그러나 REST가 실제로 서비스를 구축하는 좋은 방법입니까? 원인 엔드 포인트를 사용하지 않습니다 ... 어떤 경우에 다른 엔드 포인트보다 낫습니까?

언제 하나를 사용해야합니까?

REST를 폐기하면 HATEOAS 이상의 기능을 잃게됩니다. 마이크로 서비스가 퍼블릭 (그리고 퍼블릭이거나 적어도 언젠가 퍼블릭하는 것이 좋습니다) ¹ 인 경우 REST 및 SOAP 이외의 다른 것을 사용하는 것이 문제가됩니다.

• 일부 개발자는 AMQP를 사용한 적이 없습니다.

• 일부는 AMQP를 사용했지만 종종 REST 및 SOAP에 훨씬 익숙합니다.

• 일부 언어의 AMQP 라이브러리는 특히 간단하지 않습니다.

• 서비스에 대한 수동 실험은 매우 제한적입니다. CURL을 사용하여 Amazon S3에 대한 요청을 수행 할 수 있습니다. SQ의 AMQP 변형을 사용하려면 컴퓨터에 무엇을 설치 해야 합니까?

• REST 및 SOAP 디버깅은 쉽습니다. HTTP 교환을 추적하고 분석합니다. AMQP 교환을 디버깅하기 위해 어떤 도구를 사용해야하는지 잘 모르겠습니다.

AMQP는 훌륭하지만 이벤트를 기반으로 한 매우 구체적인 교환 목적으로 수행됩니다. 기술적으로 AMQP를 사용하여 RPC를 수행 할 수는 있지만 주요 목적은 아닙니다.

비동기 측면도 중요합니다. 때로는 이점이 있습니다 : 서버에 요청을하는 동안 앱의 사용자 인터페이스를 차단하고 싶지 않습니다. 때로는 필요 이상으로 힘들어 지기도합니다. 로컬 파일이 손상되어 Amazon S3에서 파일 백업을 복구 한 다음 백업을 복원해야하는 경우 계속 진행하기 전에 배치 파일에서 작업을 마치려면 반드시 CURL이 필요합니다. 동기화 작업 (특정 시간 초과)은 완벽하게 이해됩니다.

기본 작업을 위해 REST를 유지하십시오.

• 제품 구하기

• 송장 저장

메시징이 실제로 의미가있는 작업에 AMQP를 사용하십시오.

• 9 월부터 모든 인보이스를 처리하고 보고서를 표시 할 준비가되면 앱에 알립니다 (일반적으로 2 ~ 10 분이 소요됨)

  ^{AMQP의 이점은 비동기 적 측면입니다. 10 분 동안 보류중인 HTTP 요청은 시간 종료 및 기타 문제를 일으킬 가능성이 높습니다.}

• 지원 담당자, 데이터베이스 관리자, 모니터링 팀,이 데이터베이스를 사용하는 응용 프로그램 개발자 등 관심있는 모든 사람에게 백업이 손상되었다는 정보 전달

  ^{AMQP의 이점은 무엇보다도 백업을 추적하고 손상된 것을 발견하면 경고를 트리거하는 응용 프로그램을 변경하지 않고 가입자를 추가 할 수 있다는 것입니다.}

^{¹ 회사 외부의 사용자가 공개 웹 서비스를 반드시 사용할 필요는 없습니다. 대기업 또는 중소 기업에서 서비스는 종종 같은 회사의 다른 부서에서 사용되며 제 3자가 사용하는 것과 동일한 요구 사항을 갖습니다. 모든 전화를 불신해야합니다 ( 누가 같은 회사에서 서비스를 호출하는지에 대해 들었다고해서 보안 문제를 악용하지는 않을 것입니다.) 같은 인도인이 반드시 전화 번호를 알지 못하고 반드시 그런 것은 아니기 때문에 제대로 문서화해야합니다 영어를 알고) 등}

둘 다 사용하십시오.

REST 스타일 JSON 웹 서비스는 자바 스크립트, iOS 등과의 상호 운용성에 적합합니다.

AMQP는 장기 실행 프로세스, 이벤트 및 마이크로 서비스 오케스트레이션에 적합합니다.

그러나 둘 다 실제 서비스를위한 통신 래퍼 일 뿐이며 동일한 서비스를 여러 가지 방법으로 노출 할 수 있습니다.

AMPQ는 Websocket을 통해 잘 노출 될 수 있습니다. 웹 소켓을 보면 REST 엔드 포인트와 매우 비슷합니다.

REST는 특히 구성 요소 간의 상호 운용성에 적합한 표준 기술입니다. 이는 핵심 요소이며 다른 사람이 사용할 수있는 웹 서비스를 만드는 데 유용합니다. 그러나 이러한 상호 운용성의 일반적인 문제는 사용자 지정 프로토콜보다 비효율적이라는 점입니다.

서비스가 자신 만 사용하는 백엔드 아키텍처를 작성하는 경우 원하는 프로토콜을 사용할 수 있습니다. 더 이상 상호 운용 가능한 프로토콜을 사용하여 더 이상 제약을받지 않습니다. MQ 또는보다 밀접하게 결합되고 성능이 좋은 것을 사용할 수 있습니다. 사용하는 사례는 사용 사례에 따라 다르며, 메시지 버스는 클라이언트가 누가 보낸 메시지를 받는지 신경 쓰지 않는 데이터를 처리하는 분산 서비스 세트에 매우 적합합니다.

AMQP는 지점 간 통신도 지원합니다 (예 : python-qpid-proton자습서 참조 ). REST !=HTTP 부터이를 사용하여 RESTful 인터페이스를 구현할 수 있습니다.

AMQP는 HTTP보다 성능이 훨씬 뛰어납니다.