注意事项与最佳实践

区块链分布式结构的特点，使得其在管理上相对单点系统要复杂的多，需要从多个角度进行仔细考量和论证。这里总结一些在生产环境中使用 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 目前已经支持了链码升级特性，升级时会调用链码中的 Init 方法。通过合适地设计链码，对其进行升级操作可以保护旧版本链码所关联的状态数据不被破坏。

但是注意目前升级操作并不需要整个网络的共识，因此对部分节点上链码版本升级后，未被升级的节点上仍然会运行旧版本的链码。

从数据一致性上考虑，在对某链码代码进行升级前，推荐先将所有该链码的容器停止，并从 Peer 上备份并移除旧链码部署文件。之后先在个别 Peer 节点上部署新链码，对原有数据进行测试，成功后再在其它节点上进行升级操作。

另外，在一开始编写链码过程中，就需要考虑链码升级操作，通过传入 Init 参数指定特定的升级方法来保护原有数据。

组织结构

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

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

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

证书管理

Fabric 网络中，CA 负责证书的管理。用户虽然可以通过 cryptogen 工具提前分配好各组织的身份证书，但对于加入到网络中的用户，以及未来支持的交易证书，都需要 Fabric CA 来进行统一管理。

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

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

账本备份和裁剪

目前，Fabric 自身并未考虑对账本结构的备份和裁剪操作。在生产环境中，需要用户自己进行处理。

一方面，推荐用户根据业务需求和吞吐量来估算所需磁盘的大小。一般的，在平均每秒百次 TPS、交易消息不太大情况下，每年大约产生 3 TB 左右数据。

账本文件一般位于默认的 /var/hyperledger/production 目录下，包括区块链结构（文件存储）和相关状态（数据库存储）。大部分操作只与数据库存储相关，因此，对于旧的区块链文件，可以考虑从本地移除，备份到容量更大的持久化存储中。当需要时，再从大容量存储中恢复到本地。

系统优化

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

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

此外，对于第三方软件也应该根据对应文档进行调整和优化。例如使用 Kafka 共识机制，在 Kafka 2.0 版本默认保留日志时间为 7 天，应当调整为更长，但同时注意要预留足够的系统存储空间。