HYPERLEDGER FABRIC - Developing Applications - Application design elements - Gateway
독자 : Architects, application and smart contract developers
gateway는 application을 대신하여 네트워크 상호작용을 관리하여, application이 비즈니스 로직에 집중할 수 있도록 합니다.
application은 gateway에 연결되면, 모든 후속 상호작용은 gateway의 설정을 사용하여 관리됩니다.
이번 주제에서는 다음의 것을 다룰 것입니다.
- Why gateways are important
- How applications use a gateway
- How to define a static gateway
- How to define a dynamic gateway for service discovery
- Using multiple gateways
Scenario (Why gateways are important)
Hyperledger Fabric 네트워크 채널은 지속적으로 변경될 수 있습니다.
네트워크의 다른 조직에서 기여한 peer, orderer, CA 구성요소들은 왔다가 사라집니다.
그 이유에는 비즈니스 수요 증가 또는 감소, 계획된 중단과 계획되지 않은 중단이 있을 수 있습니다.
gateway는 이러한 부담을 덜어 주어 해결하려는 비즈니스 문제에 집중할 수 있도록 합니다.
MagnetoCorp나 DigiBank application(issue와 buy)은 그들의 네트워크 상호작용을 gateway에 위임합니다. 각 gateway는 두 조직인 MagnetoCorp 및 DigiBank의 여러 peer와 orderer로 구성된 네트워크 채널 토폴로지를 이해하므로 application이 비즈니스 로직에 집중할 수 있습니다. peer는 조직 내부와 조직간에 gossip 프로토콜을 이용하여 서로 대화할 수 있습니다.
gateway는 다음 두 가지 방법으로 application에서 사용할 수 있습니다.
- Static : gateway 구성이 connection profile<connection profile>에 완전히 정의됩니다. gateway를 구성하는데 사용되는 connection profile에 application에서 사용가능한 모든 peer, orderer, CA가 정적으로 정의됩니다. 예를 들어, peer의 경우 endorsing peer 또는 이벤트 알림 허브로서의 역할이 포함됩니다. connection profile <connection profile> 항목에서 이러한 역할에 대해 자세히 알아볼 수 있습니다.
SDK는 트랜잭션 제출과 알람 프로세스를 관리하기 위해 이 정적 토폴로지를 사용하고 gateway connection options<connection options>를 사용합니다. connection profile은 application대신 gateway가 네트워크와 상호작용 하기 위해 충분한 네트워크 토폴로지를 포함하고 있어야합니다. 여기에는 네트워크 채널, 조직, orderer, peer, 그들의 역할이 포함됩니다. - Dynamic : gateway 구성이 connection profile에 최소한으로 정의됩니다. 일반적으로 application의 조직의 한 두개의 peer가 명시되고, 그들은 사용가능한 네트워크 토폴로지를 알기위해 service discovery<Architecture Reference » Service Discovery>를 사용합니다. 이는 peer, orderer, 채널, 인스턴스화된 smart contract 및 그들의 보증 정책을 포함합니다. (프로덕션 환경에서 gateway 구성은 가용성을 위해 2개 이상의 peer를 지정해야합니다.)
SDK는 트랜잭션 제출과 알림 프로세스를 관리하기 위해 gateway connection option과 함께 정적 및 검색된 토폴로지 정보를 사용합니다. 이 과정에서 발견된 토폴로지를 지능적으로 사용합니다. 예를 들어, smart contract를 위해 발견된 보증 정책을 사용하여 최소 필수 보증 peer를 계산합니다.
정적 gateway가 나은지 동적 gateway가 더 나은지 스스로에게 물어보세요.
그 균형은 예측 가능성과 응답성 사이에서 찾을 수 있습니다.
정적 네트워크는 네트워크가 바뀌지 않는 것으로 인식하므로 언제나 같은 방식으로 동작할 것입니다.
만약 사용가능한 경우 언제나 동일한 peer와 orderer를 사용하기 때문에 예측이 가능합니다.
동적 네트워크는 네트워크가 어떻게 변하는지 알기 때문에 더 빠르게 반응합니다.
회복력과 확장성을 제공할 수 있는 새로운 peer와 orderer를 잠재적인 예측 가능성안에 약간의 비용을 들여서 사용할 수 있습니다.
일반적으로 동적 네트워크를 사용하는 것이 좋으며, 실제로 이것이 gateway의 기본 모드입니다.
같은 connection profile은 정적으로나 동적으로 사용될 수 있다는 것을 유의하세요.
명백하게 profile이 정적으로 사용된다면 포괄적이어야하는 반면에, 동적이면 적은 정보만 필요합니다.
gateway의 두가지 스타일은 application에 영향을 끼치지 않습니다.
application 프로그램 설계는 사용된 gateway가 정적이든 동적이든 변경하지 않습니다.
이것은 몇몇의 application이 service discovery를 사용할수도 있다라는 의미인 반면에 그 외 다른 application은 사용하지 않을 수도 있음을 의미합니다.
일반적으로 동적 discovery을 사용한다는 것은 SDK의 적은 정의, 더 지능적임을 의미합니다. 이것이 기본 값입니다.
Connect (How applications use a gateway)
application이 gateway에 연결할 때, 두가지 옵션이 제공됩니다.
이는 나중에 SDK 처리 중에 사용됩니다.
await gateway.connect(connectionProfile, connectionOptions);- Connection profile : connectionProfile은 정적으로든 동적으로든 SDK에 의해 트랜잭션 처리에 사용되는 gateway 설정입니다. YAML이나 JSON으로 명시될 수 있지만, gateway에 전달할 때는 JSON object로 변환해야합니다.
let connectionProfile = yaml.safeLoad(fs.readFileSync('../gateway/paperNet.yaml', 'utf8'));connection profile <connection Profile>와 설정하는 방법에 대해서 더 읽어보세요.
- connection options : connectionOptions를 사용하면 application이 원하는 트랜잭션 처리 행동을 구현하지 않고 선언할 수 있습니다. connection options는 네트워크 구성요소와 상호작용 패턴을 제어하기위해 SDK에 의해 해석됩니다. (예를 들어 연결할 ID 또는 이벤트 알림에 사용할 peer를 선택) 이러한 옵션은 기능에 영향을 끼치지 않고 application의 복잡성을 상당히 줄입니다. application이 요구하는 low level의 로직 대부분을 SDK가 구현하기 때문에 가능합니다. connection options은 로직 흐름을 제어합니다.
사용 가능한 connection options<connection options>의 목록과 언제 사용해야하는지에 대해서 읽어보세요.
Static (How to define a static gateway)
정적 gateway는 고정된 네트워크를 정의합니다.
MagnetoCorp 시나리오에서 gateway는 MagnetoCorp의 단일 peer와 DigiBank의 단일 peer, MagnetoCorp의 orderer를 식별합니다.
그 대신에 gateway는 MagnetoCorp와 DigiBank의 모든 peer와 orderer을 정의해야합니다.
두 경우 모두 gateway는 기업 어음 트랜잭션을 승인하고 배포하기에 충분한 네트워크를 정의해야합니다.
application은 gateway.connect() API의 discovery: {enabled:false} connect option을 명시적으로 지정하여 정적으로 gateway를 사용할 수 있습니다.
그 대신 FABRIC_SDK_DISCOVERY=false 환경 변수 설정 은 application 선택을 재정의해야합니다.
MagnetoCorp issue application에 의해 사용되는 connection profile을 확인해보세요. (github.com/hyperledger/fabric-samples/blob/master/commercial-paper/organization/magnetocorp/gateway/networkConnection.yaml)
그들의 역할을 포함하여 모든 peer, orderer 그리고 CA가 이 파일에서 어떻게 명시되어있는지 확인하세요.
정적 gateway는 어떤 한 순간의 네트워크를 나타냅니다.
네트워크가 변경되면, 이를 gateway 파일에 반영하는 것이 중요합니다.
application은 gateway 파일이 다시 로드될 때 이러한 변화를 자동으로 알 것입니다.
Dynamic (How to define a dynamic gateway for service discovery)
동적 gateway는 고정된 작은 네트워크를 정의합니다.
MagnetoCorp 시나리오에서 동적 gateway는 단지 MagnetoCorp의 단일 peer를 식별합니다.
다른 모든 것들은 앞으로 발견될 것입니다. (복원성을 제공하기 위해, 두 개의 부트스트랩 peer같은 정의하는 것이 좋습니다.)
application에 의해 service discovery<Service Discovery _ Architecture Reference>가 선택되었다면, gateway 파일안에서 정의된 토폴로지가 이 프로세스에서 생성된 토폴로지를 추가시킵니다.
service discovery는 gateway 정의를 시작하고, gossip protocol<Gossip data dissemination protocol>을 사용하여 MagnetoCorp 조직안의 모든 연결된 peer와 orderer를 찾습니다.
만약 anchor peer<Glossary - AnchorPeer>가 채널을 정의한다면, service discovery는 연결된 조직내에서 구성요소를 검색하기위해 조직 전체에서 gossip protocol을 사용할 것입니다.
이 프로세스는 peer에 설치된 smart contract와 채널 수준에 정의된 그들의 보증 정책을 검색할 것입니다.
정적 gateway와 마찬가지로 검색된 네트워크는 기업어음 트랜잭션을 승인하고 배포하기에 충분해야합니다.
동적 gateway는 Fabric application의 기본 설정입니다.
application은 gateway.connect() API의 discovery: {enabled:true} connect option을 명시적으로 지정할 수 있습니다.
그 대신 FABRIC_SDK_DISCOVERY=true 환경 변수 설정은 application 선택을 재정의해야합니다.
동적 gateway는 최신 네트워크를 나타냅니다.
네트워크가 변경되면, service discovery는 application에 표시되는 토폴로지를 네트워크에 정확하게 반영한다는 것을 확인합니다.
application은 자동으로 이러한 변화를 포착합니다. gateway 파일이 다시 로드될 필요가 없습니다.
Multiple gateway (Using multiple gateways)
마지막으로 동일하거나 다른 네트워크에서 application이 여러 gateway를 정의하는 것은 간단합니다.
게다가 application은 정적으로나 동적으로 name gateway를 사용할 수 있습니다.
여러 gateway를 갖는 것은 도움이 될 수 있습니다. 몇가지 이유를 확인해보세요.
- 다른 사용자 대신 요청을 처리합니다.
- 동시에 다른 네트워크에 연결할 수 있습니다.
- 네트워크 구성을 기존 구성과 동시에 비교하여 테스트합니다.
출처 ]
hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/gateway.html#