Как и многие другие разработчики, я начал разработку в Hyperledger, используя образцы Hyperledger Fabric. Поскольку наша организация одной из первых использовала Hyperledger Fabric, мы начали работать с V1.1.
Итак, у всех наших сетей были длинные файлы конфигурации, нам пришлось упомянуть множество компонентов, дающих подробную информацию о каждой сущности. Пока мы искали независимые решения, Hyperledger Fabric предложила решение в версии 1.2.
Этим решением было s обнаружение сервисов, которое избавило нас от множества проблем и позволило разработать масштабируемую сеть без дополнительных усилий.
В этой статье мы рассмотрим, как работает обнаружение сервисов в Hyperledger Fabric, и посмотрим, что делает его таким актуальным и полезным для разработчиков.
Приложение, которое мы запускаем с комплектом разработки программного обеспечения (SDK) Hyperledger Fabric, использует это обнаружение службы на одноранговых узлах для получения всей информации, необходимой для дальнейшего взаимодействия с другими одноранговыми узлами сети.
Чтобы понять, как работает обнаружение сервисов, нужно сначала понять, как данные передаются с использованием протокола сплетен в одноранговых узлах.
Что такое протокол сплетен?
Просматривая документацию, вы сталкиваетесь с множеством причудливых терминов, таких как якорь и партнеры-лидеры. Мы постараемся понять, как проходит важная для нас транзакция и как все встает на свои места.
Для лучшего понимания мы будем рассматривать только часть транзакции после того, как блокировка будет снята со службы заказа.
Как только блок освобождается, влияние всех транзакций, которые являются частью блока, должно отражаться на всех партнерах, которые являются частью канала.
Обычно это делается двумя способами:
1. Служба заказов сама поставляет блок всем партнерам.
2. Выбран один одноранговый узел, и служба заказа предоставляет блоки этому одноранговому узлу, в свою очередь, этот одноранговый узел передает его другим одноранговым узлам.
Hyperledger Fabric советует нам использовать последнее. В этом случае используется механизм протокола сплетен.
Одноранговые и ведущие узлы
Теперь, когда мы прошли через поток в обычных терминах, давайте также рассмотрим причудливые термины, введенные Hyperledger Fabric.
Служба заказа поставляет блоки одному партнеру организации, известному как партнер-лидер. Это значительно снижает сетевое взаимодействие, так как теперь единственная ответственность за распространение блоков среди других одноранговых узлов своей организации лежит на Leader, а не на службе заказа, которой больше не нужно беспокоиться обо всех узлах.
Fabric также поддерживает межорганизационное взаимодействие, то есть путем включения узлов привязки.
Первоначально, когда настроена сеть с поддержкой сплетен, одноранговые узлы знают только одноранговых узлов внутри своей организации. После того, как одноранговые узлы привязки установлены, их можно использовать для сбора информации обо всех одноранговых узлах из других организаций.
Как работает обнаружение служб?
Теперь, если сеть настроена с включенными сплетнями и установленными одноранговыми узлами привязки, каждый одноранговый узел будет иметь информацию обо всех одноранговых узлах в сети Fabric. Вся информация хранится сплетнями в метаданных.
Служба, работающая на каждом одноранговом узле, обеспечивает 2 функции:
- Идентификация пиров, которые находятся в сети
- Сбор информации из государственной базы данных об индоссаменте (ам)
Приложение, которое мы запускаем с комплектом разработки программного обеспечения (SDK) Hyperledger Fabric, использует эту службу на одноранговых узлах для получения всей информации, необходимой для дальнейшего взаимодействия с другими одноранговыми узлами сети.
Впоследствии данные возвращаются таким образом, чтобы SDK мог напрямую использовать их для отправки дальнейших транзакций.
Давайте посмотрим, как это работает!
Я запускаю первую сеть от Fabric, в которой есть две организации с двумя одноранговыми узлами в каждой. После того, как сеть настроена, все одноранговые узлы имеют информацию о каждом другом узле как той же, так и других организаций.
Вот журналы в одноранговом узле, которые вы можете прочитать, чтобы проверить, есть ли какие-либо проблемы со связью.
Как видно из журналов peer peer0.org1.rajat.com, он взаимодействует со всеми одноранговыми узлами, а именно. peer1.org1.rajat.com, peer0.org2.rajat.com и peer1.org2.rajat.com.
Затем мы установим chaincode на одноранговом узле peer1. org1.rajat.com. Ниже приведен снимок экрана, который подтверждает, что цепной код присутствует только в peer1.org1.rajat.com.
Мы будем отправлять транзакцию, используя peer0.org1.rajat.com в конфигурации подключения. Вы увидите, что транзакция теперь обрабатывается с предупреждением о внутреннем отсутствующем цепном коде.
Эффект от этой транзакции можно увидеть в одноранговой части этого канала.
Чтобы обуздать свое любопытство, я начал добавлять сообщения журнала в SDK в разных местах, и вот что я обнаружил. Я добавил результат, показанный на изображении ниже:
Примечание. Ответ в этом фрагменте обрезан, чтобы отображать только релевантную информацию, касающуюся только сети.
Дескриптор службы обнаружения
Наконец, чтобы завершить наше понимание, мы должны просмотреть странно выглядящий объект в приведенном выше журнале (Изображение 5).
Когда наш SDK связывается с обнаружением службы, запущенным на каждом одноранговом узле, возвращается дескриптор, состоящий из двух объектов:
1. Макеты: используется для получения списка одноранговых узлов и информации о количестве одноранговых узлов, которое нам потребуется от каждой группы.
2. Подтверждающий по группам: в идеале это возвращает текущих активных партнеров в данной организации.
Из вывода можно различить и другую информацию. Но по сути служба полагается на эти два компонента для отправки запроса.
Как проходит транзакция в сети, где есть сплетни?
Сначала запрос на обнаружение отправляется одноранговому узлу, выбранному из конфигурации соединения. Этот партнер отвечает метаданными сплетен в форме, которая может быть использована SDK. SDK использует макет, чтобы выбрать, сколько пиров от каждой организации нам нужно общаться, и мы получаем точный список пиров от групп одобряющих.
В зависимости от этого одобрения SDK случайным образом выбирает одноранговых узлов и отправляет запрос в сеть. Как только мы получим желаемые подписи, мы продолжим поток, отправив запрос в службу заказа.
Хотя обнаружение службы ограничено этим этапом, оно помогает значительно уменьшить размер наших файлов конфигурации.
Заключение
Если вы начали разработку на Hyperledger Fabric и всегда задавались вопросом, как обрабатываются транзакции, даже если цепочный код не установлен на всех узлах, или вы были поражены тем, как транзакции обрабатывались с такими небольшими конфигурациями, теперь у вас есть «под вытяжка »посмотрите, как работает система!
Надеюсь, эта статья побуждает всех разработчиков глубже понять, что происходит за кулисами, когда мы используем Hyperledger Fabric!
Слушатель событий цепного кода Hyperledger позволяет нам получать статус транзакции от однорангового узла. Это позволяет нам устанавливать пользовательские события в цепном коде вместо использования встроенных прослушивателей событие транзакции и событие блокировки. Чтобы понять, как мы можем зарегистрировать слушателей событий кода цепочки, ознакомьтесь с нашим постом.
Hyperledger Fabric - это проект, поддерживаемый Linux Foundation®, и Hyperledger является его зарегистрированным товарным знаком. Node.js является зарегистрированным товарным знаком Joyent, Inc .. DLT Labs является товарным знаком DLT Global, Inc.
Автор - Раджат Шарма, DLT Labs ™
Об авторе: Раджат - разработчик блокчейнов, который стремится понимать вещи на фундаментальном уровне. В настоящее время он работает над ElementDB, инициативой DLT Labs, направленной на объединение мощи блокчейна с простотой SQL.
