> 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。