> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/blockchain_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/blockchain_guide/10_fabric_op/best_practice.md).

# 注意事项与最佳实践

区块链分布式结构的特点，使得其在管理上相对单点系统要复杂的多，需要从多个角度进行仔细考量和论证。这里总结一些在生产环境中使用 Fabric 网络需要注意的地方和最佳实践技巧。

## 节点角色差异

Fabric 网络中各个节点可以拥有不同的角色。不同角色的众多节点负责整个网络功能中不同环节的工作负载，呈现出了差异化的处理特性。

Ordering 服务需要排序整个网络中所有的交易消息，是全网的关键组件。Orderer 维护网络中所有通道的区块链结构，往往大量吞吐区块文件。因此，对于 Orderer 节点来讲需要加强网络（至少千兆网络）、存储和内存方面的配置，并且采用集群部署的方式提高其可靠性。

Peer 节点除了处理区块和背书交易（Endorser）之外，还需要对账本状态进行更新（Committer），对身份进行验证。同时，对于每个通道来说，加入通道的节点都需要维护一个针对该通道的账本结构（存放在数据库中）和区块链结构（存放在文件系统）。因此，Peer 节点需要加强CPU、内存、存储等资源配置，Endorser 还可以在签名处理方面进行加权。对于打开文件句柄较多的节点（如配置使用 CouchDB 作为状态数据库时），可能还需要对系统的 ulimit 等参数进行调整。

而对于链码容器来说，自身不需要维护太多状态信息，但是需要执行计算操作，因此需要提供较好的计算能力支持。

一般来讲，链码容器常常跟 Peer 节点在同一服务器上，建议为 Peer 服务预留 2 GB 以上的空闲内存，4 CPU 以上资源，并且一般每个链码容器分配 256 MB 运行内存和 1/10 的 CPU 核资源（根据链码逻辑进行调整）。

## 日志级别

日志级别越低，输出日志内容越详细，出现问题后方便进行调试。但输出过多日志会拖慢系统的吞吐性能，严重时甚至能降低几个数量级。

因此，在生产环境中必须要仔细调整日志级别。对于关键路径上的系统，通常要配置不低于 Warning 级别的日志输出；对于非关键路径上的系统，则可以采用不低于 Info 级别的日志输出。

Fabric 在日志级别上，支持对不同组件提供不同的级别。推荐将全局配置为 warning 级别，gRPC 组件由于需要处理大量交互消息，可以配置为更高的 error 级别。

如果要追踪区块链网络中的状态变化，可以通过事件监听等方式，降低对网络处理的压力。

## 链码升级

在 Fabric 2.x 的链码生命周期（Lifecycle）下，升级链码本质上是更新链码定义：递增序列号（`--sequence`）、更新版本号并重新打包安装后，由各相关组织重新批准（approve），在满足通道的生命周期背书策略（默认为大多数组织，Majority）后，由任一组织提交（commit）生效。详见“[管理链上代码（Lifecycle）](/blockchain_guide/10_fabric_op/chaincode_v2.md)”一节。

与 1.x 旧 LSCC 机制不同，升级需要组织间达成共识；一旦新定义提交成功，便在通道范围内统一生效，而非由单个管理员单方面操作，也不会出现部分节点新旧版本并存的情况。

从数据一致性上考虑，新版本链码应能够正确读取旧版本写入的状态数据，避免数据结构不兼容导致读写错误。建议先在测试网络或个别组织上，用新版本（递增 `--sequence`）验证对原有数据的读写，确认无误后再在生产通道上推进批准与提交。

大多数现代链码无需显式的 Init 方法；如确有初始化需求，可在 approve 与 commit 时指定 `--init-required`，并在提交后用 `--isInit` 调用一次以保护原有数据。

## 组织结构

组织代表了维护网络的独立成员身份。一般来说，组成联盟链的各个成员，每个都拥有代表自己身份的组织。一个组织可以进一步包括多个资源实体，这些资源实体彼此具有较强的信任度，并且对外都呈现为同一组织身份。

