원서 : https://hyperledger-fabric.readthedocs.io/en/release-1.4/discovery-overview.html
- Why do we need service discovery?
- peer에서 chaincode를 실행하고, orderer에 transaction을 제출하고, state를 업데이트 하기위해~ application은 SDK에서 제공하는 API로 연결 합니다.
- 하지만, application이 node에 접속을 하려면~ SDK에 많은 정보가 필요합니다.
- 게다가 "CA 및 TLS 인증서", "IP 와 Port", "보증 정책" 등도 알아야 합니다.
- 구버젼에서는 이런 정보들을 정적으로 관리해서, 동적으로 변하는 네트워크에 적절하지 않았습니다. (peer의 추가/삭제 등)
- 정적인 설정은 "보증 정책"의 변화에 따른, application에도 적합하지 않습니다. (새 organization 합류 등)
- 또한, client application에서 어떤 peer가 ledger를 업데이트 하였는지? 알수가 없습니다.
- 이결과로 client application에서 "ledger 동기화"도 안된 peer에게 propsal을 제출하기라도 하면, 큰 리소스 낭비를 초래합니다.
- 그래서 discovery-service란? peer에게 필요한 정보를 동적으로 가져하면서, 전체 프로세스를 향상 시키는것 입니다.
- How service discovery works in Fabric
- application에서 신뢰하는 peer 그룹을 인지하고, discovery요청에 관한 응답를 할수있어야 합니다.
- client application에서 사용하기 적합한 peer으로 같은 organizagion을 꼽을수있습니다.
- peer를 discovery-service에 알릴려면, "EXTERNAL_ENDPOINT"를 정의해야 하는것을 명심하십시요.
- 더 자세한 사항은 "Service Discovery CLI" 을 참고하세요.
- application에서 discovery-service에 질의를 하여, network의 모든 node와 통신에 필요한 정보를 획득합니다.
- 이러한 정보는 해당 peer의 discovery-service에 후속질의를 해서, 언제든지 갱신을 될 수 있습니다.
- 즉, discovery-service는 peer에서 돌고있는것 입니다. 그리고 gossip으로 유지되는 네크워크 메타데이터를 사용해서, 온라인 상태의 peer를 찾는것 입니다.
- 또한, 해당 peer의 state-db에서~ 관련 "보증 정책"을 가져올수도 있습니다.
- discovery-service가 있으면, application은 더이상 '보증-peer'를 직접 가지고 있을 필요가 없습니다.
- 즉, SDK에서 간단히 discovery-service에게 질의를 하면 되는것 입니다.
- 결과적으로 아래와 같은 2가지의 정보가 산출되는것 입니다.
- Layouts : peer 그룹의 리스트 와 각 그룹의 peer 수
- Group to peer mapping : 위 Layours의 그룹의 peer.
- 예) "보증 정책" AND(Org1, Org2) 경우
- Layouts: [ QuantitiesByGroup: { "Org1":1,"Org2":1, } ],
- EndorsersByGroups: { "Org1": [peer0.org1,peer1.org1], "Org2": [peer0.org2, peer1.org2] }
- ("보증 정책"은 Org1 및 Org2 의 peer에 서명을 요구하며, 각 Org의 '보증-peer' 이름은 알려주고 있다)
- SDK에서는 먼제 Layouts를 만족하도록 선택 합니다. 그런다음, SDK는 해당되는 peer를 선택합니다.
- 실질적으로, SDK는 peer의 여러가지 상태를 따져가면서~ 가장 적합할것같은 선택을 하게 되는것 입니다.
- Capabilities of the discovery service
- discovery-service는 아래와 같은 질의를 처리 합니다.
- Configuration query : channel의 모든 organization의 MSPconfig를 리턴 합니다.
- Peer membership query : channel에 참여한 모든 peer를 리턴 합니다.
- Endorsement query : channel의 특정 chaincode에 "보증 정책"을 리턴 합니다.
- Local peer membership query : 쿼리에 응답하는 peer의 local-membership 정보를 리턴 합니다. (디폴트 admin권한의 client만 질의가능)
- discovery-service는 아래와 같은 질의를 처리 합니다.
- Special requirements
- peer가 TLS 통신을 한다면, client는 'TLS 인증서'를 가지고 있어야 합니다.
- peer가 client에 인증서를 확인하지 않도록 되어있을떄는(clientAuthRequierd=false), 'TLS 인증서'를 자가서명으로 하셔도 됩니다.
-끝-
'hyperledger > fabDoc.Arch-Ref' 카테고리의 다른 글
10) Read-Write set semantics (0) | 2019.08.18 |
---|---|
9) Private Data (0) | 2019.08.18 |
8) Peer channel-based event services (0) | 2019.08.18 |
6) Channels (0) | 2019.08.18 |
1) Architecture Origins (0) | 2019.05.15 |