全称Membership service provider。至于概念官方给出的过于抽象,我这里说说我个人的浅显的理解。
我理解中的MSP是一个模块,专门提供用户账号注册的服务。各个网络组件都需要向MSP注册,所得到注册文件就在对应的msp目录下。所以我对msp目录下的文件都理解为该msp目录所有者的账号,其中包括证书和秘钥对。
凡是以pem结尾的文件都是证书文件。
以**_sk**结尾的文件都是私钥文件。
锚节点的本质就是peer节点。之前我讲过,网络中包括很多组织,每个组织中又有许多个peer节点。那么不同组织之间相互是怎么通信的呢?
每个组织中选择一个peer节点来代表该组织与其他组织通信。这个被选择的节点就是锚节点。
那么锚节点是怎么被选出的呢?
答:在配置文件中可以指定某个peer节点为锚节点。一个组织内的任意一个节点都有资格作为锚节点,但是一个组织中最多只能有一个锚节点。
这个二级标题听起来可能有点绕,我再重新解释一下。创世块和通道的创建需要依赖对应的文件A和B,但是A和B文件的创建又依赖于一个C文件。这里我要讲解一下这个C文件的编写。我的妈呀,说的累死我了!
当然这个文件我们还是去改,而不是重新写。先找到模板,其路径是:hyperledger-fabric/fabric-samples/first-network/configtx.yaml
注:hyperledger-fabric路径就是在部署Fabric环境时创建的用来下载Fabric的引导脚本的那个路径。详情可见我之前的帖子《Michael.W谈hyperledger Fabric第1期-环境搭建》中的第6部分。
复制这个文件到当前网络的配置路径下:
$ cp /home/michael.w/hyperledger-fabric/fabric-samples/first-network/configtx.yaml ~/test/
注意:修改复制这个文件之后,可以修改其内容但是不要改名字。因为修改了名字后,在终端中输入的命令就找不到这个文件了。
打开configtx.yaml文件,可见这样一种语法:
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
OrdererOrg前面有个取地址符&,这个就相当于定义了一个变量。这个变量的值就是他后面接的由Name、ID和MSPDir三个键组成的map。如果我们在这个文件中使用了变量OrdererOrg就相当于直接写了其后面的map。
那如何使用这种类型的变量,很简单在该变量名称前加星号,即*OrdererOrg就相当于后面的这个map。
为什么要使用这种语法?
答:使得你的配置文件可以看起来更加精简。许多重复的部分都可以用一个变量来表示。
回想一下前面我设计了多少个组织?应该是三个:orderer组织,peer组织1和peer组织2。
来看一下configtx.yaml文件里关于配置组织这部分都做了什么?
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations: # 表示组织的关键字 不能修改
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg # 新语法,一个变量来表示后面map,是配置文件变得精简
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg # 你设定的orderer组织的名字,自定义
# ID to load the MSP definition as
ID: OrdererMSP # 你设定的orderer组织的ID,自定义
# MSPDir is the filesystem path which contains the MSP configuration
MSPDir: crypto-config/ordererOrganizations/example.com/msp # 当前orderer组织的证书路径。这是前面生成Fabirc网络中组件证书中对应的路径
- &Org1 # 表示peer组织1的变量,可自定义
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP # peer组织1的名称,可自定义
# ID to load the MSP definition as
ID: Org1MSP # peer组织1的ID
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp # peer组织1的证书路径
AnchorPeers: # 表示peer组织1的锚节点的关键字,不可修改
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.org1.example.com # 锚节点的域名。从当前peer组织1 中随便选择一个peer节点作为锚节点。其实就是被选择的那个peer节点的域名!
Port: 7051 # peer组织1运行在容器中,这个容器需要开放一个端口与宿主机映射。这样就可以跟外界通信了。7051是锚节点容器默认开放的端口。
- &Org2 # peer组织2的相关信息,和peer组织1一样。如果你创建的网络还有更多的组织,就按照这个模板往下复制即可。
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org2MSP
# ID to load the MSP definition as
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.org2.example.com
Port: 7051
注:在配置Name选项时要不要跟前面生成证书的时候设定的组织名保持一致呢?并不用。因为前面只是生成对应组织的证书文件,而创始区块和通道是要创建在容器中。所以这些证书文件是需要以数据卷挂载的方式被映射进对应容器中。只要到时候你把这些文件路径的映射关系弄清楚就可以。
还有需要注意一点:Name和ID是可以一样的!
关于上面提到的组织的证书路径,有些朋友可能还是弄不清楚,我截了一张图,看了你就清晰了:
简单地讲,msp文件夹在哪个组件下面就是哪个组件的证书路径。
我改后的对应部分:
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/michael.com/msp # 这个地方使用的是相对路径。也就是说需要保证你修改的configtx.yaml文件要和生成证书时自动生成的crypto-config文件夹在同一级目录中。如果文件存储的位置不同,这个地方的路径也需要根据对应的情况来修改。
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.michael.com/msp
AnchorPeers:
- Host: peer0.org1.michael.com # 组织中的peer0节点作为锚节点
Port: 7051
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.michael.com/msp
AnchorPeers:
- Host: peer0.org2.michael.com # 组织中的peer0节点作为锚节点
Port: 7051
################################################################################
#
# SECTION: Capabilities
#
# - This section defines the capabilities of fabric network. This is a new
# concept as of v1.1.0 and should not be utilized in mixed networks with
# v1.0.x peers and orderers. Capabilities define features which must be
# present in a fabric binary for that binary to safely participate in the
# fabric network. For instance, if a new MSP type is added, newer binaries
# might recognize and validate the signatures from this type, while older
# binaries without this support would be unable to validate those
# transactions. This could lead to different versions of the fabric binaries
# having different world states. Instead, defining a capability for a channel
# informs those binaries without this capability that they must cease
# processing transactions until they have been upgraded. For v1.0.x if any
# capabilities are defined (including a map with all capabilities turned off)
# then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both. Set the value of the capability to true to require it.
Global: &ChannelCapabilities
# V1.1 for Global is a catchall flag for behavior which has been
# determined to be desired for all orderers and peers running v1.0.x,
# but the modification of which would cause incompatibilities. Users
# should leave this flag set to true.
V1_1: true
# Orderer capabilities apply only to the orderers, and may be safely
# manipulated without concern for upgrading peers. Set the value of the
# capability to true to require it.
Orderer: &OrdererCapabilities
# V1.1 for Order is a catchall flag for behavior which has been
# determined to be desired for all orderers running v1.0.x, but the
# modification of which would cause incompatibilities. Users should
# leave this flag set to true.
V1_1: true
# Application capabilities apply only to the peer network, and may be safely
# manipulated without concern for upgrading orderers. Set the value of the
# capability to true to require it.
Application: &ApplicationCapabilities
# V1.2 for Application is a catchall flag for behavior which has been
# determined to be desired for all peers running v1.0.x, but the
# modification of which would cause incompatibilities. Users should
# leave this flag set to true.
V1_2: true
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations: #这个地方是空的,我也不做修改。空着就好!
这里面最核心的就是键Global、Orderer和Application下对应的版本兼容性。由于版本的升级,Fabric加入了许多新的模块。为了更好地兼容之前的老版本,即让新版本的节点加入到网络后可以跟老版本创建出来的节点正常进行通信,所以在这里需要做一个兼容性的设置。
我全按照默认的来,都设置成true。后面的Application就让它空着吧,不做修改。
周所周知,Fabric中是没有矿工这个角色的。对应的相关职责由orderer节点调用排序服务器来代替。
先读一下模板的配置:
################################################################################
#
# SECTION: Orderer
#
# - This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults # 变量名,可自定义
# Orderer Type: The orderer implementation to start
# Available types are "solo" and "kafka"
OrdererType: solo # 共识机制(排序算法),目前Fabric中只给出来两种:solo和kafka。
# solo:常用于测试,效率低。
# kafka:分布式排序服务器,用于真实环境,效率高。
Addresses: # orderer节点的域名。7050为orderer节点默认开放的端口。
- orderer.example.com:7050
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 2s # 每隔多长时间生成一个区块
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 10 # 区块消息的最大值,即当区块中的消息等于该值时,orderer节点将这些数据打包
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB # 当区块中的数据大小大于等于该值时,orderer节点将这些数据打包。
# 一些资料上说,区块大小设置为32m就好,最大不要超过64m。
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 KB # 建议给出的区块体积的最大值,给开发者一个参考值。
Kafka: # 关于kafka分布式排序服务器的设置。当上面的OrdererType不设置为kafka时,该设置不生效。
# Brokers: A list of Kafka brokers to which the orderer connects
# NOTE: Use IP:port notation
Brokers:
- 127.0.0.1:9092
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations: # 默认是空的
BatchTimeout、MaxMessageCount和AbsoluteMaxBytes是直接影响orderer节点打包区块的条件。那么这三个条件之间的关系是怎样的?
正确答案是属于或
的关系。即有一个条件达到,就打包区块。
根据上面的解读,我的配置修改如下:
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.michael.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 32 MB # 当区块内数据大小大于等于32MB时,orderer节点开始打包。
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
ps:
本人热爱图灵,热爱中本聪,热爱V神,热爱一切被梨花照过的姑娘。
以下是我个人的公众号,如果有技术问题可以关注我的公众号来跟我交流。
同时我也会在这个公众号上每周更新我的原创文章,喜欢的小伙伴或者老伙计可以支持一下!
如果需要转发,麻烦注明作者。十分感谢!
公众号名称:后现代泼痞浪漫主义奠基人