Функциональные возможности каналов

Аудитория: администраторы каналов, администраторы узлов

Примечание: это концепция продвинутого уровня в Fabric, и ее понимание не требуется от начинающих пользователей или разработчиков. Однако, по мере развития каналов и сетей, понимание и управление функциональными возможностями каналов становится важным. Более того, чрезвычайно важно отличать изменение функциональных возможностей каналов от похожего, и даже часто с ним связанного, но отличного процесса - обновления узлов. Мы опишем это подробно в ходе изложения данного раздела.

Fabric - распределенная система с множеством организаций-участников, и по этой самой причине вполне возможно (и даже чаще всего встречается), что на разных узлах сети и в разных каналах сети могут существовать разные версии кода Fabric. Это допустимо в сетях Fabric и при этом не требуется, чтобы все одноранговые узлы и узлы упорядочения имели одинаковую версию. Более того, именно поддержка различных версий позволяет проводить последовательные обновления узлов Fabric.

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

Для этих целей Fabric определяет уровни «функциональных возможностей». Они описаны в конфигурации каждого канала и обеспечивают единообразность действий и детерминированность получения согласованных результатов. Как вы увидите дальше, у функциональных возможностей есть версия, которая тесно связана с версиями бинарного кода узлов. Функциональные возможности позволяют узлам с разными версиями, производить действия совместимым и согласованным образом с учетом конфигурации канала при определенном количестве блоков в реестре. Вы также увидите, что функциональные возможности существуют в разных частях дерева конфигурации, определенные в соответствии с различными задачами администрирования.

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

Версии узлов и версии функциональных возможностей

Если вы уже знакомы с Hyperledger Fabric, то вы знакомы с тем, как указываются версии платформы: v1.1, v1.2.1, v2.0, и т.д. Эти номера относятся к версиям выпусков и соответствующим им версиям бинарного кода.

Функциональные возможности нумеруются так же. Им присваиваются номера v1.1, v1.2, затем 2.0 и так далее. Но важно отметить некоторые отличия.

• Не с каждым новым выпуском следует новый уровень функциональных возможностей. Новые функциональные возможности вводятся по мере необходимости, а необходимость почти всегда исходит из потребностей обратной совместимости новых свойств и предыдущих версий бинарного кода. К примеру, введение служб упорядочения Raft в версии 1.4.1 не повлияло на исполнение транзакций или функций службы упорядочения, и таким образом, не потребовало введения новых функциональных возможностей. Конфиденциальные данные, напротив, не могли быть использованы одноранговыми узлами в версиях ниже 1.2, что потребовало введения новых функциональных возможностей в этой версии. Из-за того, что не всякий выпуск содержит новые функции (или исправление старых ошибок), некоторые выпуски не потребуют новых функциональных возможностей (например 1.4), в то время, как в иных версиях могут быть введены новые функциональные возможности только на определенных уровнях (в таких версиях, как 1.2 и 1.3). Уровни функциональных возможностей и их место в дереве конфигурации мы обсудим позже.
• Версия узла в канале должна быть не ниже уровня версии функциональных способностей канала. Когда одноранговый узел присоединяется к каналу, он последовательно считывает все блоки реестра, начиная с первичного блока канала, и далее все блоки транзакций и последующие блоки конфигурации. Если, например, одноранговый узел, пытается считать блок, содержащий обновление функциональных возможностей, которое ему непонятно (например, одноранговый узел версии 1.4 пытается прочесть блок, содержащий функциональные возможности из версии 2.0), тогда этот одноранговый узел аварийно останавливается. Эта аварийная остановка производится преднамеренно, так как одноранговый узел версии 1.4 не должен даже пытаться валидировать или записывать транзакции в этом случае. Поэтому, перед присоединением к каналу, удостоверьтесь в том, что узел имеет версию не ниже версии функциональных возможностей, определенных в той части конфигурации канала, которая относится к этому узлу. Позже мы обсудим, к каким узлам относятся те или иные возможности. При том, что ни один пользователь не желает аварийной остановки своих узлов, мы настоятельно советуем поддерживать необходимый уровень обновлений для всех узлов (лучше всего, на уровне последнего релиза), прежде, чем пытаться обновить функциональные способности. Это общий принцип рекомендаций по умолчанию со стороны Fabric - всегда обеспечивать самую последнюю версию бинарного кода и функциональных возможностей.

