Служба обнаружения¶

Назначение службы обнаружения¶

Для выполнения чейнкода на одноранговых узлах, отправки транзакций в узлы службы упорядочения и получения обновленной информации о статусе транзакций, приложения используют API, предоставляемые комплектами для разработки (SDK).

Однако для работы функций SDK требуется много информации, чтобы позволить приложениям подключаться к соответствующим узлам сети. Помимо сертификатов удостоверяющего центра и TLS-сертификатов узлов службы упорядочения и одноранговых узлов в канале, их IP-адресов и номеров портов, для работы SDK требуются соответствующие политики одобрения, а также информация об узлах, на которых установлен чейнкод (чтобы приложение знало, каким одноранговым узлам можно отправлять запросы на выполнение чейнкода).

До версии 1.2 эта информация кодировалась статически. Однако такая реализация не позволяет динамически реагировать на изменения в сети (например, при добавлении одноранговых узлов, которые установили соответствующий чейнкод, или одноранговых узлов, которые временно отключены). Статические конфигурации также не позволяют приложениям реагировать на изменения политик одобрения (такое может произойти при добавлении новой организации в канал).

Кроме того, клиентское приложение не имеет возможности узнать, какие одноранговые узлы обновили свои копии реестра, а какие нет. В результате приложение может отправлять запросы одноранговым узлам, копии реестра которых не синхронизированы с остальной сетью, что может привести к аннулированию транзакции на этапе записи и, как следствие, к нерациональному использованию ресурсов.

Служба обнаружения улучшает этот процесс, позволяя одноранговым узлам динамически вычислять необходимую информацию и предоставлять ее функциям SDK в подходящем формате.

Принципы работы службы обнаружения в Fabric¶

Приложение загружается с информацией о группе одноранговых узлов, которым разработчик или администратор приложения доверяет предоставить подлинные ответы на запросы обнаружения. Подходящий одноранговый узел для использования клиентским приложением — это узел, принадлежащий той же организации. Обратите внимание: чтобы служба обнаружения знала об этих одноранговых узлах, для них должна быть определена переменная EXTERNAL_ENDPOINT. Как определить эту переменную, описано в разделе Интерфейс командной строки службы обнаружения.

Приложение направляет запрос конфигурации в службу обнаружения и получает всю статическую информацию, которая потребовалась бы для обращения к остальным узлам сети. Эта информация может быть обновлена в любой момент путем отправки запроса в службу обнаружения однорангового узла.

Служба работает на одноранговых узлах, а не в самом приложении, и использует информацию сетевых метаданных, поддерживаемую уровнем протокола gossip, чтобы узнать, какие узлы находятся в сети. Также служба обнаружения извлекает информацию, такую как политики одобрения, из базы данных состояния однорангового узла.

Благодаря службе обнаружения приложениям больше не нужно указывать, от каких одноранговых узлов им требуется одобрение. Функции SDK позволяют отправить запрос в службу обнаружения, запрашивая необходимые одноранговые узлы согласно идентификатору канала чейнкода. Затем служба обнаружения вычисляет дескриптор, состоящий из двух объектов:

Топология: список групп одноранговых узлов и соответствующее количество одноранговых узлов из каждой группы, которые должны быть выбраны.
Привязка групп к одноранговым узлам: списки одноранговых узлов канала в группах топологии. На практике каждая группа, скорее всего, будет состоять из одноранговых узлов, представляющих отдельные организации, но поскольку API службы является более общим и не воспринимает организации, то это всего лишь «группа».

Ниже приведен пример дескриптора для политики AND(Org1, Org2), когда в каждой организации есть два одноранговых узла.

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

Другими словами, политика одобрения требует подписи от одного однорангового узла организации Org1 и одного однорангового узла организации Org2. А также здесь указаны имена одноранговых узлов тех организаций, которые могут предоставлять одобрение (peer0 и peer1 организаций Org1 и Org2).

Затем SDK выбирает случайную топологию из списка. В приведенном выше примере политика одобрения выглядит как Org1, AND Org2. Если бы вместо этого использовались правила OR, SDK случайным образом выбрал бы организацию Org1 или Org2, поскольку подпись от однорангового узла любой организации удовлетворяла бы требованиям политики.

После выбора топологии, SDK выбирает одноранговый узел из топологии на основе критериев, указанных на стороне клиента (это возможно, поскольку SDK имеет доступ к таким метаданным, как количество блоков в реестре). Например, в соответствии с количеством одноранговых узлов из каждой группы в топологии могут быть выбраны одноранговые узлы с большим количеством блоков в реестре по сравнению с другими или исключены те, которые по данным приложения находятся не в сети. Если на основании критериев предпочтение не отдается какому-либо одноранговому узлу, SDK случайным образом выберет одноранговые узлы, которые наиболее соответствуют критериям.

Возможности службы обнаружения¶

Служба обнаружения может отвечать на следующие запросы:

Запрос конфигурации: возвращает MSPConfig всех организаций в канале вместе с конечными точками узлов службы упорядочения канала.
Запрос о членстве одноранговых узлов: возвращает одноранговые узлы, которые входят в состав канала.
Запрос об одобрении: возвращает дескриптор политики одобрения для указанного чейнкода(ов) в канале.
Запрос о локальном членстве однорангового узла: возвращает информацию о локальном членстве однорангового узла, который отвечает на запрос. По умолчанию, чтобы одноранговый узел ответил на этот запрос, клиент должен быть администратором.

Специальные требования¶

Когда одноранговый узел работает с включенным TLS-шифрованием, клиент должен предоставить TLS-сертификат при подключении к этому узлу. Если одноранговый узел не настроен для проверки клиентских сертификатов (для параметра clientAuthRequired указано значение false), этот TLS-сертификат может быть самоподписанным.