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

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

Примечание: это концепция продвинутого уровня в 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 - всегда обеспечивать самую последнюю версию бинарного кода и функциональных возможностей.

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

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

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

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

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

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

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

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

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

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

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