HyperLedger Fabric开发实战 -Kafka集群部署
133 浏览量
2021-01-20
13:43:53
上传
评论
收藏 381KB PDF 举报
HyperLedger Fabric开发实战开发实战 -Kafka集群部署集群部署
第第5章章 Kafka集群部署集群部署
根据前面章节的介绍，知道了Fabric组网过程的第一步是需要生成证书等文件，而这些默认配置信息的生成依赖于configtx.yaml及crypto-config.yaml配置文件。
在采用Kafka作为启动过类型的Fabric网络中，configtx.yaml 及 cryto-config.yaml配置文件依然有着重要的地位，但是其中的配置样本与先前的内容会有些不同。
本章将进行基于Kafka集群的部署，其中重要的概念是对前三章的总结，也是对本章及后续章节关于智能合约及CouchDB的铺垫。
5.1 Fabric账本账本
账本 （Ledger）
即所有的状态变更是有序且不可篡改的。状态变更是由参与方提交的chaincode(智能合约)调用事务（transactions）的结果。每个事务都将产生一组资产键-值对，这些键-值对用
于创建、更新或删除而提交给账本。
账本由BlockChain（区块链）组成，区块则用来存储有序且不可篡改的记录，以及保存当前状态的状态数据库。在每一个Channel中都会存在一个账本。每一个Peer都会维护它
作为其中成员的每一个Channel中的本地复制的账本。
链
链是一个事务日志，是一个由Hash链接各个区块的结构，其中每个区块都包含了N个事务的序列。
区块header包含了该区块的事务的Hash，以及上一个区块头的Hash。这样，所有在账本上的交易都是按顺序排列的，并以密码方式链接在一起。也就是说在不破坏Hash 链接的
情况下篡改账本数据是不可能的。最近的区块Hash代表了以前的每个事务，从而确保所有的Peers都处于一致和可信的状态。
链存储Peer文件系统（本地或附件存储）上，有效的支持BlockChain工作负载的应用程序的特性。
状态数据库
该账本的当前状态数据表示链事务日志中包含的所有值的最新值。
由于当前状态表示Channel所知道的全部最新键值，因此有时称为“World State”。
在Chaincode调用对当前状态数据执行操作的事务时，为了使这些Chaincode交互非常有效，所有的键的最新值都存储在一个状态数据库中。状态数据库只是一个索引视图到链的
事务日志，因此可以在任何时候从链中重新生成。在事务被接受之前，状态数据库将自动恢复或者在需要时生成。
状态数据库包括LevelDB 和 CouchDB 。 LevelDB 是嵌入在Peer进程中的默认状态数据库，并将Chaincode数据存储为键-值对。CouchDB是一个可选的外部状态数据库，所写的
Chaincode数据被建模为JSON时，它提供了额外的查询支持，允许对JSON内容进行丰富的查询。
事务流
在高层业务逻辑处理上，事务流是由应用程序客户端发送的事务协议，该协议最终发送到指定的背书节点。
背书节点会验证客户端的签名，并执行一个Chaincode函数来模拟事务。最终返回给客户端的是Chaincode结果，即一组在Chaincode读集中获取的键值版本，以及在Chaincode
写集中写入的键值集合，返回该Peer执行Chaincode后模拟出来的读写集结果，同时还会附带一个背书签名。
客户端将背书组合成一个事务payload,并将其广播至一个ordering service （排序服务节点），ordering service 为当前Channel 上的所有Peers 提供排序服务并生成区块。
实际上，客户端在将事务广播到排序服务之前，先将本次请求提交到Peer ,由Peer验证事务。
首先，Peer将检查背书策略，以确保指定的Peer的正确分配已经签署了结果，并且将根据事务payload对签名进行身份验证。
其次，Peer 将对事务集进行版本控制 ， 以确保数据完整性 ， 并防止诸如重复开销之类问题。
5.2 事务处理流程事务处理流程
此处将介绍在标准资产交换过程中发生的事务机制。这个场景包括两个客户，A和B，他们在购买和销售萝卜（产品）。他们每个人在网络上都已一个Peer，通过这个网络，他们
发送自己的交易，并与Ledger(账本)进行交互，如下图所示：
假设这个事务流中有一个Channel被设置并运行。应用程序客户端及该组织的证书颁发机构均已注册，并获得了必要的加密资料，用于对网络进行身份验证。
Chaincode（包含一组表示萝卜市场的初始状态的键值对）被安装在Peers上，并在Channel上实例化。Chaincode包含定义一组事务指令的逻辑，以及一个萝卜（商品）的价
格。该Chaincode也确定一个背书策略，即peerA和peerB都必须支持任何交易。
完整具体处理流程如下：完整具体处理流程如下：
5.3 Kafka集群配置集群配置
搭建Kafka集群的最小单位组成如下：
3个Zookeeper节点集群
4个Kafka节点集群
3个Orderer排序服务节点
其他Peer节点
以上集群至少需要10个服务节点提供集群服务，其余节点用于背书验证、提交及数据同步。
准备工作：
名称名称 IP hostname 组织机构组织机构
Zk1 172.31.159.137 zookeeper1
Zk2 172.31.159.135 zookeeper2
Zk3 172.31.159.136 zookeeper3
Kafka1 172.31.159.133 kafka1
Kafka2 172.31.159.132 kafka2
Kafka3 172.31.159.134 kafka3
Kafka4 172.31.159.131 kafka4
Orderer0 172.31.159.130 orderer0.example.com
Orderer1 172.31.143.22 orderer1.example.com
Orderer2 172.31.143.23 orderer2.example.com
peer0 172.31.159.129 peer0.org1.example.com Org1
peer1 172.31.143.21 peer1.org2.example.com Org2
如果考虑到高可用性，可以学习参考K8s管理Docker的方案。
在这些服务器中，每一台都会安装Docker、Docker-Compose环境，而Orderer排序服务器及Peer节点服务器会额外的安装Go及Fabric环境。
剩余14页未读，继续阅读
评论0