简介这是一份基于Hyperledger Fabric区块链的工作流审批应用毕业设计项目面向软件工程、计科、人工智能、通信工程、自动化等计算机相关专业的在校生、教师及企业开发者可作为毕设、课设、作业或项目立项演示使用项目代码均经过测试运行成功功能完整也适合区块链方向学习者进阶。资源共163个文件压缩包约224KB包含区块链证书与密钥、前端交互页面、网络配置文件、智能合约、辅助脚本与说明文档目录结构清晰便于按模块学习或二次开发。目前已有582人学习浏览。下载即可获得完整源码、详细文档与全部配套资料可结合文档深入理解Fabric网络搭建、链码编写与审批流程实现在此基础上修改扩展快速完成高分毕设或课程设计项目对答辩展示与项目迭代均有参考价值。1. 基于 Hyperledger Fabric 的工作流审批拿到手先别急着跑把这条路走通才是高分关键做区块链方向的毕业设计最怕的不是不会写链码而是折腾两周连 Fabric 网络都起不来最后只能换个 SSM 管理系统保底。这份基于 Hyperledger Fabric 的工作流审批应用恰恰是当前毕设题里少见的“全链路能跑”的资源——它把 Fabric 网络拓扑、私钥证书、链码、前端审批界面、完整文档一次打包。你在传统 Java Web 里写的是一张审批表在这里写的是一个带背书策略、不可篡改的审批状态机导师问起架构演进、共识机制、数据隔离你都能在项目里指给他看。适合软工、计科、信安这类专业做毕设或课程设计从网络部署到业务落地只有一条主线没有绕弯的伪分布式。2. 网络骨架与加密材料先看懂 _sk 文件再决定改哪里2.1 资源里的 _sk 是什么Fabric 每个身份的“私钥命根子”把压缩包解压后你会看到一长串以_sk结尾的哈希文件名比如0d46ccf0e9436c1bc3b6e2bf80cdb202c4943604f95c72ee0ff839d3ec300719_sk。这不是摆设而是 Hyperledger Fabric 用 cryptogen 工具生成的身份私钥。每个排序节点、每个 peer、每个管理员账号都有一对密钥msp/keystore/下存私钥msp/signcerts/下存签过名的证书msp/cacerts/下存组织 CA 的根证书。我第一次打开这个资源时也愣了半天几十个以哈希命名的文件不知道该关心哪个。后来养成一个习惯先列目录看它是属于 orderer 还是 peer 组织。这些_sk文件在 Fabric 里的典型归属和用途大概是这样的文件所在路径身份用途crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/keystore/排序节点 Orderer对交易排序后签名出块crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/Org1 的 Peer 节点模拟交易、背书、维护账本crypto-config/peerOrganizations/org2.example.com/users/Adminorg2.example.com/msp/keystore/Org2 管理员部署链码、管理通道crypto-config/peerOrganizations/org1.example.com/users/User1org1.example.com/msp/keystore/Org1 普通用户调用链码发起审批这些_sk文件全部不能泄露也不能把路径改乱。起网络时 Fabric 会按 MSP 目录结构去加载私钥和证书路径错一层peer start就直接报错。这也是很多同学把项目从 Windows 拷到 Linux 后第一个翻车点后面专门讲。2.2 网络拓扑怎么看一个 Orderer、两个 Org、两个 Peer这类工作流审批毕设网络规模普遍不大但至少要能演示“多组织协同审批”——一个组织发起申请另一个组织审批交易要经过背书策略认可才写入账本。常见的拓扑是1 个排序节点 orderer.example.com2 个组织 org1.example.com 和 org2.example.com每个组织 1 个 peer 节点再加 1 个可选 CA 容器。对应到资源里就是docker-compose.yaml中那 8 到 10 个服务。理解了这个网络拓扑你再去看crypto-config.yaml就完全不懵了文件里定义的就是每个组织的域名和节点数量OrdererOrgs: - Name: Orderer Domain: example.com Specs: - Hostname: orderer PeerOrgs: - Name: Org1 Domain: org1.example.com EnableNodeOUs: true Template: Count: 1 Users: Count: 1 - Name: Org2 Domain: org2.example.com EnableNodeOUs: true Template: Count: 1 Users: Count: 1EnableNodeOUs打开后MSP 里会区分 peer、admin、client 等角色背书策略里写Org1MSP.peer才能正确匹配节点身份。Template.Count控制每个组织生成几个 peer毕设场景 1 个就够多了反而占内存。Users.Count是普通用户数量至少 1 个因为后面要用它调用链码。2.3 启动网络的正确顺序从 configtxgen 到 peer channel join很多同学一上来就docker-compose up -d然后发现 peer 容器起来了但通道没有、链码没装根本没法跑业务。正确顺序应该是先出块再建通道最后加入通道。这个资源里如果带脚本一般是start.sh或network.sh你会在里面看到这样的执行顺序export FABRIC_CFG_PATH$PWD # 1. 生成排序节点的创始块 configtxgen -profile TwoOrgsOrdererGenesis -channelID syschannel \ -outputBlock ./channel-artifacts/genesis.block # 2. 生成通道配置交易 configtxgen -profile TwoOrgsChannel -outputCreateChannelTx \ -channelID trackchannel \ -outputCreateChannelTx ./channel-artifacts/trackchannel.tx # 3. 启动网络容器 docker-compose up -d # 4. 让 peer0.org1 创建通道并加入 docker exec peer0.org1.example.com peer channel create \ -o orderer.example.com:7050 -c trackchannel \ -f /etc/hyperledger/fabric/channel-artifacts/trackchannel.tx \ --tls --cafile /etc/hyperledger/fabric/tls/tlsca.example.com-cert.pem docker exec peer0.org1.example.com peer channel join -b trackchannel.block第 2 步里的-profile TwoOrgsChannel必须和configtx.yaml中定义的 Profile 名称完全一致否则会报Could not find profile。第 4 步里-c后面的通道名我一般固定一个有意义的名字比如trackchannel后面 SDK 和链码都会用到。通道创建成功后一定要检查docker exec peer0.org2.example.com peer channel join -b trackchannel.block另一个组织的 peer 也要加入否则通道成员缺失背书策略会因为找不到第二个组织的节点而直接失败。3. 链码与审批状态机把流转规则写进账本3.1 链码语言怎么选Go 在 Fabric 里最稳Fabric 的链码支持 Go、Node.js、Java但毕设项目我强烈建议你用 Go。原因很直接Fabric 本身是 Go 写的shim接口的文档最全网上能搜到的踩坑帖八成都是 Go 链码。Node.js 链码写起来看着快但依赖fabric-chaincode-node版本和 Fabric 网络版本容易对不上实例化时各种神奇的报错让人想把电脑砸了。这份资源的链码如果从项目结构上判断一般是 Go 写的你会在chaincode/目录下看到go.mod和以.go结尾的源码。判断方法很简单打开链码目录有go.mod文件的就是 Go 链码。3.2 审批状态机怎么落三种状态加一条历史链工作流审批的核心是状态流转在传统数据库里是UPDATE t_approval SET statusapproved在 Fabric 里则是对链码状态的一次 Invoke账本上会记录一次交易。常见的设计是三种状态pending待审批、approved通过、rejected驳回外加一个doc_id作为业务主键。我一般会这样设计链码的结构package main import ( encoding/json fmt github.com/hyperledger/fabric-chaincode-go/shim pb github.com/hyperledger/fabric-protos-go/peer ) type ApprovalChaincode struct{} type ApprovalRequest struct { DocID string json:doc_id Applicant string json:applicant Approver string json:approver Status string json:status Reason string json:reason CreatedAt string json:created_at } // 发起审批状态置为 pending func (t *ApprovalChaincode) CreateRequest(stub shim.ChaincodeStubInterface, args []string) pb.Response { if len(args) ! 4 { return shim.Error(需要4个参数: docId, applicant, approver, reason) } req : ApprovalRequest{ DocID: args[0], Applicant: args[1], Approver: args[2], Status: pending, Reason: args[3], } data, _ : json.Marshal(req) err : stub.PutState(req.DocID, data) if err ! nil { return shim.Error(写入账本失败: err.Error()) } return shim.Success([]byte(审批单 req.DocID 已提交)) } // 审批动作只有状态为 pending 才能流转 func (t *ApprovalChaincode) ApproveRequest(stub shim.ChaincodeStubInterface, args []string) pb.Response { if len(args) ! 3 { return shim.Error(需要3个参数: docId, approver, 审批意见) } docID : args[0] data, err : stub.GetState(docID) if err ! nil || data nil { return shim.Error(未找到审批单: docID) } var req ApprovalRequest json.Unmarshal(data, req) if req.Status ! pending { return shim.Error(该审批单已处理不能重复操作) } req.Status approved req.Reason args[2] req.Approver args[1] updated, _ : json.Marshal(req) stub.PutState(docID, updated) return shim.Success([]byte(审批单 docID 已通过)) }参数上要注意几点PutState的 value 必须是序列化后的[]byte所以这里先用json.Marshal把结构体转成字节数组GetState返回的data可能是nil在查不到 key 时不会返回 error所以要先判断data nil。另外ApproveRequest里做了状态校验pending才能流转这样两条审批交易同时到达时不会把状态覆盖成奇怪的值。shim.Error返回的字符串会出现在 SDK 拿到的错误信息里这是我排错时最先看的地方所以错误信息里一定要带上下文不要只写error。3.3 背书策略为什么单个组织说了不算数工作流审批应用里最容易被忽略的是背书策略。Fabric 的交易要经过背书节点模拟执行结果写入账本才算数。如果你的通道背书策略是默认的AND(Org1MSP.peer)那 Org2 的审批人调用链码时交易流程其实没有经过 Org2 的节点背书这个“多组织协同”就名存实亡了。毕设里通常会在实例化链码时指定背书策略比如要求两个组织各出一个 peer 认可交易peer chaincode instantiate -o orderer.example.com:7050 \ --tls --cafile /etc/hyperledger/fabric/tls/tlsca.example.com-cert.pem \ -C trackchannel -n approvalcc \ -v 1.0 -c {Args:[]} \ -P AND(Org1MSP.peer,Org2MSP.peer)-P参数就是背书策略。AND(Org1MSP.peer,Org2MSP.peer)表示交易必须同时被 Org1 和 Org2 的 peer 认可才算合法交易。这条策略体现的是“发起与审批分离”——Org1 发起Org2 审批两边都确认了交易才上链。如果你在 SDK 里调用链码时只连接了 Org1 的节点而另一个组织的 peer 没加入通道或没装链码就会频繁报背书失败这时第一反应应该是查 Org2 的 peer 状态而不是改代码。4. 工作流业务链路从前端表单到账本回执4.1 发起审批SDK 提交事务的正确姿势链码只是跑在 Fabric 里的智能合约外边还得有应用去调它。毕设项目里一般用fabric-sdk-node或fabric-gateway写前端后端对接。我比较推荐用fabric-network这个 npm 包它封装好了连接、事务提交、事件监听你只需要准备一个连接配置文件一般是connection.json和钱包目录。发起审批时前端把表单数据提交到后端后端通过 SDK 调用链码的CreateRequestconst { Gateway, Wallets } require(fabric-network); const path require(path); const fs require(fs); async function submitApproval(docId, applicant, approver, reason) { const wallet await Wallets.newFileSystemWallet(./wallet); const gateway new Gateway(); const connectionProfile JSON.parse( fs.readFileSync(./connection.json, utf8) ); // asLocalhost: true 表示连接本地的 Fabric 网络 await gateway.connect(connectionProfile, { wallet, identity: admin, discovery: { enabled: true, asLocalhost: true } }); const network await gateway.getNetwork(trackchannel); const contract network.getContract(approvalcc); // submitTransaction 会走完“背书 → 排序 → 上账本”全流程 await contract.submitTransaction( CreateRequest, docId, applicant, approver, reason ); await gateway.disconnect(); }discovery.enabled设为true后SDK 会自动发现通道里的所有 peer省去手工配置每个节点地址。asLocalhost: true是因为这套网络跑在本地 Docker 容器里节点的域名映射到 127.0.0.1。提交事务用submitTransaction它和只读的evaluateTransaction关键区别在于前者真的会往账本写数据后者只做查询。如果把写操作放在evaluateTransaction里不会报错但账本上不会有任何记录这种坑很隐蔽。4.2 审批操作查询走 evaluate写库走 submit审批人收到待办后先要查当前的状态和申请理由。这个查询动作应该走只读路径async function queryApproval(docId) { const network await gateway.getNetwork(trackchannel); const contract network.getContract(approvalcc); // evaluateTransaction 不产生区块只返回当前状态 const result await contract.evaluateTransaction(QueryRequest, docId); return JSON.parse(result.toString()); }而审批人点击“通过”按钮时走的还是submitTransaction调用ApproveRequest。同一个链码函数读和写必须严格区分调用方式。我记得有一次调试时把两者混用查询和写入都提交了事务结果账本里多了一堆空的区块peer 高度还莫名涨了后来才发现是submitTransaction在只读函数上的副作用。4.3 附件和数据怎么存哈希上链文件留链下工作流审批里免不了有佐证材料比如报销单的 PDF、请假条的附件。如果直接把文件二进制写进链码的PutState每个区块会迅速膨胀性能急剧下降而且 Fabric 本身不适合存大文件。我一般这样切分数据类型存储位置原因审批单 ID、申请人、审批人、状态、时间链码状态数据库需要共享、可追溯、不可篡改附件文件本体链下文件服务器或本地磁盘区块链不适合存大文件附件哈希值SHA-256链码状态里对应的字段用哈希验证附件是否被换过在CreateRequest的入参里加一个file_hash字段存附件的 SHA-256。审批时用相同的算法再算一次比对哈希是否一致——链上存的是凭证链下存的是内容两边能对上就说明材料是原封不动的。这个设计在答辩时讲出来非常加分因为它体现你对区块链存储边界的理解。5. 避坑这套 Fabric 项目最常见的 5 个翻车现场5.1 peer 容器起不来MSP 路径指错了层现象docker logs peer0.org1.example.com显示Error: failed to load MSP: msp folder does not exist但明明 crypto-config 目录里确实有 msp 文件夹。原因peer 环境变量CORE_PEER_MSPCONFIGPATH指到了.../msp/keystore这一层Fabric 期望的是包含keystore、signcerts、cacerts的完整 msp 目录。路径深了一层或浅了一层都加载不到合法的 MSP。解决把路径指到当前身份的 msp 根目录比如crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp。不要自作聪明指到keystore文件夹里。这个路径由 docker-compose 里挂载的 volume 决定检查volumes部分即可。5.2 链码实例化永远 pendingGo 依赖没有 vendor现象链码 install 成功但 instantiate 之后一直处于instantiate任务 pending 状态容器一直在重启日志里是Error: chaincode registration failed。原因Go 链码的go.mod没有拉齐依赖网络环境里go mod download失败导致链码容器里缺少 shim 包。Fabric 的链码容器是独立镜像它编译链码时需要联网拉依赖国内环境经常在这一步卡住。解决提前在链码目录执行GO111MODULEon go mod vendor把依赖打包进vendor/目录同时把链码目录挂载进容器。这样容器启动时不需要联网直接用本地 vendor 编译。从那以后我每次写链码都会把 vendor 提交进项目避免环境差异。5.3 背书策略不匹配invoke 直接 500现象SDK 调用submitTransaction时报Error: endorsement failure during invoke. chaincode result: nil有时错误信息还会带上MSP error。原因通道的背书策略要求两个组织都背书但 Org2 的 peer 没有加入通道或者加入了通道但没有安装链码。背书节点集合不满足策略要求交易直接被拒。解决先docker exec peer0.org2.example.com peer channel list看它是否在通道里再去peer lifecycle chaincode queryinstalled确认链码已安装。两个组织必须同步做完 join 和 install缺一个都不行。5.4 CouchDB 状态库导致 peer 内存暴涨现象网络跑了两天peer 容器内存占用超过 2G操作一多直接容器被 kill。资源里如果docker-compose的 peer 部分配了CouchDB的 environment多半是这个引起的。原因Fabric 的 peer 默认用 LevelDB如果配置成 CouchDB每个区块写入时都要更新 JSON 索引数据量大了之后内存和 CPU 开销明显。解决毕设场景没有复杂的富查询需求把CORE_LEDGER_STATE_STATEDATABASE改回goleveldb并去掉couchdb容器内存立刻降下来。如果确实需要用 CouchDB 做按字段查询给 peer 容器加mem_limit: 1g别让它裸奔。5.5 Windows 解压后私钥文件权限丢失现象从 Windows 上解压的_sk文件拷到 Linux 后peer start或 SDK 连接时报permission denied或Failed to initialize crypto。原因Windows 解压的文件默认没有保留 Unix 权限_sk文件变成-rw-r--r--Fabric 缺省要求敏感文件不能被 group 和 other 读否则拒绝加载。解决进入crypto-config目录执行chmod -R 755 crypto-config重点检查keystore下的私钥文件再用chmod 600 xxx_sk把私钥权限收紧。这一步不做后面所有容器都会卡在证书初始化上。6. 进阶验证用区块浏览器和哈希校验证明你的链“不可篡改”6.1 把账本“可视化”Explorer 怎么接进这套网络答辩的时候光靠命令行查状态不够直观。给项目接一个 Hyperledger Explorer 是加分操作它能把每个区块、每笔交易以图形化页面展示出来鼠标一点就能看到审批单从pending到approved的全过程记录。Explorer 需要一个配置文件告诉它你的网络连接信息orderer地址、peer 地址、组织 MSP 和 admin 证书路径。通常你只需要把资源里的 crypto-config 路径填进 Explorer 的config.json再启动explorer-docker-compose.yaml里的容器访问 8080 端口即可。配置时注意把channel名改成你的trackchannel否则 Explorer 找不到账本。6.2 一个自测技巧重启网络后验证区块哈希连续性想快速证明 Fabric “不可篡改”不是说说的可以做这个实验先记录当前通道的区块高度和最新区块哈希然后关掉 peer 容器再重启用peer channel getinfo对比重启前后的区块哈希。如果账本被人为篡改过后续区块的previous_hash就会对不上。换作传统数据库重启后没法用这种哈希链来证明数据完整性。具体操作是在peer0.org1.example.com容器里执行peer channel getinfo -c trackchannel它会输出类似Block height: 10, Block hash: 0x...的信息。连续执行两次高度在涨、前一区块哈希与当前区块哈希严格衔接就说明账本在按预期写入。答辩现场做这一步比空谈“区块链不可篡改”有力得多。6.3 从单机到多机至少把 Orderer 单独拉出去手头资源跑通后如果你想再往前一步把单机多容器变成真正意义上的多机部署最低成本的改法是把 orderer 容器单独放到一台云服务器上两个 peer 分别放在另外两台机器把 docker-compose 里的hostname和extra_hosts改成对方机器的公网 IPTLS 证书重新签发一遍。这一步做完你就能理直气壮地说自己做过分布式部署了。从那以后我每次拿到一个 Fabric 项目压缩包不再急着跑业务而是强制自己先走一遍“看 crypto-config → 启动网络 → 查 channel info → 对比区块哈希”的流程。网络和账本验证通过才轮到调前端界面。这套习惯帮我避开了九成以上的低级翻车。这个项目的代码和文档都齐值得按这个顺序完整复现一遍希望帮到你。本文还有配套的精品资源点击获取