Service Discovery¶

Why do we need service discovery?¶

ピアでチェーンコードを実行し、トランザクションをordererに送信し、トランザクションのステータスについて通知を受けるために、アプリケーションはSDKによって公開されるAPIに接続します。

ただし、アプリケーションが関連するネットワークノードに接続できるようにするためには、SDKに多くの情報が必要となります。チャネル上のordererとピアのCAそしてTLS証明書、--- およびそれらのIPアドレスとポート番号 --- に加えて、 SDKは関連するエンドースメントポリシーとともに、チェーンコードがどのピアにインストールされているか (それによってアプリケーションはどのピアにチェーンコードの提案を送信するかがわかります)を知っていなくてはなりません。

v1.2より前のバージョンではこの情報は静的にエンコードされていました。ただし、この実装はネットワークの変更 (関連するチェーンコードをインストールしたピアの追加、または一時的なピアのオフライン)に対して動的に対応できるものではありません。静的な設定では、(新しい組織がチャネルに参加したときに発生する可能性がある)エンドースメントポリシー自体の変更に対してアプリケーションが対応することもできません。

また、クライアントアプリケーションには更新された台帳があるピアとないピアを知る方法がありません。その結果、アプリケーションは台帳データがネットワークの他の部分と同期していないピアに提案を送信し、その結果、トランザクションがコミットしたときに無効になり、結果としてリソースを浪費する可能性があります。

ディスカバリーサービス はピアが必要な情報を動的に算出し、それを解釈可能なようにSDKに提供することによって、このプロセスを改善します。

How service discovery works in Fabric¶

アプリケーションはアプリケーション開発者/管理者によって信頼され、ディスカバリークエリに対して真正の応答を提供するピアのグループを認識して起動します。クライアントアプリケーションで使用するピアの候補としては同じ組織内のピアが適しています。ピアがディスカバリーサービスに認識されるためには EXTERNAL_ENDPOINT が定義されていなければならないことに注意してください。この方法については Service Discovery CLI ドキュメントを参照してください。

アプリケーションは構成クエリをディスカバリーサービスに発行し、ネットワークの他のノードと通信を行うのに、このサービスを使わなければ必要であった静的な情報すべてを取得します。この情報は、後続のクエリをピアのディスカバリーサービスに送信することにより、いつでも更新できます。

このサービスはアプリケーション上ではなくピア上で実行され、ゴシップコミュニケーションレイヤーで管理されているネットワークメタデータ情報を使用して、どのピアがオンラインであるかを把握します。また、ピアのステートデータベースから関連するエンドースメントポリシーなどの情報を取得します。

サービスディスカバリーを使用すると、アプリケーションはエンドースメントを取得するピアを指定する必要がなくなります。 SDKは、チャネルとチェーンコードIDを指定して、どのピアが必要かを尋ねるクエリをディスカバリーサービスに送信するだけです。ディスカバリーサービスは次の2つのオブジェクトで構成される記述子を計算します：

Layouts: ピアのグループのリストと、各グループから選択する必要があるピアの数。
Group to peer mapping: レイアウト内のグループからチャネルのピアへのマッピング。実際には各グループは個々の組織を表すピアである可能性が最も高いですが、サービスAPIは汎用的であり、組織を意識しないため、これは単なる「グループ」です。

以下は、各組織に2つのピアがある AND(Org1, Org2) のポリシーの評価からの記述子の例です。

Layouts: [
     QuantitiesByGroup: {
       “Org1”: 1,
       “Org2”: 1,
     }
],
EndorsersByGroups: {
  “Org1”: [peer0.org1, peer1.org1],
  “Org2”: [peer0.org2, peer1.org2]
}

言い換えると、エンドースメントポリシーは組織1の1つのピアと組織2の1つのピアからの署名が必要としています。そして、エンドースできる組織の中で利用可能なピアの名前(Org1とOrg2の両方にある peer0 と peer1 )を提示します。

次に、SDKはリストからランダムにレイアウトを選択します。上の例ではエンドースメントポリシーはOrg1 AND Org2です。もしそれが OR ポリシーであれば、SDKはランダムにOrg1かOrg2のどちらかを選択します。どちらかのOrgからのピアからの署名がポリシーを満たすからです。

SDKはレイアウトを選択した後、クライアント側で指定された基準に基づいて、レイアウト内のピアから選択します (SDKは台帳の高さなどのメタデータにアクセスできるため、これを行うことができます)。たとえば、レイアウト内の各グループのピアの数に応じて台帳の高さが他の高さが高いピアを優先したり、アプリケーションがオフラインであることを検出したピアを除外したりできます。基準に基づいて望ましいピアが1つもない場合、SDKは基準を最も満たすピアをランダムに選択します。

Capabilities of the discovery service¶

ディスカバリーサービスは次のクエリに応答できます。

コンフィギュレーションクエリ(Configuration query)：チャネル内のすべての組織の MSPConfig と、そのチャネルのordererエンドポイントを返します。
ピアメンバーシップクエリ(Peer membership query):チャネルに参加しているピアを返します。
エンドースメントクエリ(Endorsement query): チャネル内の特定のチェーンコードのエンドースメント記述子を返します。
ローカルピアメンバーシップクエリ(Local peer membership query): クエリに応答するピアのローカルメンバーシップ情報を戻します。デフォルトでは、クライアントは、このクエリに応答するピアの管理者である必要があります。

Special requirements¶

ピアがTLSを有効にして実行されている場合、クライアントはピアに接続するときにTLS証明書を提供する必要があります。ピアがクライアント証明書を確認するように設定されていない場合(clientAuthRequiredがfalse)、このTLS証明書は自己署名可能です。