距离上一篇文章发布差不多 1 个月了吧，这个月没有闲着，也是干了一些 Besu 区块链相关的活。后续找个时间跟大家分享一下。那么紧接着 Geth 我们继续回归到 Besu，深入聊一下 Besu 本身到底是什么、它的组件怎么分工、这些组件在一次真实请求里怎么串起来。
PS：我重新回看了一下之前的分享，好像并没有深入去聊过这部分的内容。这次就彻彻底底将这部分跟大家讲透了。
我不讲 QBFT 的协议细节，也不把 Solidity 的 ABI 展开到代码级......那些我会留到后面的专题里单独写。这里我想先把"Besu 的骨架"讲清楚，这样后面不管看 RPC、监控、合约，还是排障，都不会散。
1. "分层系统" VS "一个节点程序"
我第一次认真理解 Besu 的时候，最大的收获不是"它能出块"，而是意识到它其实更像一个分层系统：
- 上层 -> API、监控和插件
- 中间 -> P2P 网络和交易池
- 底层 -> 执行与状态管理
一些互联网社区把它的主要能力拆成了 EVM、P2P networking、Storage、Permissioning、Privacy、User-facing API 和 Monitoring。而官方文档则进一步说明，Besu 的对外能力包括 CLI、JSON-RPC、WebSocket、Pub/Sub 和 GraphQL。
也就是说，我们平时看到的 RPC 接口，只是这个系统对外露出的那一层。在本质上 Besu 不是单纯一个执行引擎，而是一个可以被观察、被调试、被集成的运行平台。
2. 执行层、网络层、接口层、观察层
如果把 Besu 的结构压缩成四层，我会这样记：
- 执行层负责算账，它对应的是 EVM 和状态更新；
- 网络层负责找人和传消息，它对应的是节点之间的 P2P 通信；
- 接口层负责给外部系统递交能力，它包括 JSON-RPC、WS、IPC、GraphQL 和 Pub/Sub；
- 观察层负责告诉我它有没有出问题，它则是 metrics、block explorer 和插件输出。
这四层结构的好处是，我排障时不会一股脑地怀疑"链坏了"。比如节点连不上，我先看网络层；交易发出去了但没结果，我再看接口层和交易池；状态读错了，我再看执行层和存储层；如果系统表现正常但我拿不到业务需要的数据，我就去看插件层和监控层。
这个思路比"只盯着区块高度"更有用。我们可以通过 web3_clientVersion、net_peerCount、eth_blockNumber 这三个最小接口，把节点的版本、连通性和链头推进情况拆开检查。
3. 不是只有 RPC
Besu 的 API 层不止 JSON-RPC。
官方文档明确列出了三条常用入口：JSON-RPC over HTTP / WebSocket/IPC、RPC Pub/Sub over WebSocket/IPC、以及 GraphQL over HTTP。这意味着不同类型的调用应该走不同的通道：请求 <-> 响应型操作适合 HTTP，事件订阅适合 WebSocket 或 IPC，结构化查询适合 GraphQL。
另一个很关键的点是，eth_subscribe 和 eth_unsubscribe 这类订阅方法不能走 HTTP，只能走 WebSocket 或 IPC。
这层里还有几个特别容易忽略的安全细节。
Besu 默认把 API 服务监听在 127.0.0.1，如果你把 host 改成 0.0.0.0，它就会对远程连接开放。官方文档明确提醒，这会把接口暴露给外部网络，所以生产环境必须配防火墙或其他网络隔离。
此外，Besu 还提供 host allowlist，但官方也说了，这不是权限控制机制；真正要限制 API 访问，应该使用认证机制，或者把服务放在带 TLS 终止和访问控制的网络层后面。
默认端口也值得我记住：HTTP JSON-RPC 是 8545，WebSocket JSON-RPC 是 8546，GraphQL 是 8547。这个看似琐碎，但在实际部署和排障里很有用，因为很多问题最后都只是"端口开错了"或者"服务挂在了错误的监听地址上"。
4. Besu 不替你管私钥
Besu 不在客户端内部做密钥管理，如果要给交易签名，通常会配合 Web3Signer 之类的外部签名服务。这个设计其实很符合企业环境的思路：节点负责执行和验证，私钥交给独立的签名器或 HSM/KMS 去管，职责边界更清楚，也更容易做权限隔离。对我来说，这一点非常重要，因为它直接决定了我会不会把"节点主机"和"签名权"混在一起部署。
这也解释了为什么 Besu 的可用性并不只取决于节点本身，而是取决于它周边是否有一套完整的签名、认证和访问控制系统。
5. 链数据和世界状态是两回事
LimeChain 有一篇文章将 Besu 的存储描述得很直观：它使用键值数据库保存本地链数据，而且这些数据被分成两类------ blockchain data 和 world state data。这点我特别认同，因为很多初学者会把"区块数据"和"状态数据"混成一件事，最后排障时分不清自己到底是在查区块、查数据，还是查状态。
Besu 官方文档也对此进行了强调：世界状态可以用 Forest of Tries 或 Bonsai Tries 存储，而且 Besu 默认使用 Bonsai。对于非 FULL 模式，很多历史世界状态并不可用，若使用非全量同步或修剪策略，某些依赖历史状态的 JSON-RPC 方法可能返回 null。
这是一件特别容易被忽略的事，大多数人查询时上遇到空结果，第一反应是"RPC 坏了"。其实应该先想想是不是当前同步/存储模式不保留历史状态啦。
此外还有一点需要注意的，CPU 压力通常在同步时最高，随后会下降。不同同步模式和存储格式会显著影响磁盘占用和同步时长。这个知识点我后面会说到：存储结构不是背景板，它直接决定同步速度、历史可查性和磁盘成本。
6. Besu 的"扩展总线"
Besu 的插件机制是我很喜欢的一点。
官方文档说，Besu 支持用 Java 扩展插件，也可以使用已有的开源插件。而插件 API 能拿到 blocks、balances、transactions、smart contracts、execution results、logs 和 syncing state 的数据。更关键的是，插件有明确生命周期：注册、启动、停止。这对我来说意味着 Besu 不只是"能跑"，它还天然支持把内部事件向外部系统流出。我可以把监控、审计、索引、事件分发等任务从节点核心里拆出去，用插件或者外部消费者接走，这样节点就不会被业务逻辑拖得太重。
7. 请求处理流程
- 我发起一次请求，应用先通过 JSON-RPC、WebSocket 或 GraphQL 进入 Besu 的 API 层（如果是订阅类事件，就必须走 WebSocket 或 IPC，而不是 HTTP）。
- Besu 在接到请求后，会先做 host allowlist 检查，再根据配置决定是否允许认证请求通过（认证则可以走用户名/密码或 JWT 两种方式之一）。
- 请求通过之后，Besu 才会把它交给内部执行和状态组件去处理，最后再把结果通过 receipt、日志、事件或查询接口返回给外部。
这个链路我会记成一句话：外部请求先过门，再进接口，再进执行，最后回到状态和观测层。
如果哪一步出问题，定位也就对应地往回查：认证失败先看鉴权，收不到事件先看 WS/IPC，结果不对先看执行和存储，完全没变化再看 P2P 和同步。
8. 总结
如果只用一句话概括 Besu，我会说它不是一个"单一节点程序"，而是一套围绕 Ethereum 执行、通信、暴露接口、观测和扩展建立起来的 Java 客户端系统。
最后给大家分享一下我的 Besu 故障排查清单：
- 先确认 Besu 版本和 API 是否真的打开。
- 再查 peerCount 和 blockNumber，判断网络和链头是否正常。
- 如果是订阅类需求，只走 WebSocket / IPC，不走 HTTP。
- 如果外部系统连不上，先检查 host allowlist、监听地址和端口。
- 如果交易相关问题排不掉，再看鉴权、签名器和外部钱包。
- 如果历史查询失败，先判断是不是当前存储/同步模式不保留那段状态。
- 如果还不清楚，就把问题拆成"接口、执行、存储、网络"四层分别查。