简介本资源是一套基于SpringBoot构建的区块链农产品溯源系统采用多系统微服务架构面向计算机专业学生、Java开发者及需要完成溯源类毕业设计或课程项目的学习者帮助解决农产品从生产到流通环节的数据可信存证与全链路追溯问题。压缩包共1370个文件约15.73MB涵盖255个Java后端源码、86个Vue前端页面、251个JavaScript脚本、110个WXML与109个WXSS小程序页面以及98个PEM证书、34个CRT证书和17个KEY密钥文件配合JSON配置、SQL脚本与YAML部署文件完整呈现区块链网络搭建与微服务拆分结构。资源中另含Go语言链码、Shell启动脚本及Docker相关配置便于理解Fabric网络与业务系统的对接方式。目前已有459人学习下载适合作为微服务与区块链结合的实战参考帮助读者掌握溯源业务建模、链码调用与前后端联调思路。1. 农产品溯源为什么非要上区块链和微服务一个被问烂但值得说清的问题做过农产品溯源的人都知道这行的核心矛盾从来不是能不能记录而是记录之后谁信。传统做法是建一个中心化数据库种植信息、加工记录、物流节点全塞进去查询时从库里捞出来展示。问题在于这个库的 owner 是谁如果 owner 是平台方那平台改一条数据比改 Excel 还容易如果 owner 是监管方那企业又担心商业数据被看光。消费者扫码看到的那条山东寿光 3 月 12 日采摘到底有没有被改过没人能自证。区块链在这里解决的不是性能问题而是信任归属问题。数据上链后哈希值串成链改一条就得改后面所有块成本高到没人愿意干。但光有链不够——链上只存哈希原始数据还得有地方放业务逻辑还得有人跑。这就是微服务出场的地方农产品溯源涉及种植、加工、质检、仓储、物流、销售至少六个环节每个环节的数据结构、访问频率、权限模型都不一样硬塞进一个单体应用里改一个质检字段可能把物流模块搞崩。拆成微服务各管各的库各发各的事件链上只做存证和校验这才是能落地的架构。这套SpringBoot 微服务 区块链存证的组合适合两类人一是做农业信息化项目的团队手里有真实溯源需求但不知道怎么把链和业务揉在一起二是学微服务架构的开发者想找一个有实际业务约束不是电商秒杀那种烂大街场景的项目练手。下面从架构拆解开始一步步说清楚怎么跑起来、怎么改、哪里容易翻车。2. 微服务拆分与区块链存证的分层设计六个服务怎么切、链上存什么2.1 为什么按业务环节拆而不是按技术层拆很多教程讲微服务拆分上来就是用户服务、订单服务、商品服务这是电商思维。农产品溯源的业务链路是线性的种植 → 加工 → 质检 → 仓储 → 物流 → 销售。每个环节的参与方不同、数据字段不同、上链时机也不同。按技术层拆比如所有实体一个服务、所有查询一个服务会导致一个致命问题质检环节要改一个字段得同时动三个服务的代码。我一般会按业务环节拆成六个核心服务外加两个基础服务服务名职责是否上链数据库planting-service种植记录、地块信息、农药使用是MySQLprocessing-service加工批次、工艺参数、产出物是MySQLquality-service质检报告、合格证、检测项是MySQLwarehouse-service入库出库、库存、温湿度是MySQLlogistics-service运输节点、承运商、签收是MySQLsales-service销售终端、批次拆分、消费者查询否查链MySQL Redisblockchain-service统一上链接口、哈希计算、链交互—链上 MySQL 索引gateway-service路由、鉴权、限流—Redis关键设计blockchain-service 是唯一跟链打交道的服务其他服务不直接调链。这样做的好处是链的 SDK 升级、节点切换、Gas 策略调整只影响一个服务。坏处是它可能成为瓶颈所以这个服务要做异步化——业务服务发消息到 MQblockchain-service 消费后上链上链结果再回写业务库的 tx_hash 字段。2.2 链上到底存什么哈希、时间戳和最小必要字段新手最容易犯的错是把整条业务记录 JSON 序列化后直接上链。一条种植记录可能 2KB一天一万条就是 20MB一年下来链上数据膨胀到不可维护。正确做法是只存关键字段的哈希// blockchain-service 中的上链数据构建 public class TraceHashBuilder { /** * 构建上链哈希只取业务关键字段 * param bizType 业务类型PLANTING/PROCESSING/QUALITY... * param bizId 业务主键 * param coreFields 核心字段 Map顺序必须固定 */ public static String buildHash(String bizType, String bizId, LinkedHashMapString, String coreFields) { // 用 LinkedHashMap 保证字段顺序一致否则同样数据哈希不同 StringBuilder sb new StringBuilder(); sb.append(bizType).append(|).append(bizId); for (Map.EntryString, String entry : coreFields.entrySet()) { sb.append(|).append(entry.getKey()).append().append(entry.getValue()); } // SHA-256 输出 64 位十六进制 return DigestUtils.sha256Hex(sb.toString()); } }逻辑说明哈希输入必须确定性——同样的业务数据每次算出来必须一样。所以用 LinkedHashMap 固定字段顺序用|做分隔符避免字段值拼接歧义。参数方面bizType 和 bizId 参与哈希是为了防止不同业务类型的相同数据产生碰撞。coreFields 只放不可变的关键字段比如种植环节放地块编号、采摘日期、农药名称不放备注、操作人姓名这类可能变更的字段。上链时实际写入链的是{bizType, bizId, hash, timestamp, operator}。查询时从链上取 hash再从业务库取原始数据重新算 hash比对一致就说明没被篡改。这个链上存哈希、链下存原文的模式是行业标准做法别自己发明新花样。2.3 服务间通信同步 Feign 还是异步 MQ六个业务服务之间有没有直接调用有但很少。比如 sales-service 查询某批次时需要聚合种植、加工、质检的信息。如果同步调六个服务任何一个超时都会拖垮查询。我的做法是写操作走 MQ 异步读操作走聚合层。# application.yml 中 RabbitMQ 配置片段 spring: rabbitmq: host: ${MQ_HOST:localhost} port: 5672 username: ${MQ_USER:guest} password: ${MQ_PASS:guest} publisher-confirm-type: correlated # 开启发送确认 publisher-returns: true # 开启失败返回 listener: simple: acknowledge-mode: manual # 手动 ACK防止消息丢失 prefetch: 10 # 每个消费者预取 10 条参数说明publisher-confirm-type: correlated让每条消息有唯一确认回调配合publisher-returns: true可以在消息路由失败时拿到返回。acknowledge-mode: manual是关键——自动 ACK 在消费者处理到一半崩溃时会丢消息溯源数据丢一条就是事故。prefetch: 10控制消费者积压太大容易内存溢出太小吞吐上不去10 是实测比较稳的值。写操作的流程是业务服务写本地库 → 发消息到trace.exchange→ blockchain-service 消费 → 上链 → 回写 tx_hash。如果上链失败消息进死信队列人工介入。读操作则由 sales-service 直接查各服务的只读副本或 Redis 缓存不走链。3. 本地跑通最小闭环从数据库初始化到链上存证验证3.1 数据库初始化与微服务启动顺序拿到源码包后第一步不是急着mvn spring-boot:run而是先把数据库和中间件准备好。这套系统依赖 MySQL 8.0、Redis 7、RabbitMQ 3.12以及一个区块链节点通常是 FISCO BCOS 或 Hyperledger Fabric 的单机版。# 1. 创建各服务数据库源码包中通常有 init.sql mysql -uroot -p sql/init_all.sql # 2. 启动 Redis 和 RabbitMQ假设用 Docker docker run -d --name trace-redis -p 6379:6379 redis:7-alpine docker run -d --name trace-mq -p 5672:5672 -p 15672:15672 rabbitmq:3.12-management # 3. 启动区块链节点以 FISCO BCOS 单机为例具体看源码包内 build_chain.sh bash blockchain/build_chain.sh -l 127.0.0.1:1 -p 30300,20200,8545启动顺序有讲究先 MySQL → 再 Redis/RabbitMQ → 再区块链节点 → 最后启动微服务。如果先启动微服务Nacos 注册成功但数据库连不上服务会反复重启日志刷得看不清错误。我一般会写一个start-all.sh按依赖顺序拉起。#!/bin/bash # start-all.sh 按依赖顺序启动 services(gateway-service blockchain-service planting-service processing-service quality-service warehouse-service logistics-service sales-service) for svc in ${services[]}; do echo Starting $svc... nohup java -jar ${svc}/target/${svc}-1.0.0.jar \ --spring.profiles.activedev logs/${svc}.log 21 sleep 8 # 等待注册到 Nacos donesleep 8不是随便写的——SpringBoot 服务启动到注册完成通常 5-7 秒gateway 需要等所有下游注册后才能正确路由。如果机器慢加到 15 秒。3.2 用一条种植记录验证上链全流程服务全部起来后别急着打开前端。先用 curl 打一条种植记录看整条链路通不通。# 1. 登录获取 tokengateway 统一鉴权 TOKEN$(curl -s -X POST http://localhost:8080/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123} | jq -r .data.token) # 2. 提交种植记录 curl -X POST http://localhost:8080/api/planting/record \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d { plotId: SD-SG-001, cropName: 西红柿, plantDate: 2026-03-01, harvestDate: 2026-05-20, pesticide: 生物制剂A, operator: 张工 } # 3. 查询上链结果等 3 秒让 MQ 消费完 sleep 3 curl -s http://localhost:8080/api/blockchain/tx/PLANTING/12345 \ -H Authorization: Bearer $TOKEN | jq预期返回里应该有txHash、blockNumber、status: CONFIRMED。如果status一直是PENDING去查 blockchain-service 的日志大概率是链节点没连上或者合约地址配错了。3.3 验证数据未被篡改手动改库再查链这是最能说明区块链价值的测试。直接改数据库里那条种植记录的harvest_date然后调校验接口-- 手动篡改把采摘日期从 5-20 改成 5-15 UPDATE planting_record SET harvest_date 2026-05-15 WHERE id 12345;# 调校验接口 curl -s http://localhost:8080/api/blockchain/verify/PLANTING/12345 \ -H Authorization: Bearer $TOKEN | jq返回应该是{valid: false, reason: HASH_MISMATCH, onChainHash: a3f2..., localHash: b7c1...}。如果返回valid: true说明校验逻辑写错了——常见错误是校验时用了数据库当前值重新算哈希而不是用上链时的快照。正确做法是业务表里要存一份snapshot_json字段记录上链那一刻的原始数据。4. 避坑与排查链上存证和微服务联调中最容易翻车的五件事4.1 哈希对不上字段顺序和空值处理现象同样的数据上链时算的哈希和校验时算的哈希不一致校验永远失败。原因Java 的 HashMap 不保证顺序如果构建哈希时用了 HashMap两次遍历顺序可能不同。另外字段值为 null 时有的代码拼成keynull有的直接跳过导致哈希输入不同。解决统一用 LinkedHashMap并且约定 null 值统一转成空字符串参与哈希。在TraceHashBuilder里加一行String.valueOf(value)兜底。4.2 微服务循环依赖planting 调 qualityquality 又调 planting现象服务启动时报BeanCurrentlyInCreationException或者 Feign 调用时死循环。原因拆服务时没画清楚依赖方向。种植环节需要质检结果才能出库质检又需要种植批次信息两个服务互相调。解决引入事件驱动。planting 完成种植后发PlantingCompletedEventquality 监听后生成质检任务质检完成后发QualityPassedEventwarehouse 监听后允许入库。服务之间不直接调用只通过 MQ 通信。如果必须同步查把查询逻辑下沉到 gateway 的聚合层。4.3 链上交易确认慢导致接口超时现象提交种植记录后前端一直转圈最后报 504。原因区块链交易从发送到确认需要出块时间FISCO BCOS 默认 1 秒一个块但网络拥堵时可能 5-10 秒。如果业务接口同步等上链结果必然超时。解决业务接口只负责写库和发 MQ立即返回tx_hash为 null 的记录。前端拿到记录 ID 后轮询/api/blockchain/tx/{bizType}/{bizId}查上链状态。轮询间隔建议 2 秒最多 30 秒超时提示存证排队中。4.4 Nacos 注册成功但网关路由 404现象服务列表里能看到所有服务但通过 gateway 访问一直 404。原因gateway 的路由配置里uri写的是lb://planting-service但服务注册到 Nacos 时的服务名是planting-service-dev带了 profile 后缀。解决统一服务名规范spring.application.name不要带 profile 后缀profile 通过spring.profiles.active区分。或者在 gateway 路由里用lb://planting-service并确保 Nacos 里的服务名完全一致。4.5 数据库时区导致上链时间戳偏差 8 小时现象链上记录的时间戳和业务库的时间差 8 小时校验时如果时间参与哈希就会失败。原因MySQL 连接串没指定时区JVM 默认时区是 UTCMySQL 是 CST写入和读取差 8 小时。解决JDBC URL 加serverTimezoneAsia/ShanghaiJVM 启动参数加-Duser.timezoneAsia/Shanghai。如果时间字段参与哈希统一用 UTC 时间戳毫秒数而不是格式化字符串。5. 进阶技巧用 Merkle 树批量存证把 Gas 成本压下来单条上链的写法在测试环境没问题但真实场景一天几千条记录每条都发一笔交易链的吞吐和成本都扛不住。我后来改成批量存证blockchain-service 每 10 秒或每 100 条攒一批构建 Merkle 树只把根哈希上链。// MerkleTreeBuilder批量构建 Merkle 根 public class MerkleTreeBuilder { /** * param hashes 单条记录的哈希列表 * return Merkle 根哈希 */ public static String buildRoot(ListString hashes) { if (hashes.isEmpty()) return ; ListString currentLevel new ArrayList(hashes); while (currentLevel.size() 1) { ListString nextLevel new ArrayList(); for (int i 0; i currentLevel.size(); i 2) { String left currentLevel.get(i); // 奇数个节点时最后一个自己和自己配对 String right (i 1 currentLevel.size()) ? currentLevel.get(i 1) : left; // 拼接后哈希注意顺序不能反 nextLevel.add(DigestUtils.sha256Hex(left right)); } currentLevel nextLevel; } return currentLevel.get(0); } }逻辑说明Merkle 树的核心是两两配对哈希奇数个节点时最后一个复制自己。这样一批 100 条记录只需要存一个根哈希上链成本降到 1/100。验证时单条记录只需要提供从叶子到根的路径哈希Merkle Proof就能证明这条记录在这批里。参数方面批量大小建议 50-200 条。太小省不了多少成本太大验证路径变长。10 秒的攒批窗口是经验值——再长用户等不及再短攒不够量。验证 Merkle Proof 的接口这样写public boolean verifyProof(String leafHash, ListString proof, String root, int index) { String computed leafHash; for (String sibling : proof) { // index 的奇偶决定当前节点是左还是右 if (index % 2 0) { computed DigestUtils.sha256Hex(computed sibling); } else { computed DigestUtils.sha256Hex(sibling computed); } index / 2; } return computed.equals(root); }index参数是关键——它记录叶子在原始列表中的位置决定每一步是拼在左边还是右边。这个 index 在构建树时就要存下来跟 proof 一起返回给验证方。我踩过的一个坑早期为了省事把 proof 和 index 存在业务库里结果业务库被改了 proof 也跟着变验证就失去意义。正确做法是 proof 和 index 在构建 Merkle 树时生成存到独立的存证表这张表只允许 blockchain-service 写入其他服务只读。这套方案跑下来单机 FISCO BCOS 四节点TPS 稳定在 800-1000 左右对于农产品溯源这种日增几千条的场景完全够用。如果真要上生产链节点至少四个机构各跑一个共识算法用 PBFT别用 Solo——Solo 出块虽然快但一个节点挂了整条链就停溯源系统停摆的后果比性能差严重得多。希望帮到你。本文还有配套的精品资源点击获取