Fabric1.4 kafka共识的多orderer集群 1.排序节点介绍 2.部署基于kafka的排序节点

本节内容基于前几节介绍的hellowrold区块链环境基础,实现基于kafka模式的排序节点部署和测试。

Fabric 的共识模型是Execute-Order-Validate,即先执行再排序最后验证的过程。
在创建区块链创世块以及通道的时候我们会用到一个configtx.yaml文件,该配置文件中的Orderer配置信息中有一个OrdererType参数,
该参数可配置为”solo” and “kafka”,之前例子我们使用的配置皆是solo,即单节点共识。

使用kafka集群作为orderer共识的技术方式可以为排序服务提供足够的容错空间,当客户端向peer节点提交Transaction的时候,
peer节点会得到一个读写集结果,该结果会发送给orderer节点进行共识和排序,此时如果orderer节点突然down掉,
将导致请求服务失效、数据丢失等问题。

因此,在生产环境部署Fabric,往往需要采用具有容错能力的orderer,即kafka模式,使用kafka模式搭建orderer节点集群需要会依赖于kafka和zookeeper。

1.1.排序执行过程

一个交易的生命周期包括下面几个步骤:

  • client先向peer提交一个题案进行备案;
  • peer执行智能合约,调用数据执行操作,peer将操作结果发送给orderer;
  • orderer将收到的所有的题案排序,打包成区块,并发送给Peer;
  • Peer打开每个区块,并进行验证,若验证通过,则写入本地账本,更新世界状态。向client发送event告知交易被提交到账本中。

1.2.Atomic Broadcast(Total Order):

客户端提交交易信息 –> orderers:将交易排序并打包成块 –> 各个账本写入全局有序的区块

1.2.1 全局排序要求:

  • 全局唯一、容错(cft、bft)
  • 网络分区(分区出去的节点的限制)
  • 强一致性
  • bft(fabric v1.4 的orderer是cft,并不代表fabric是cft)

1.2.2 Block Cutting(打包规则):

BatchSize:批次大小

MaxMessageCount:最大消息数量
AbsoluteMaxBytes :限制单个交易大小,超过该限制,会被拒绝掉
PreferredMaxBytes :综合可能超过PreferredMaxBytes,假设PreferredMaxBytes=200b,前9个交易大小为100b,第10个交易大小为200b,这时会把第10个交易一块打包,这样就会大于PreferredMaxBytes。

BatchTimeout

Timeout 按照时间规则打包

2.部署基于kafka的排序节点

我们将部署三个Oraderer节点,
基于前几节的helloworld案例按以下步骤重新修改配置文件,重新部署区块链网络。

步骤1. 修改crypto-config.yaml,添加OrdererOrgs 的Specs

Specs:
  - Hostname: orderer
  - Hostname: orderer2
  - Hostname: orderer3 

crypto-config.yaml完整配置文件如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: example.com
EnableNodeOUs: true
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
- Hostname: orderer2
- Hostname: orderer3

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org1
# ---------------------------------------------------------------------------
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Specs:
- Hostname: peer0
- Hostname: peer1
- Hostname: peer2
- Hostname: peer3
- Hostname: peer4
# ---------------------------------------------------------------------------
# "Specs"
# ---------------------------------------------------------------------------
# Uncomment this section to enable the explicit definition of hosts in your
# configuration. Most users will want to use Template, below
#
# Specs is an array of Spec entries. Each Spec entry consists of two fields:
# - Hostname: (Required) The desired hostname, sans the domain.
# - CommonName: (Optional) Specifies the template or explicit override for
# the CN. By default, this is the template:
#
# "{{.Hostname}}.{{.Domain}}"
#
# which obtains its values from the Spec.Hostname and
# Org.Domain, respectively.
# ---------------------------------------------------------------------------
# Specs:
# - Hostname: foo # implicitly "foo.org1.example.com"
# CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
# - Hostname: bar
# - Hostname: baz
# ---------------------------------------------------------------------------
# "Template"
# ---------------------------------------------------------------------------
# Allows for the definition of 1 or more hosts that are created sequentially
# from a template. By default, this looks like "peer%d" from 0 to Count-1.
# You may override the number of nodes (Count), the starting index (Start)
# or the template used to construct the name (Hostname).
#
# Note: Template and Specs are not mutually exclusive. You may define both
# sections and the aggregate nodes will be created for you. Take care with
# name collisions
# ---------------------------------------------------------------------------
Template:
Count: 3
# Start: 5
# Hostname: {{.Prefix}}{{.Index}} # default
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
Users:
Count: 1
# ---------------------------------------------------------------------------
# Org2: See "Org1" for full specification
# ---------------------------------------------------------------------------
- Name: Org2
Domain: org2.example.com
EnableNodeOUs: true
Specs:
- Hostname: peer0
- Hostname: peer1
- Hostname: peer2
- Hostname: peer3
- Hostname: peer4
Template:
Count: 3
Users:
Count: 1

步骤2. 执行生成证书文件

cryptogen generate --config=./crypto-config.yaml

执行后可见crypto-config/orderOrganizations/example.com/orderers目录下出现了三个组织的证书:

orderer.example.com
orderer2.example.com
orderer3.example.com

步骤3. 修改configtx.yaml配置文件

将OrdererType设置为kafka 并配置打包规则和kafka地址

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Orderer: &OrdererDefaults

# Orderer Type: The orderer implementation to start
# Available types are "solo" and "kafka"
OrdererType: kafka

Addresses:
- orderer.example.com:7050
- orderer2.example.com:7050
- orderer3.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

# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB

# 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:
# Brokers: A list of Kafka brokers to which the orderer connects
# NOTE: Use IP:port notation
Brokers:
- kafka1:9092
- kafka2:9092
- kafka3:9092
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:

完整的configtx.yaml配置文件如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243