마이크로 서비스 교차 언어 호출 (선택)

마이크로서비스 아키텍처는 현재 인터넷 아키텍처의 트렌드가 되었으며, 마이크로서비스에 대한 토론은 거의 모든 기술 대회의 거의 대부분을 차지하고 있습니다. 국내에서 가장 많이 사용되는 서비스 거버넌스 프레임워크는 알리오픈 소스가 아닌 듀보 (dubbo) 이며, 킬로미터망도 듀보 (dubbo) 를 마이크로서비스 거버넌스 프레임워크로 선택했다. 한편, 대부분의 인터넷 회사와 마찬가지로, 킬로미터의 개발 언어는 다양하다. 대부분의 백엔드 업무는 Java 에 의해 지지되고, 각 업무 라인마다 자체 개발 언어를 선택할 수 있는 옵션이 있어 nodejs, python, go 다국어 호출 문제가 발생했다.

언어 간 호출은 큰 주제이자 어려운 기술 활동입니다. 현재 업계에서 자주 언급되는 솔루션은 다음과 같습니다.

우리가 언어 간 호출에 대해 다시 이야기 할 때 우리는 무엇에 대해 이야기하고 있습니까? 이러한 좀 더 일반적이고 성숙한 솔루션을 살펴보면 언어 간 호출을 해결하는 방법은 두 가지

에 불과하다는 결론을 내릴 수 있습니다

새로운 팀이 기술 선택에 직면할 경우, 기존 시스템의 호환성 문제

를 고려하여 위 방안을 모두 참고할 수 있다고 생각합니다.

기존 시스템의 마이그레이션 비용

이것도 중요한 선택형 요인이다. 우리가 한 첫 번째 시도는 RPC 프로토콜에 힘쓰는 것이었다.

공통 프로토콜에 대한 언어 간 지원

스프링 MVC 의 멋진 시대

Springmvc

Springmvc

실제 언어 간 호출이 구현되기 전에' 언어 간' 을 구현하려는 대부분의 시나리오는. alibaba.dubbo.remoting.exchange.response

를 사용하는 것입니다

Invoke id: 메시지 id, long 유형입니다. 각 요청의 고유 id (비동기 통신으로 인해 요청 요청을 반환된 response 에 대응)

Body length: 메시지 본문 body 길이, int 유형, 즉 Body Content 의 바이트 수 기록

Body content: 응답 매개변수의 추상적 직렬화 후 저장되는 요청 매개변수입니다.

프로토콜 메시지는 결국 바이트가 되어 TCP 전송을 사용하며, 네트워크 모듈을 지원하고 소켓과 같은 캡슐화가 있는 언어라면 통신은 문제가 되지 않습니다. 그럼, 언어 간 어려움은 어디에 있나요? 다른 언어로 Java 를 호출하는 데는

의 두 가지 주요 어려움이 있습니다

Ps: 듀오 프로토콜 통신 demo (/lexburner/dubbojs-learning)