由于 Gossip 协议目前在 MSP 范围内进行传播，因此，一般建议将组织与 MSP 一一对应，即每个组织拥有自己专属的 MSP。当一个组织拥有多个 MSP 时，不同成员之间的交互可能会带来障碍；当多个组织同属于一个 MSP 时，可能会发生不希望的跨组织的数据泄露。

另外，一个组织可以包括多个成员身份，多个 Peer 可以通过使用同一成员身份来提高高可用性。

## 证书管理

Fabric 网络中，CA 负责证书的管理。`cryptogen` 主要用于测试和开发环境中快速生成网络密钥材料，通常不应作为生产网络的证书签发和生命周期管理工具。生产网络应由各组织运营 Fabric CA 或符合企业安全要求的外部 PKI/中间 CA，用于注册、签发、轮换和吊销节点、管理员、客户端等身份。

Fabric CA 占据网络中安全和隐私的最核心位置，因此需要加强安全方面的防护。CA 不应该暴露在公共网络域中，并且只能由有限个具备权限的用户可以访问。

另外，根证书往往要进行离线保护处理，减少接触和泄露的可能性。通常使用中间层证书来完成实体证书的签发。同时，绝对不能直接用根证书作为组织管理员的身份证书。

## 账本备份和裁剪

Fabric 2.3 之后支持 Peer 账本快照（ledger snapshot），可用于让新 Peer 从某一高度加入通道，或在多个 Peer 间比较快照哈希以检查是否存在账本分叉。但快照不是完整备份，也不会对已加入通道的 Peer 执行账本归档或裁剪。

一方面，推荐用户根据业务需求和吞吐量来估算所需磁盘的大小。一般的，在平均每秒百次 TPS、交易消息不太大情况下，每年大约产生 3 TB 左右数据。生产环境应为区块文件、状态数据库、私有数据、历史数据库和快照目录分别规划容量和告警阈值。

账本文件一般位于默认的 `/var/hyperledger/production` 目录下，包括区块文件、状态数据库、私有数据存储、历史数据库和节点本地元数据。不要手动删除活跃 Peer 的旧区块文件来“裁剪”账本；这会破坏后续的 `reset`、`rollback`、`rebuild-dbs` 等管理操作，并可能导致节点无法一致恢复。

快照目录只包含加入通道所需的最小数据，例如公开状态、私有数据哈希、交易 ID 和集合配置历史；不包含私有数据明文、完整区块历史、MSP、节点配置或运行时数据库文件。因此：

* 快照可以压缩、分发给新 Peer，或用于一致性校验；
* 快照不能替代 Peer 完整备份，也不能作为回滚到历史高度的机制；
* 通过快照加入通道的 Peer 不具备完整历史区块，不能使用依赖完整区块文件的 `reset`、`rollback` 或 `rebuild-dbs` 命令；
* 私有数据需要在加入后从有权限的集合成员 Peer 中重新协调拉取，可能需要额外时间；
* Fabric 2.5 的私有数据 purge 只处理私有数据状态和历史，不等同于公开账本裁剪。

完整备份应在一致性窗口内覆盖 Peer 文件系统、状态数据库（如 CouchDB）、私有数据、MSP、TLS 材料和配置文件，并在恢复演练中验证节点能重新加入网络、同步区块、查询账本和处理链码调用。

## 系统优化

区块链作为分布式系统，对系统的计算、网络、存储等资源都有所需求，优化的系统配置可以有效提高资源效率。

例如，可以调整系统缓存策略、允许打开的文件句柄数、调整 TCP 连接超时时间等网络参数等。如果使用容器，还可以调整容器的资源限额和访问权限等。

此外，对于第三方软件也应该根据对应文档进行调整和优化。例如使用 CouchDB 作为状态数据库时，应单独规划认证、网络隔离、备份和容量告警。仍使用 Kafka 排序服务的旧 Fabric 2.x 网络，应先迁移到 Raft，再考虑升级到 Fabric 3.x。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/blockchain_guide/10_fabric_op/best_practice.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.