Если пользователи не могут по какой-то причине обновить бинарные файлы своих узлов, тогда уровень функциональных возможностей надо оставить в соответствии с минимальной версией узлов в канале. Бинарные файлы и функциональные возможности более низких уровней будут работать вместе как положено. Но помните о том, что лучшей практикой является своевременное и постоянное обновление бинарных файлов до последнего уровня, даже если пользователь не желает обновлять функциональные возможности. Рекомендуется обновлять функциональные возможности всегда, как только бинарный код в сети это позволяет, по причине того, что новые функциональные возможности также обычно содержат и исправление ошибок кода.

Группировка конфигурации функциональных возможностей

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

• Orderer. Эти функциональные возможности управляют обработкой задач, присущих исключительно службе упорядочения. Поскольку эти функциональные возможности не включают процессы, затрагивающие транзакции или одноранговые узлы, их обновление полностью в руках администраторов службы упорядочения (одноранговые узлы не обязаны понимать функциональные возможности упорядочивания и поэтому не будут аварийно останавливаться ни при каких обновлениях функциональных возможностей упорядочения). Отметим, что эти функциональные возможности не менялись между версиями 1.1 и 1.4.2. Однако, как мы и увидим в разделе Channel, это не означает, что узлы упорядочения версии 1.1 будут работать на всех каналах с уровнем функциональных возможностей ниже 1.4.2.
• Application. Эти функциональные возможности управляют задачами, присущими исключительно одноранговым узлам. Из-за того, что администраторы службы упорядочения не могут влиять на решения относительно характера транзакций между организациями, владеющими одноранговыми узлами, изменение этих функциональных способностей - исключительное право организаций, которым принадлежат одноранговые узлы. Например, конфиденциальные данные могут быть задействованы в канале только с версии функциональных возможностей группы приложений 1.2 (и выше). В этом случае это единственная обязательная группа функциональных возможностей, которая должна быть задействована, так как для конфиденциальных данных не требуется иных изменений: ни в администрировании каналов, ни в функционировании службы упорядочения.
• Channel. В этой группе объединены задачи, администрируемые совместно организациями, владеющими одноранговыми узлами, и организациями, владеющими узлами службы упорядочения. Например, именно здесь определяется уровень функциональных возможностей, на котором обрабатываются обновления конфигурации канала, инициируемые организациями и оркеструемые службой упорядочения. На практике, в этой группе определяется минимальный уровень любого бинарного файла в канале, потому что и узлы службы упорядочения и одноранговые узлы обязаны по крайней мере на уровне бинарных файлов соответствовать этой функциональной возможности, для того, чтобы ее обрабатывать.

Функциональные возможности разделов Orderer и Channel по умолчанию наследуются из системного канала службы упорядочения, где их изменение является исключительной прерогативой администраторов службы упорядочения. В результате организации, которым принадлежат одноранговые узлы, обязаны исследовать первичный блок канала перед тем, как пытаться присоединить свои узлы к этому каналу. Несмотря на то, что функциональные возможности канала управляются администраторами службы упорядочения в системном канале службы упорядочения (ровно так же, как и членство в консорциуме), частым и ожидаемым явлением бывает то, что администраторы службы упорядочения координируются с администраторами консорциума для обеспечения того, что функциональные возможности канала обновляются только тогда, когда к этому обновлению готов консорциум.

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

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

Для обзора полной картины действительных функциональных возможностей службы упорядочения, приложения и канала в текущих версиях, смотрите образец файла configtx.yaml, в котором они содержатся списком в разделе «Capabilities».

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