-- 배경--
현재 블록체인 크로스체인 플랫폼의 접근 방식은 아키텍처 설계 측면에서 상당히 다르며 애플리케이션 체인을 크로스체인 시스템에 빠르고 편리하게 연결하는 것이 시급한 문제다. BitXHub의 BitXHub 크로스체인 서비스 플랫폼은 릴레이 체인 + 게이트웨이의 크로스체인 솔루션을 채택하고 있으며, 크로스체인 게이트웨이는 블록체인 간의 트랜잭션을 수집하고 전파하는 역할을 합니다. 플러그인 메커니즘의 설계는 크로스 체인 게이트웨이의 핵심 기능 모듈에서 게이트웨이(Pier)와 애플리케이션 체인 사이에서 상호 작용하는 모듈을 분리하여 서로 다른 유형의 애플리케이션 체인이 크로스 체인에 효율적으로 연결될 수 있도록 합니다. 체인 시스템. Pier가 실행 중일 때 플러그인을 동적으로 로드하여 다양한 애플리케이션 체인의 유연한 적응이 완료됩니다. Pier와 애플리케이션 체인 사이의 상호 작용을 향상시키기 위해 특정 애플리케이션 체인 플러그인은 서로 다른 블록체인의 특성에 따라 특정 인터페이스를 구현해야 하며 상호 작용 인터페이스는 다음 기능을 충족해야 합니다.
1) 애플리케이션 체인에서 교차 체인 이벤트를 모니터링하고 처리를 위해 코어 모듈로 전달합니다.
2) 게이트웨이에서 크로스 체인 요청을 실행합니다(다른 애플리케이션 체인에서).
3) 애플리케이션 체인에서 수신 및 실행된 교차 체인 요청의 상태를 능동적으로 쿼리하는 기능.
플러그인 구현 방식의 설계에서 우리는 두 가지 다른 플러그인 메커니즘을 연속적으로 채택했으며 다음은 네이티브 플러그인을 사용할 때 발생하는 문제와 새로운 플러그인 솔루션의 장점을 소개합니다.
—— 네이티브 플러그인——
go 언어는 버전 1.13부터 플러그인으로 컴파일을 지원하며 사용법은 다음과 같습니다.
go build --buildmode=plugin -o appchain.so *.go
go 프로젝트는 컴파일 시 --buildmode 를 통해 플러그인 모드로 지정할 수 있으며, 출력은 이런 식으로 동적 링크 파일이 됩니다. 이 파일은 직접 실행할 수 있는 바이너리 파일이 아니라 다른 바이너리 런타임에 제공되는 동적 호출입니다.
다음과 같이 기본 바이너리에서 사용됩니다.
이점:
이점:
1) 사용자 경험은 코드 모듈의 이진화와 유사하게 네이티브 코드와 일치합니다.
결점:
결점:
1) 네이티브 플러그인의 종속 라이브러리는 메인 프로그램과 완전히 일치해야 합니다. 그렇지 않으면 시작할 때 오류가 보고되고 종속성이 직접 참조되는지 간접적인지에 관계없이 이 문제가 발생합니다.
—— RPC 플러그인으로 전환 ——
기본 플러그인의 엄격한 버전 제한으로 인해 플러그인 및/또는 게이트웨이 기본 프로그램 기능을 업그레이드할 때 기본 프로그램의 일부 종속성이 의도하지 않게 업그레이드될 수 있으며 플러그인도 동일한 적응을 수행해야 합니다. 업그레이드. 이 방법은 플러그인의 완전한 분리에 도움이 되지 않으므로 RPC를 사용하는 다른 GO 플러그인 프로젝트로 전환했습니다. (프로젝트의 GitHub 주소: https://github.com/hashicorp/go-plugin)
Hashicorp의 go-plugin은 GO의 네이티브 플러그인 메커니즘이 등장하기 전에 이미 존재했지만 GO의 네이티브 플러그인이 나온 후에도 프로젝트에 대한 지원을 포기하지 않았습니다. 매우 완벽합니다. 일부 시나리오에서는 go-plugin이 더 편리합니다.
go-plugin 플러그인은 다음과 같이 사용됩니다.
쉽게 말해 go-plugin 프로젝트에서 구현한 플러그인 방식은 C/S 모드를 채택하여 메인 프로그램을 RPC 클라이언트로 사용하고 특정 플러그인을 RPC 서버로 사용하는 방식이다. 클라이언트도 인터페이스 사양을 기반으로 합니다.
구체적인 이용 절차는 다음과 같습니다.
1) 추상화에는 플러그인 인터페이스가 필요하며, 여기서 네이티브 플러그인에서 사용된 인터페이스 정의를 직접 재사용할 수 있습니다.
2) 클라이언트와 서버 모두 위의 인터페이스를 구현합니다. 서버 측 구현은 특정 플러그인 처리 로직에 대한 코드이며, 클라이언트 측 구현은 gRPC 처리 결과 및 예외 정보를 캡슐화하기만 하면 되며, 메인 프로그램은 플러그인 사용 시 gRPC를 약하게 인식할 수 있습니다. 안에.
서버 구현 부분:
클라이언트 구현 부분:
▲다음 사항에 추가로 주의를 기울여야 합니다.
플러그인은 자체 RPC 서비스를 사용하도록 기본 프로그램에 권한을 부여하기 위해 plugin.Serve를 호출해야 합니다. 여기서 주 프로그램과 플러그인이 통신하기 전에 주로 플러그인의 버전 정보 확인을 포함하여 핸드셰이크가 필요하다는 점에 유의해야 합니다.
기본 프로그램은 다른 프로세스에서 실행되는 플러그인을 시작하기 위해 plugin.Client 개체를 사용하므로 플러그인의 충돌이 기본 프로그램에 영향을 미치지 않습니다.
클라이언트와 서버는 실제로 사용하는 동안 프로세스 간 소켓을 통해 통신하는데, 이는 어느 정도의 성능을 희생하지만 네이티브 플러그인의 단일 프로세스 솔루션이 제공하는 종속성 디커플링 및 다국어 지원과 같은 유연한 응용 프로그램을 제공합니다. 에는 없습니다.
-- 결론--
저자 소개
저자 소개
FunChain 기술 데이터 그리드 연구소 BitXHub 팀
FunChain 기술 데이터 그리드 연구소 BitXHub 팀
IOS
Android