区块链系统部署运维实践文档 | FISCO BCOS¶

FISCO-BCOS 是一个稳定、高效、安全的区块链底层平台，经过多家机构、多个应用，长时间在生产环境运行的实际检验。

FISCO-BCOS 系统部署运维实践文档是一份针对 FISCO-BCOS 区块链平台运维的指引手册，是对 FISCO-BCOS 官方文档的整理和补充。

文档的结构按照区块链运维 部署前，部署以及 后期运维 的三个阶段进行组织，对每一阶段进行了概括和整理，列出每个阶段不同的操作方式，具体操作流程。

重要

该指引文档只适用 FISCO-BCOS 2.0+
该指引文档对应 FISCO-BCOS 版本请参考: 文档版本
区块链运维会使用到基于 FISCO-BCOS 的中间件平台 WeBASE，关于 WeBASE 的相关介绍，请参考：什么是 WeBASE？

文档介绍¶

该文档是一份 FISCO-BCOS 区块链运维的指引手册，主要分为下面几个部分：

部署前准备
- 部署前的准备工作
部署
- 多种部署方式
- 部署操作指引
后期运维
- 区块链系统运维中，常用的运维操作
附录
- 依赖软件安装

重要

建议按照文档的结构顺序，逐一阅读，并注意仔细阅读文档中的 <提示> 部分。

认识区块链¶

区块链是由多个学科交叉组合形成的一门技术，涉及到网络，密码学，证书，分布式系统等相关知识。建议在进行部署之前，学习一些区块链的基础知识，了解一些基本概念。如果您已经对这些基本技术很熟悉，可以跳过。

文档版本¶

文档版本	对应 FISCO-BCOS 版本
v1.0.0	v2.7.x

环境准备¶

环境准备是 FISCO-BCOS 运维中的第一部分，主要是运行 FISCO-BCOS 操作系统（Linux）的一些操作和说明，同时，也会对所需的硬件资源进行说明。

环境准备主要包括：

操作要求和规范¶

FISCO-BCOS 的节点是运行在 Linux 操作系统中，通过设定统一的操作要求和规范，可以尽最大程度减少线上人为操作失误，降低操作风险的同时，提升线上系统的安全性和稳定性。

文件操作¶

文件变动操作，比如 mv，vim，rm，尽量先备份，后修改
使用 rm 时必须再三确认，同时禁止使用 rm -rf $FILE/
重要文件添加不可更改位 chattr +/- i filename
使用 crontab 定时备份重要文件和数据
禁止使用 FTP 传输文件，使用 SFTP（scp）代替

服务¶

防火墙屏蔽无用端口，只开放 SSH 和必要的应用端口
- 如果使用云服务，推荐使用云服务安全组功能
SSH 服务禁用密码登录，改用密钥登录方式，并且由专人管理密钥

网络¶

只有需要外网连接的服务，才能监听回环地址 0.0.0.0 上，否则都监听 127.0.0.1

系统¶

由 root 分发不同的权限给对应用户，然后禁用 root，尽量不使用 root 启动服务。非必要情况下，以非 root 用户登录进行操作
监控服务器的状态，CPU，内存，磁盘，网络的使用量，如果使用量达到 80%，需要进行评估或者反馈
生产环境尽量使用自动工具或者脚本，减少人为操作，降低人为操作的风险
定期给系统打补丁，防止系统被漏洞攻击

重要

针对 rm 操作，推荐使用 safe-rm 工具，参考：safe-rm

硬件要求¶

预估硬件资源¶

开发（体验）环境¶

对于开发（体验）环境，请参考：推荐配置中开发（体验）环境推荐的配置。

提示

开发（体验）环境一般使用开发工具中的一键脚本 build_chain.sh 在单台主机部署 4 个节点和一个 WeBASE-Front 服务。具体操作，请参考：开发工具部署

生产环境¶

生成环境作为正式提供对外服务的环境，需要在上线前对整体容量量进行一个预估。根据容量预估的结果，来预估部署时需要的硬件资源。包括，主机数量，主机配置（CPU，磁盘，内存），网络带宽等等。

重要

对部署所需要的硬件资源进行一个合理的预估，不仅能够提高硬件资源的利用率，还能提高运行环境的稳定性
在部署生产环境之前，如果没有对预期环境做合理的容量评价，那么应用上线后，可能会出现大量的计算资源和存储资源闲置，造成资源利用率低；相反，还可能会出现流量过载，造成服务器高负载，服务崩溃，延迟高，用户体验差等问题

提示

为了减少成本，一台机器只部署一条链的一个节点，一台机器可以部署多条链的一个节点

容量预估¶

容量是指系统可处理容纳的最大能力，包括：

需要的区块链数量
每条链的用户量
每条链的交易量，每笔交易的平均大小，交易的流量大小
每条链的 TPS
每条链的 QPS

在做容量预估时，如果有现有流量数据，那么可以参考现有流量数据来进行预估；如果没有，那么可以根据具体的业务场景、业务类型、流量入口的数据、引流渠道等来估算容量的大小。

性能参考数据¶

影响区块链性能的指标因素很多，包括：

硬件处理能力
- 包括 CPU 主频、CPU 核心数、内存大小、磁盘 IO、带宽速率等
部署情况
- 受参与共识的节点数量影响，通常共识节点数量增多性能会有所下降
算法
- 包括共识机制、网络分发、压缩、编解码、加解密、签名验签等密码学算法
系统参数
- 业务逻辑本身的复杂程度，通常表现为业务智能合约的复杂度，合约逻辑更复杂导致计算需要更多资源，性能也会更低；

下面列出 腾讯云服务器 配置环境下的两组 FISCO-BCOS 性能测试数据：

测试服务器配置

选项	参数
服务器类型	腾讯云虚拟机
CPU	Intel(R) Xeon(R) CPU E5-26xx v4 （8 核）
内存	16GB
硬盘	高速云硬盘，IOPS 上限 6000，读写吞吐上限 150MB/s
网卡	千兆网卡
操作系统	CentOS 7.3

测试环境数据

配置	描述
FISCO-BCOS 版本	FISCO BCOS V2.7.0
MySQL 版本	5.5.64-MariaDB
主机数量	*4 台主机，单链，4 节点（满足 3 n + 1）**
测试工具	Caliper
测试业务	转账

测试结果数据 1：固定节点测试

密码算法	合约引擎	存储引擎	用户量	交易量	QPS	TPS
非国密	Solidity	Rocksdb	1W	100w	10000	9616
非国密	预编译	Rocksdb	1W	100w	18000	14543
非国密	Solidity	Mysql	1W	100w	6000	5800
非国密	预编译	Mysql	1W	100w	8000	8553
国密	Solidity	Rocksdb	1W	100w	8000	6281
国密	预编译	Rocksdb	1W	100w	9000	7183

测试结果数据 2：多群组交易测试数据

多群组交易测试环境配置

国密算法、Solidity 合约、RocksDB 引擎，PBFT 共识机制
交易大小：1.48 KB；出块间隔：1s；每个区块最大交易数量：6000；交易池上限：150 0000

群组	用户量/群组	交易量/群组	TPS/群组	QPS/群组	CPU%	内存%	带宽Mbps
4 节点 1 群组	10000	500000	5924	8000	720	6	In: 35 Out: 34
4 节点 4 群组	10000	500000	1364	2000	750	28	In: 42 Out: 32
4 节点 8 群组	10000	200000	629	1000	780	32	In: 42 Out: 32
4 节点 16 群组	10000	100000	261	500	790	38	In: 42 Out: 31
4 节点 32 群组	10000	50000	129	300	790	61	In: 48 Out: 30
4 节点 64 群组	10000	20000	43	100	790	86	In: 38 Out: 25

磁盘类型¶

重要

区块链的应用中，会存在同步大量链数据的场景，特别是一台主机上部署多条链的节点（一条链一个节点），此时对硬盘的性能要求相对会比较高。所以，在进行硬件资源评估之前，一定要选择合适的磁盘类型。

下图是腾讯云的的磁盘类型及性能：

磁盘类型	随机 IOPS	吞吐量（MB/s）	时延
增强型 SSD	最大随机 IOPS = 1800 + 存储容量（GB）× 50 且最大随机 IOPS 不超过50000	最大吞吐量 = 120 + 存储容量（GB）× 0.5 且最大吞吐量不超过350MB/s	0.3 - 1ms
SSD	最大随机 IOPS = 1800 + 存储容量（GB）× 30 且最大随机 IOPS 不超过26000	最大吞吐量 = 120 + 存储容量（GB）× 0.2 且最大吞吐量不超过260MB/s	0.5 - 3ms
高性能	最大随机 IOPS = 1800 + 存储容量（GB）× 8 且最大随机 IOPS 不超过6000	最大吞吐量 = 100 + 存储容量（GB）× 0.15 且最大吞吐量不超过150MB/s	0.8 - 4ms

提示

推荐至少使用高性能磁盘（吞吐量 150MB/s 左右）；如果交易量很小，可以考虑使用普通云磁盘；

重要

在运维监控时，也要多注意磁盘的 IO 指标；
如果使用云服务，或者平台服务，尽量使用云磁盘存放部署时生成的节点配置文件和区块链的数据文件（配置文件目录中的 data 和 log 目录），防止主机销毁而导致数据跟随系统磁盘丢失；

预估硬件资源¶

完成容量预估后，参考压测数据和推荐配置中生产环境推荐的配置，预估所需要的硬件资源：

机器配置
- CPU 核心数；
- 内存大小；
- 硬盘类型（IO 性能），硬盘大小；
机器数量
- 机构的节点数量，可以根据机构的权重来分配；
- 每个机构至少有 2 个共识节点；
- 由多个机构组成群组时，每个群组共识的节点数量至少为：3 * n + 1（ n 表示系统可容错的节点数目，为大于等于 1 的整数）。由于共识节点自身消耗和数量呈线性相关，所以共识节点的数量不是越多越好，推荐 n 的值为 1，2 即可；
- 每个机构适当添加观察节点，数量根据机构情况来定；
网络带宽

初始化系统环境¶

这一小节主要包括操作系统的版本要求，系统环境的初始配置以及依赖软件的安装。

提示

关于系统环境的初始配置，推荐使用 虚拟机镜像 的方式，创建自定义镜像后，通过相同的镜像初始化系统，屏蔽线上环境的系统差异；

操作系统要求¶

当前支持的操作系统以及要求最低版本：

‌操作系统	‌最低版本	‌使用 WeBASE-Docker 时最低版本
‌CentOS/RHEL（推荐）	‌7.2+	‌7.3+
‌Ubuntu	‌16.04+	16.04 (LTS)

检查系统环境¶

检查网络性能¶

在配置主机环境之前，需要先测试一下网络的连通性（IP，端口），链路以及丢包率，确保节点之间能互相访问，防止因为网络问题降低区块链集群的整体性能。

具体操作：

ping [ip]
- 把 [ip] 替换成目标 IP 地址。比如，另外一个节点的外网 IP 地址
telnet [ip] [port]
- 把 [ip] 替换成目标 IP 地址，[port] 可以使用 SSH 端口，默认 22
mtr -rwc 20 -i 0.2 [ip]
- 把 [ip] 替换成目标 IP 地址。比如，另外一个节点的外网 IP 地址
- 如果系统提示 mtr 命令不存在，使用 yum/apt-get install -y mtr

提示

如果主机是购买的云服务，需要给主机增加一个外网 IP（或者动态 IP），同时需要注意配置云服务提供的 安全组功能 。在测试端口的连通性时，需要在 安全组中允许端口的访问

配置防火墙¶

防火墙是计算机防止网络入侵的第一道屏障，是主机所有流量的出入口。合理的配置防火墙，有助于提高主机的安全性。

注意 屏蔽数据库 3306 端口，不允许外网直接访问
只开放必要端口（SSH 22 端口 + 服务应用端口），禁止访问其它端口
只允许固定的来源 IP 访问某些服务（非必须）

提示

如果是购买云服务，可以使用云服务的 安全组 来设置端口开放，限制来源 IP，也可以搭配主机防火墙一起使用；

配置 DNS¶

如果没有配置正确的 nameserver 地址，会导致我们在访问域名地址时，不能正常解析域名到 IP 地址，导致针对域名的网络连接失败。

检查 /etc/resolv.conf 文件中的 nameserver 配置，添加正确的 nameserver 地址。

配置 SSH¶

SSH 做为提供远程访问计算机的安全协议，通过修改一些配置来提高服务器的安全性。

首先需要需要将 OpenSSH 更新到最新版本；
禁止 root 用户登录，普通用户可以添加到 sudo 组；
禁止密码安全验证，只能使用公钥登录；
优化 SSH 服务器端的性能；

部署¶

FISCO-BCOS 的部署，是指使用 FISCO-BCOS 提供的部署工具，在多台主机上运行一条完整的区块链节点服务。部署作为区块链运维中最核心的部分，是成功搭建一套区块链服务的基础。

部署流程如下：

概览¶

区块链部署是指根据机构和群组的配置关系，使用部署工具，生成每个机构对应的节点配置文件，然后将生成的配置文件推送到单台或者多台主机，并启动节点服务，验证节点的共识状态，以及备份配置文件等一些列操作。

区块链部署是使用区块链服务的最重要的步骤，部署操作的结果将直接影响区块链服务的可用性。

基本概念¶

联盟
- 指参与一个基于区块链的业务协作或业务交易网络的所有组织的集合，一个联盟一般由多个机构组成。
机构
- 指参与区块链业务网络的企业、政府机构、团体、组织等实体。
节点
- 区块链业务网络中的最小单位，可以是一个业务进程或者一台物理主机。
群组
- 由多个机构的节点组成。

联盟、机构、节点、群组之间的关系如图： _images/league-organization-group-node.jpg

部署流程¶

部署的大概流程分为 部署前准备，部署操作 和 验证 + 备份 三个阶段，大致流程如图：

_images/deploy-process.png

生产环境建议¶

如果只需要部署开发（体验）环境，可以直接跳转到开发（体验）环境部署。

由于生产环境的重要性，所以这一小节针对部署生产环境，提供一些建议，以此最大化的的保障生产环境的安全性和稳定性。

机构节点数量¶

基于节点容灾备份的考虑，建议每个机构至少部署 2 个共识节点，建议分布在不同的机器甚至网段上。例如：3 个机构间通过一条链互联，则至少应该部署 3 * 2 = 6 个区块链共识节点（此时，最大只能容忍 1 个节点出错）。

群组节点数量¶

由于群组是由多个机构的节点组成，并且每个群组独立运行各自的共识算法。所以，建议一个群组内所有机构加起来的共识节点数至少为 3 * n + 1（n 表示系统最大可容错的节点数目，为大于等于 1 的整数），建议 n 取值 1，2 即可。

备份¶

在部署区块链服务时，部署工具会为链，机构，主机节点生成大量的配置文件。有些配置文件，一旦丢失后，都是不可再次生成的（比如，私钥文件）。一旦出现文件丢失，恢复的难度很高，甚至可以说无法恢复，严重的甚至会导致整个链无法恢复。所以，对这些文件进行 双备份 就是极其重要的。

生成配置使用单独的机器 在部署时，建议使用单独的机器生成配置文件，然后再将配置文件同步到对应的物理主机，同时对生成的文件做至少双备份。
使用云磁盘 如果节点主机采用的是云主机，强烈建议每个节点将配置文件都放到云磁盘中，而不是主机磁盘，防止配置文件随主机销毁而丢失。

需要备份的文件列表，请参考：备份

环境准备¶

选择版本¶

FISCO-BCOS 每个版本的兼容列表，请参考： FISCO-BCOS 版本及兼容

落盘加密¶

在联盟链的架构中，机构和机构共同搭建一条区块链，数据在联盟链的各个机构内是可见的。

在某些数据安全性要求较高的场景下，联盟内部的成员并不希望联盟之外的机构能够获取联盟链上的数据。此时，就需要对联盟链上的数据进行访问控制。主要分为两个方面：

链上通信数据的访问控制
- 通过节点证书和SSL来实现
节点存储数据的访问控制
- 通过落盘加密来实现。落盘加密是对节点存储在硬盘上的内容（合约的数据、节点的私钥）进行加密，就算硬盘被带出联盟链自己的内网环境，也无法解密链中的数据，保证了数据的安全

重要

节点在第一次运行前，必须配置好是否采用落盘加密。一旦节点开始运行，无法切换状态。

启用落盘加密特性¶

启用落盘加密特性主要有三步：
1. 部署 Key Manager 应用;
2. 使用 gen_data_secure_key.sh 生成节点的配置;
3. 修改节点配置，添加生成的落盘加密配置;

关于落盘加密的详细介绍和操作文档，请参考：落盘加密

国密版本¶

为了充分支持国产密码学算法，金链盟基于国产密码学标准，实现了国密加解密、签名、验签、哈希算法、国密 SSL 通信协议，并将其集成到 FISCO-BCOS 平台中，实现了对国家密码局认定的商用密码的完全支持。

国密版 FISCO-BCOS 将交易签名验签、P2P 网络连接、节点连接、数据落盘加密等底层模块的密码学算法均替换为国密算法，国密版 FISCO-BCOS 与标准版主要特性对比如下：

	标准版FISCO-BCOS	国密版FISCO-BCOS
SSL链接	Openssl TLSv1.2 协议	国密 TLSv1.1 协议
签名验证	ECDSA 签名算法	SM2 签名算法
消息摘要算法	SHA-256 SHA-3	SM3 消息摘要算法
落盘加密算法	AES-256 加密算法	SM4 加密算法
证书模式	OpenSSL 证书模式	国密双证书模式
合约编译器	以太坊 solidity 编译器	国密 solidity 编译器

关于国密支持方案，请参考：国密支持方案

源码编译¶

为了压缩可执行程序的文件大小，减少下载时的网络传输时间，官方提供的可执行文件去掉了调试信息。如果需要带有调试信息的可执行程序，方便后续调试，可以自行通过编译源码获得可执行程序。

使用编译后的可执行程序替换部署工具生成的 fisco-bcos 可执行文件即可。

重要

如果节点处于运行状态，在替换 fisco-bcos 可执行文件之前，需要先关闭节点，然后进行替换。

关于源码编译，请参考：源码编译

检查主机信息¶

如果主机是云主机，由于云主机的公网 IP 均为虚拟 IP。若生成的节点配置文件 config.ini 中 rpc_ip，p2p_ip，channel_ip 三个配置填写了外网 IP，会绑定失败，必须填写 0.0.0.0。

提示

关于 config.ini 文件的配置，请参考： config.ini 配置文件

网络连接
- 确保各个节点之间是否能够相互通信（使用 ping，telnet 命令检查），如果不能访问，配置云主机的安全组，路由配置。
端口开放
- 区块链底层 FISCO-BCOS 在启动的时候，会涉及到三个端口：

‌端口类型	‌默认值	‌描述	‌建议
‌p2p_port	‌30300	‌节点之间互联，包括机构内的多个节点，以及多机构节点之间的互联	‌绑定外网IP 或者 0.0.0.0 注意：云主机的公网 IP 均为虚拟 IP 或者动态 IP，只能使用 0.0.0.0
‌jsonrpc_port	‌8545	‌JSON-RPC API HTTP 请求端口	‌绑定内网 IP 地址，仅供本机和内网访问
‌channel_port	‌20200	‌控制台和客户端 SDK 连接的 Channel 端口	‌绑定内网 IP 地址，仅供本机和内网访问

提示

如果配置 jsonrpc_port 只能本机访问，FISCO-BCOS 2.3.x 之后的版本（包括 2.3.x）配置 jsonrpc_listen_ip 为 127.0.0.1 即可。如果是 2.3.x 之前的版本，只能在网络防火墙屏蔽访问 8545 端口，请参考：配置 RPC

提示

如果绑定内网 IP 地址，就只能本机和内网访问。如果需要某个端口只能本机访问，设置绑定 IP 为 127.0.0.1；
监听端口必须位于 1024-65535 范围内；
云主机一般通过 安全组规则 和 本机防火墙 配置端口开放规则；
私有主机一般是通过 本地 NAT 和 本机防火墙 配置端口开放规则；

部署区块链¶

开发（体验）环境¶

开发环境部署是采用一键部署脚本 build_chain.sh 在单机上快速部署一条 4 节点的 FISCO-BCOS 联盟链，通过控制台（console）或可视化界面（WeBASE-Front）完成合约的编译，部署，调试和调用等操作。

主要操作步骤：

# 下载一键脚本，添加执行权限
curl -LO https://raw.githubusercontent.com/FISCO-BCOS/FISCO-BCOS/master/tools/build_chain.sh

# 生成节点配置文件，如果使用国密，再加上一个 -g 参数
bash build_chain.sh -l "127.0.0.1:4" -p 30300,20200,8545

# 启动节点
bash nodes/127.0.0.1/start_all.sh

关于开发部署工具使用，请参考：开发部署工具

企业环境¶

对于企业部署，官方提供了两种部署方式和三种部署工具来满足现实场景中，多机构，多群组部署的需求。

部署方式

部署方式	特点
单机构部署	单机构部署所有节点（包括其他机构），适用于一个机构部署所有节点。由于密钥统一由一个机构生成，有泄漏风险
多机构对等部署	多机构对等部署，适用于多机构各自部署。每个机构各自部署自己的节点，机构私钥不出内网，可以保证各机构密钥的安全

部署工具

‌部署工具	‌支持的部署方式	适用场景‌	启动方式	备注
‌build_chain.sh	单机构部署	单机构部署所有节点	‌脚本命令行	开发部署工具
‌WeBASE-Docker	单机构部署	单机构部署所有节点	Docker	使用 Dokcer 启动，同时包含一个 WeBASE-Front 应用
‌generator（推荐）	单机构部署多机构对等部署	多个独立机构联盟	‌脚本命令行	企业级部署使用

根据当前部署的场景和环境，选择合适的部署方式已经部署工具。

重要

在部署企业生产环境之前，一定要仔细阅读生产环境建议部分，特别是备份说明，一定要做好配置文件的备份，降低故障恢复的成本和不能恢复的风险
WeBASE-Docker 部署方式，跟使用开发者部署工具大致相同。通过 build_chain.sh 生成节点配置文件。启动的时，通过手动执行 docker run 命令启动一个 Docker 容器
WeBASE-Docker 部署方式，在启动后，会同时启动一个 WeBASE-Front 应用，可以直接通过浏览器查看所有群组，节点的共识状态，块高，视图等信息

开发者工具部署和 WeBASE-Docker¶

开发者工具部署和 WeBASE-Docker 两种方式的部署方式大致相同，使用相同的方式生成节点的配置文件，仅仅是启动节点时，使用的启动命令不一样。

主要操作步骤：

安装依赖
- 使用 build_chain.sh，安装 FISCO-BCOS 依赖
- 使用 WeBASE-Docker，安装 Docker 环境
下载 build_chain.sh 一键脚本
新增机构和群组关系 ip.conf 配置文件
(可选) 编译源码，获取二进制可执行程序
- 如果需要使用带有调试信息的可执行程序，自行编译源码，获取可执行程序 fisco-bcos
- 如果使用 WeBASE-Docker 容器方式启动节点，跳过
执行 build_chain.sh 脚本，使用 -f ip.conf 参数，生成节点配置
- 如果使用自行编译的带调试信息的可执行程序，需要加上 -e /path/to/excutable/fisco-bcos 参数
(可选) 是否使用落盘加密
拷贝生成的配置文件到相应的物理主机，注意使用 云磁盘 存放节点目录
登录每台物理主机，执行启动脚本，启动节点
- 如果使用 WeBASE-Docker，手动使用 docker run 命令启动容器
验证部署结果，请参考：验证部署结果
备份生成的配置文件

详细的操作步骤，请参考：开发者工具和 WeBASE-Docker 部署详细操作

提示

如果使用了 WeBASE-Docker 方式部署，由于 Dokcer 容器已经启动了一个 WeBASE-Front 应用，所以可以 直接使用 WeBASE-Front 方式验证部署结果

运维工具部署（generator）¶

FISCO-BCOS generator 是一个基于 Python 实现，为企业用户提供了部署、管理、监控多机构多群组联盟链的便捷工具。

generator 同时支持 单机构部署 和 多机构对等部署 两种方式。

关于 generator 工具的使用，请参考：generator 运维部署工具使用

根据部署文档，完成部署后，验证部署结果，请参考：验证部署结果。

单机构部署¶

单机构部署是指在联盟链部署时，由协商的其中一个机构来生成所有的节点配置。

_images/single-organization-deploy.png

关于 generator 部署工具在单机构部署时的操作，请参考：单机构部署文档

ansible-for-fisco-bcos

ansible-for-fisco-bcos 是 FISCO-BCOS 开源社区，开发者基于 generator 和 ansible 封装的一个企业级的快速部署工具。在部署 2 群组 3 机构 6 节点的环境，可以在 30 秒内（不包括下载时间）生成配置，极大简化了部署难度，避免了手工配置容易发生的错误。

关于 ansible-for-fisco-bcos 工具的使用，请参考：ansible-for-fisco-bcos

多机构对等部署¶

_images/multiple-organization-deploy.png

提示

每个机构的私钥和节点私钥不会发送到外部，保证安全；
一条联盟链中只能用到一个根证书 ca.crt，由联盟委员会生成；
一个群组只能有一个群组创世区块信息 group.x.genesis；
一个机构属于多个群组时，使用 add_group 执行添加新群组；
一个群组有 2 个以上的机构，需要将多个 peers.txt 需要合并到一个文件后再生成配置；
生成的节点配置，只需要将配置推送到 IP 对应的物理主机即可；
如果使用落盘加密，请参考：落盘加密

关于 generator 部署工具在多机构对等部署时的操作，请参考：

验证部署结果¶

在部署操作执行完成后，不管是开发环境，还是企业环境，都可以使用相同的验证方式来检查部署的结果是否成功。

验证部署结果主要有两种方式：

check_seal.sh 脚本
- 执行 check_seal.sh 脚本，脚本会通过 JSON-RPC 请求获取节点的块高和 view，每分钟获取一次，跟上一次比对，如果相同则共识异常，如果不同，共识状态正常
WeBASE-Front
- 部署 WeBASE-Front 应用，通过 Web 页面来查询部署结果

提示

如果使用了 WeBASE-Docker 部署方式，由于 Docker 镜像自带了 WeBASE-Front 镜像，就可以通过浏览器通过节点列表页面直接验证

check_seal.sh 脚本验证¶

使用脚本验证部署节点的共识状态，详细的脚本文件和使用方法，请参考：检查节点是否共识脚本

可视化 WeBASE-Front 验证¶

可视化验证，需要部署 WeBASE-Front 应用，通过页面来查看部署的结果，请参考：部署 WeBASE-Front

问题排查¶

如果在部署和验证中，出现问题，可以通过官方问题问题排查查找相应解决办法。

部署合约¶

部署合约是指，将 solidity 语言编写的合约代码进行编译，然后调用部署方法，将合约代码上传到区块链上。只有合约通过部署到链上后，SDK 和应用程序才能进行调用。

部署合约的三种方式：

控制台（console）部署
SDK 部署
（推荐使用）可视化（WeBASE-Front）部署

提示

SDK 部署需要使用控制台（console）中的 sol2java.sh 脚本来生成对应的 Java 文件，只需要部署控制台（console）服务，不需要运行；

控制台（console）¶

登录一台节点主机，部署控制台（console）服务
上传合约到指定的目录
启动 console
调用部署指令

部署控制台应用，请参考：部署和启动控制台

合约部署和调用，请参考：控制台部署合约

SDK¶

登录一台节点主机，部署 console
上传合约到指定的目录
执行编译脚本 contracts/sdk/sol2java.sh，使用包名（比如：org.fisco.xxx）做参数，生成 Java 文件
导入 Java 文件到工程，依赖 web3j SDK
编写 Java 代码，通过 web3j SDK 提供的方法部署合约

关于如何使用合约编译工具，请参考：合约编译工具

合约编译工具操作示例，请参考：合约编译工具的示例

可视化（WeBASE-Front）¶

登录一台节点主机，部署并启动 WeBASE-Front
在浏览器输入地址：http://[IP]:5002/WeBASE-Front/#/home
选择群组编号，然后点击左侧的合约管理，打开合约 IDE

关于 WeBASE-Front 的部署，请参考：部署 WeBASE-Front

_images/webase-front-solidity-ide.jpg

创建合约文件夹，上传合约文件
指定点击编译和部署按钮，如下图：

_images/webase-front-deploy-contract.jpg

监控¶

监控是整个运维乃至整个产品生命周期中非常重要的一环，事前及时预警预防故障，事后提供详实的数据用于追查定位问题，通过发现、定位、解决问题，期望缩短异常出现的 MTTR （平均修复时间）。

如果没有监控，所有的基础运维，业务运维都是“瞎子”，毫无可靠性、安全性和稳定性，也就印证了运维界的老话：“无监控、不运维”。

区块链的核心监控指标：

监控指标	详细	推荐优先级
主机状态	CPU，内存，磁盘 IO ，磁盘使用率，网络	云服务 > 平台监控 > WeBASE-Front
节点存活	fisco-bcos 进程	monitor.sh
共识状态	块高、view	monitor.sh > WeBASE-Front
错误日志	搜集所有的 error 和 warning 日志，判断网络连接状态	monitor.sh
告警	分析错误日志，发送告警信息到微信账号	monitor.sh

提示

对于主机监控，如果使用云服务推荐优先使用云平台的监控，如果使用平台服务，可以使用平台监控，也可以选择 WeBASE-Front 服务
monitor.sh 脚本需要配合 crontab 一分钟执行一次
FISCO-BCOS 在 v2.x.x 以后的版本，对日志进行了优化，监控时只需要关注 error 和 warning 日志即可

日志说明¶

FISCO-BCOS 的日志，默认位于节点目录的 log 目录下，日志格式为：

log_level|time|[g:group_id][module_name] content

log_level
- 日志级别。从小到大包括 trace、debug、info、warning、error、fatal
- 最主要关注 error 和 warning 两种日志
time
- 表示日志打印时间
[g:group_id]
- 表示群组号
[module_name]
- 表示模块名，包括共识、同步、交易池、存储等
content
- 为具体日志内容

日志输出级别设定在 config.ini 文件配置。

提示

测试环境建议设置为 trace 或 debug
生产环境建议设置为 info 级别，减少日志输出量（trace 和 debug 日志量较大），避免日志占用过多磁盘空间

关于日志说明，请参考：日志格式

WeBASE-Front 监控示例¶

WeBASE-Front 的部署，请参考：部署 WeBASE-Front。

提示

如果使用了 WeBASE-Docker 方式部署，由于 Dokcer 容器已经启动了一个 WeBASE-Front 应用，可以直接使用浏览器打开地址：http://[IP]:5002/WeBASE-Front/#/home

CPU，内存，磁盘使用率，网络

_images/webase-front-monitor.jpg

区块高度，pbftView，待打包交易数，如图：

_images/webase-front-view-height.jpg

监控脚本¶

FISCO-BCOS generator 生成的节点配置文件夹中提供了内置的监控脚本 monitor.sh，需要配置告警信息接受账号。再搭配 crontab 一分钟执行一次脚本。

脚本会自动解析节点日志，匹配一定的规则（比如某个 error 或者 warning 连续出现 5 次），自动发告警信息到配置的账号。

monitor.sh 的功能：
- 监控节点是否存活, 并且可以重新启动挂掉的节点；
- 获取节点的块高和 view 信息, 判断节点共识是否正常；
- 分析最近一分钟的节点日志打印, 收集日志关键错误打印信息, 准实时判断节点的状态；
- 指定日志文件或者指定时间段, 分析节点的共识消息处理, 出块, 交易数量等信息, 判断节点的健康度；
- 根据错误日志，发送告警信息到指定的微信账号；

提示

只有通过 FISCO-BCOS generator 生成的节点配置文件，才包含了 monitor.sh 脚本，build_chain.sh 生成的节点配置文件暂不包含。
monitor.sh 需要加入到 crontab 定时执行，推荐 一分钟

关于 monitor.sh 脚本监控的详细使用，请参考：监控设计

常见告警信息¶

OK! $config_ip:$config_port $node:[group:$group] is working properly: height $height view $view
- 节点正常启动, 群组$group共识正常并且共识模块正常工作；
- 注意：区块链本身有一定的容错能力, 共识正确不代表整个链完全正常, 不排除有其他的节点异常；
ERROR! $config_ip:$config_port $node does not exist
- 节点$node进程不存在, 节点宕机, 此时会自动启动节点；
- 注意：连续发生说明脚本无法正常启动进程,此时需要运维人员查看节点日志,确认节点无法正常启动的原因；
ERROR! Cannot connect to $config_ip:$config_port $node:[group:$group]
- 获取块高或者视图的RPC请求失败, 节点宕机获取节点群组$groupRPC服务异常；
ERROR! $config_ip:$config_port $node:[group:$group] is not working properly: height $height and view $view no change
- 群组共识异常，严重错误；
- 节点块高,视图与上次比较没有发生变化, 一般是因为区块链中有其他节点宕机或者网络直接p2p网络无法连通；

常见日志¶

Find disconnectedNode,disconnectedNodeSize=x
- 节点发现断连（已经建立过连接）；
disconnect error P2PSession,nodeID=xxxx
- 没有和节点建立连接；
TCP Connection refused by node,endpoint=10.10.10.10:30434,message=Connection refused
- 尝试重连节点失败；
ViewChangeWarning: not caused by omit empty block
- 共识异常日志，网络抖动、网络断连或配置出错(如同一个群组的创世块文件不一致)均有可能导致节点共识异常，PBFT共识节点会输出 ViewChangeWarning日志；

运维管理¶

压力测试¶

对于区块链开发者和用户而言，性能是评价一个区块链平台重要的考量条件。对于 FISCO-BCOS，提供了 Caliper 来测试整个区块链服务的整体性能。

关于 Caliper 的介绍，请参考：性能压测工具 Caliper

关于 Caliper 的使用，请参考：Caliper 压力测试

安全控制¶

为了保障节点间通信安全性，以及对节点数据访问的安全性，FISCO-BCOS 引入了 节点准入 机制、CA 黑白名单 和 权限控制 三种机制，在网络和存储层面上做了严格的安全控制。

提示

权限控制根据具体实现分为两种：基于表的权限控制 和 基于角色的权限控制。

节点准入¶

节点准入，是指基于群组的概念，将节点的接入分为两种：网络准入 机制和 群组准入 机制。每种准入机制的规则记录在配置中，节点启动后将读取配置信息实现网络及群组的准入判断，来判断是否允许节点介入区块链网络。

关于节点准入介绍，请参考：节点准入管理介绍

关于节点准入操作，请参考：节点准入管理操作文档

CA黑白名单¶

CA黑名单

别称 证书拒绝列表（certificate blacklist，简称CBL）。CA 黑名单基于 config.ini 文件中 [certificate_blacklist] 配置的NodeID进行判断，拒绝此NodeID节点发起的连接。

CA白名单

别称 证书接受列表（certificate whitelist，简称CAL）。CA 白名单基于 config.ini 文件中 [certificate_whitelist] 配置的NodeID进行判断，拒绝除白名单外所有节点发起的连接。

关于 CA 黑白名单介绍，请参考：CA 黑白名单介绍

关于 CA 黑白名单操作，请参考：CA 黑白名单操作手册

基于表的权限控制¶

权限控制是指，基于外部账户(tx.origin)的访问机制，对包括合约部署，表的创建，表的写操作（插入、更新和删除）进行权限控制，表的 读操作不受权限 控制。

权限控制规则如下：

权限控制的最小粒度为表，基于外部账户进行控制。
使用白名单机制，未配置权限的表，默认完全放开，即所有外部账户均有读写权限。
权限设置利用权限表（_sys_table_access_）。权限表中设置表名和外部账户地址，则表明该账户对该表有读写权限，设置之外的账户对该表仅有读权限。

关于权限控制介绍，请参考：权限控制介绍关于权限控制工具操作，请参考：权限控制工具

基于角色的权限控制¶

当前 基于表的权限控制，由于涉及到许多系统表，要求用户对底层的逻辑有一定理解，使用门槛较高。

从 2.5.0 版本开始，基于已有的表权限控制模型，新增了 ChainGovernance 预编译合约，用于实现基于角色的权限控制。

关于基于角色的权限控制介绍和使用，请参考：基于角色的权限控制

新增机构¶

在新增加一个机构时，需要链私钥的持有方（联盟委员会）进行操作，为新机构签发机构证书。

生成新机构文件：

获取机构证书生成脚本 gen_agency_cert.sh
使用脚本生成新的机构证书和私钥信息
生成的机构证书在 nodes/cert/newAgencyName 以及 nodes/gmcert/newAgencyName-gm 下
将新生成的 newAgencyName 中的文件发送给新机构
备份生成的新机构文件

在新增机构后，如果机构需要新增节点，请参考：节点管理。

重要

对新生成的机构私钥和证书备份

群组管理¶

FISCO-BCOS 通过引入群组实现 单链多账本 功能。使联盟链从原有一链一账本的存储/执行机制扩展为一链多账本的存储/执行机制，基于群组维度实现同一条链上的数据隔离和保密。

群组间数据隔离，每个群组可以独立运行各自的共识算法，不同群组可使用不同的共识算法。

在区块链的维护操作中，常见的群组操作包括：

新建群组
启动群组
停止群组
删除群组
恢复群组
查询群组状态

当前群组管理有两种方式：

JSON-RPC
- 通过 JSON-RPC 向节点发送请求，完成群组的操作
- 具体请参考：JSON-RPC API 接口操作中群组操作接口
SDK
- 通过使用 SDK 提供的 API 接口进行编码，使用程序来操作群组
- 使用 WeBASE-Node-Manager 服务进行群组管理，具体请参考：群组管理

提示

在调用群组 JSON-RPC API 接口时，请求中的 nodeid 参数从文件 conf/node.nodeid 中获取
WeBASE-Node-Manager 是 WeBASE 提供的一个中间件服务。依赖 WeBASE-Web，WeBASE-Front 和 WeBASE-Sign 三个服务。关于 WeBASE-Node-Manager 的部署和使用：[WeBASE-Node-Manager 节点管理服务](https://webasedoc.readthedocs.io/zh_CN/latest/docs/WeBASE-Node-Manager/index.html)

节点管理¶

FISCO-BCOS 中，一个节点代表一个 fisco-bcos 服务进程，在生产环境，一般一台主机只运行一条区块链的一个节点。

节点的类型分为三种类型：

组员
- 共识节点：参与共识的节点，拥有群组的所有数据（部署时默认都生成共识节点）；
- 观察节点：不参与共识，但能实时同步链上数据的节点；
非组员
- 游离节点：已启动，待等待加入群组的节点。处在一种暂时的节点状态，不能获取链上的数据；

节点管理操作包括：

关于节点操作的介绍文档，请参考：

节点加入网络¶

节点加入网络是指，新生成一个节点，并将节点加入到网络中，成为一个游离节点。

操作的主要步骤：

登录生成配置的主机（机构私钥所在主机）
下载 gen_node_cert.sh 脚本
使用机构私钥，通过 gen_node_cert.sh 生成新节点的配置文件
从其它节点拷贝 config.ini，start.sh，stop.sh 文件
修改拷贝后的 config.ini 文件
从其它节点拷贝要加入群组的 group.x.genesis，group.x.ini 文件，不需要改动
上传节点文件到物理主机
执行 start.sh 启动节点
检查新节点是否与原有节点创建连接
备份

关于节点加入网络的详细操作步骤，请参考：节点加入网络

提示

建议用户同时修改原有节点的 config.ini 文件，在 P2P 节点连接列表中加入新节点的信息并重启原有节点，保持全网节点的全互联状态。

节点加入群组¶

节点加入群组的操作，是通过控制台（console）完成的，先部署控制台（console）。

关于控制台的部署，请参考：控制台部署和启动

操作的主要步骤：

节点先加入网络，请参考：节点加入网络
- 使用控制台（console）调用 getNodeIDList，确认节点已加入网络成功
使用控制台（console）调用 addObserver ，设置新节点为观察节点
使用控制台（console）调用 getObserverList，确认新节点是否在观察节点列表中
等待节点完成同步区块后（块高接近最新块高），使用控制台（console）调用 addSealer ，设置新节点为共识节点
- 先设为观察节点再设为共识节点是为了不影响原有节点网络的共识
使用控制台（console）调用 getSealerList，确认新节点是否在共识节点列表中
备份所有节点的配置文件

关于节点加入群组的详细操作步骤，请参考：节点加入群组

提示

需要加入群组的群组为 id，就从 该群组 其它节点的 config 目录下拷贝该群组的 group.[id].genesis，group.[id].ini 配置文件
节点的 nodeid 从节点根目录下 conf/node.nodeid 文件获取
新节点首次启动会将配置的群组节点初始列表内容写入群组节点系统表，区块同步结束后，群组各节点的群组节点系统表均一致；
新节点需先完成网络准入后，再执行加入群组的操作，系统将校验操作顺序；

节点退出群组¶

节点退出群组的操作，是通过控制台（console）完成的，先部署控制台（console）。

关于控制台的部署，请参考：控制台部署和启动

操作的主要步骤：

使用控制台（console）调用 removeNode ，设置节点为游离节点；
使用控制台（console）调用 getSealerList，确认新节点是否在共识节点列表中
备份所有节点配置文件

关于节点退出群组的详细操作步骤，请参考：节点退出群组

提示

节点可以以 共识节点 或 观察节点 的身份执行退出操作。

节点退出网络¶

节点退出网络是指，将一个游离节点下线，不再接入网络。

操作的主要步骤：

节点先退出群组
修改退出的节点，清空 config.ini 文件中 P2P 连接配置， 并重启节点
对于同一群组的其它节点，修改 config.ini 文件，从 P2P 连接配置 中删除退出节点的信息，并重启
确认同一群组的其它节点和退出节点的原有连接断开
备份所有节点配置文件

关于节点退出网络的详细操作步骤，请参考：节点退出网络

重要

操作节点退出网络时，必须先退出群组，退出顺序由用户保证，系统不再作校验

节点升级¶

节点升级可以通过新版本可执行文件 fisco-bcos 替换旧版本的可执行文件来完成，但是升级操作是仍然是属于比较危险的操作，建议在升级之前，对旧版本可执行文件进行备份。

重要

在进行升级之前，请仔细阅读版本升级文档和变更描述
根据升级文档中兼容性描述，判断是否需要升级 SDK 依赖库版本。

升级方式¶

重要

备份，备份，备份！！ 在进行操作之前，已经要对变更文件进行备份操作！！

兼容升级
- 大版本需要相同，比如都是 2.x.x
- 可执行文件是指节点目录中 fisco-bcos 文件
- 直接使用新版本的可执行文件替换旧版本的可执行文件。比如，使用二进制为 v2.4.0 的可执行文件替换版本 v2.3.x 可执行文件，升级后的版本修复 v2.3.x中的 bug，并新增了 v2.4.0 动态群组生命周期管理功能、网络统计功能，但不会包含 v2.4.0所有特性，普通场景下可回滚至 v2.3.x
- 回滚时，使用备份的旧版本 v2.3.x 可执行文件替换升级的可执行文件即可
全面升级
- 参考部署部分重新搭建新链，重新向新节点提交所有历史交易，升级后节点包含 v2.4.0 所有新特性
- 如果需要使用节点新特性，推荐方式为：搭建新链条，旧业务保持，新旧链共存，旧业务访问旧链，新业务访问新链；
- 如果不想使用新旧链共存的方式，需要重新编写业务代码，需要自行将交易重新提交到新链上；

提示

由于 1.x.x 和 2.x.x 的底层数据结果不一致，所以如果要从 1.x 升级到 2.x 不建议全面升级，推荐搭建新链的方式，保持旧链
FISCO-BCOS 采用 support_version 来控制区块链兼容版本，support_version 在部署链的时候决定（config.ini 配置文件中），后续升级节点此项配置不可更改。例如建链时 support_verison 为 2.1.0，后续节点升级到 2.2.0、2.3.0 之后，support_version 配置必须仍然保持为 2.1.0。
兼容升级仅包括 大版本相同 的版本升级，比如 2.2.0 到 v2.4.0；

升级流程¶

了解中间所有跨度版本的更新、修复、新特性部分，参考：版本兼容性和变更
确定新版本与现有 SDK，Solidity 等的兼容性
仔细阅读官方的升级文档，制定自己的升级方案（确定是兼容性升级还是全面升级）
关闭节点
备份现有可执行程序以及配置文件
替换原有可执行文件，修改配置文件
启动节点
检查节点和节点共识状态

节点迁移¶

节点迁移是指，当某个节点主机出现错误，或者其他原因需要更换主机时（比如云服务的主机被销毁，但是数据盘还在），将原有的节点配置文件目录和数据目录，挂载到一台新的主机，并且重启节点后，快速的完成节点变更操作。

节点迁移的大致流程：

挂载保存了配置文件和数据文件的磁盘到新的主机
- 或者拷贝原有节点目录到新主机
修改新主机 config.ini 文件中 P2P 配置中旧的 IP 为新的 IP 地址，启动节点
修改其它相关节点的 config.ini 文件中的 P2P 配置，修改旧 IP 为新节点的 IP，重启相关节点
检查节点的共识状态

增加磁盘容量¶

区块链的链数据是持续增长的，对于保存共识节点和观察节点，数据会一直累积，当磁盘空间不足时，需要进行操盘扩容操作。

增加磁盘容量主要步骤：

如果可以，对磁盘做一个快照；
停止节点；
增加新磁盘；
对节点的数据目录 data 所在的分区进行扩容（LVM 和非 LVM 两种方式）；
- 有些云平台提供动态扩容，可以参考云平台的相关文档进行扩容。
检查分区容量是否增加；
启动节点；

证书管理¶

证书，是指由私钥签发的 crt 文件，包括： * 链证书、 * 机构证书 * 节点证书、SDK 证书

在申请签发证书的时候，证书申请中会带上一个有效期的时间，一旦超过这个时间，底层节点在进行通信时，证书验证就会失败，导致无法创建网络连接，不能连接到区块链网络。所以，证书的管理，特别是有效期检测和监控，就变得至关重要。

证书管理包括：

在进行证书管理的操作之前，先获取证书检测脚本：

重要

当前的 `check_certificates.sh` 脚本不支持国密。

证书有效期检测¶

关于证书有效期检测，请参考：证书有效期检测

证书有效期监控¶

由于证书的重要性，所以需要随时关注证书的有效期时间。

关于证书的有效期监控，提供了两种方式：

使用有效期检测脚本
- 使用证书有效期检测脚本，加上 crontab 定时执行，并定期发现执行结果到自定义地址
使用 WeBASE-Node-Manager 服务查看
- 部署 WeBASE-Front 服务。如果使用 WeBASE-Docker 方式部署，就不再需要单独部署 WeBASE-Front 应用
- 使用 WeBASE-Node-Manager 服务，具体请参考：系统管理–证书管理

验证证书¶

关于证书验证，请参考：证书验证

证书续期¶

在进行证书续期前建议先检测证书的过期时间，当证书快要过期时，及时地进行证书续期操作，保证证书的有效性。

证书的续期同样需要签发方操作。链证书和机构证书都需要联盟委员会来进行续签操作，节点和 SDK 的证书则需要机构来进行续期操作。

链证书续期操作
- 使用链私钥 ca.key 重新签发链证书 ca.crt，
- 使用新生成的链证书 ca.crt 替换所有节点 conf 目录下的证书。
机构证书续期操作
- 使用机构证书 agency.key 生成证书请求文件 agency.csr；
- 使用链私钥 ca.key 对证书请求文件 agency.csr 签发得到机构证书agency.crt。
节点、SDK 证书续期操作
- 使用节点 node.key 生成证书请求文件 node.csr；
- 使用机构私钥 agency.key 对证书请求文件 node.csr 签发得到节点证书 node.crt；
- 将节点证书和机构证书拼接得到 node.crt；
- 使用新生成的节点证书 node.crt 替换所有节点 conf 目录下的证书。

重要

备份，备份，备份新生成的证书文件
证书拼接是使用 cat ~/myagency/agency.crt >> ./node.crt 命令将两个文件内容拼接到一起即可

关于证书续期的详细操作文档，请参考：

数据备份与恢复¶

FISCO-BCOS 支持两种数据备份方式，可以根据需要选择合适的方式：

静态备份
- 停止节点，将节点的 data 目录整体打包压缩并备份到其他位置，待需要的时候从备份数据解压缩恢复节点。这种方式相当于快照一个账本状态的数据，以便后续从这个状态进行恢复；
- 优点是无需部署新的服务，操作和运维简单；
- 缺点是备份的是某个历史状态，从这个状态恢复的数据不是最新数据，恢复之后需要从其他节点同步账本更新的数据；
实时备份
- 接入数据导出服务，实时将账本数据导出到链外的 MySQL，待需要恢复或新增节点时，从数据导出服务请求恢复最新的账本状态；
- 优点是可以随时恢复到最新账本状态；
- 缺点是需要部署服务，运维成本更高一些；

附录¶

依赖安装¶

安装 FISCO-BCOS 依赖¶

FISCO-BCOS 运行需要依赖
- openssl
部署工具依赖
- wget
- curl
JSON-RPC 依赖
- jq

# Ubuntu/Debian
sudo apt-get update && apt-get install -y openssl curl wget jq

# CentOS/RHEL
sudo yum install -y openssl curl wget jq

安装 Docker 应用¶

如果想要使用 Docker 方式来部署节点，那么需要在主机中安装 Docker 服务。

安装方法

系统	版本最低要求
CentOS(RHEL)	CentOS 7.3（kernel >= 3.10.0-514）
Debian	Stretch 9
Ubuntu	Xenial 16.04 (LTS)

CentOS(RHEL)/Debian/Ubuntu

curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun;

关于其他系统的安装方式，请参考：Docker 安装
检查存储驱动
- Docker 容器中的读写操作都发生在镜像层或者挂载的文件系统中，所以选择一个合适的存储驱动，有助于提高 Docker 中容器的性能和稳定性。推荐 CentOS/RHEL/Ubuntu 中都使用 overlay2 驱动。

# 检查 Docker 的存储驱动是否为 overlay2
$ docker info | grep -i "Storage Driver"

# 如果输出下面结果，表示使用了 overlay2 驱动
 Storage Driver: overlay2

注意 Docker 服务的权限

安装 Java 运行环境¶

控制台（console）和 WeBASE-Front 需要依赖 Java 的运行环境 JDK。

Ubuntu（Debian）安装 Java¶

# 安装默认Java版本(Java 8或以上)
sudo apt install -y default-jdk
# 查询Java版本
java -version 

CentOS 安装 Java¶

# 查询 CentOS 原有的 Java 版本
$ rpm -qa|grep java

# 删除查询到的Java版本
$ rpm -e --nodeps java-[VERSION]

# 查询 Java 版本，没有出现版本号则删除完毕
$ java -version

# 创建新的文件夹，安装Java 8或以上的版本，将下载的jdk放在software目录
# 从 openJDK官网 (https://jdk.java.net/java-se-ri/8) 
#   或
# Oracle官网(https://www.oracle.com/technetwork/java/javase/downloads/index.html)
# 选择Java 8或以上的版本下载
# 例如下载jdk-8u201-linux-x64.tar.gz
$ mkdir /software

# 解压jdk 
$ tar -zxvf jdk-8u201-linux-x64.tar.gz

# 配置Java环境，编辑/etc/profile文件 
$ vim /etc/profile 

# 打开以后将下面三句输入到文件里面并退出
export JAVA_HOME=/software/jdk-8u201-linux-x64.tar.gz
export PATH=$JAVA_HOME/bin:$PATH 
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

# 生效profile
$ source /etc/profile 
# 查询Java版本，出现的版本是自己下载的版本，则安装成功。
java -version 

提示

需要 JDK1.8 或以上版本，推荐使用 [OpenJDK](https://openjdk.java.net/)，建议从 [OpenJDK 网站](https://openjdk.java.net/install/) 自行下载（CentOS 的 yum 仓库的 OpenJDK 缺少 JCE(Java Cryptography Extension) ，会导致使用该 JDK 启动的应用无法正常连接区块链节点）。

部署操作¶

开发工具和 WeBASE-Docker 部署详细操作¶

开发工具部署和WeBASE-Docker 部署主要依赖 build_chain.sh 脚本来生成节点的配置文件，区别仅仅是启动时使用的命令不一致。

开发工具部署
- 使用 bash start.sh 启动节点
WeBASE-Docker 部署
- 使用 docker run 命令，通过 -v 参数，挂载配置文件的方式启动一个容器的方式启动节点

提示

build_chain.sh 脚本同样可以部署生产环境，但是这种部署方式仅仅支持企业环境部署中的 单机构部署操作。
如果使用了 WeBASE-Docker 方式部署，启动的容器已经自带了 WeBASE-Front 应用，可以 直接使用 WeBASE-Front 方式验证 。

具体的部署流程：

安装部署依赖：
- 开发者工具部署，安装 FISCO-BCOS 依赖，请参考：安装 FISCO-BCOS 依赖
- WeBASE-Docker 部署，安装 Docker 应用，请参考：安装 Docker 应用
下载一键脚本

# 创建目录
cd ~ && mkdir -p fisco && cd fisco
# 下载一键脚本
curl -LO https://raw.githubusercontent.com/FISCO-BCOS/FISCO-BCOS/master/tools/build_chain.sh
# 脚本添加可执行权限
chmod u+x build_chain.sh

配置机构和群组关系

# 生成区块链配置文件ipconf，agency开头表示不同的机构， 1，2，3 表示群组的 id
$ cat > ipconf << EOF
172.16.1.101:1 agencyA 1,2,3
172.16.1.102:1 agencyB 1,2,3
172.16.1.103:1 agencyC 1
172.16.1.104:1 agencyD 1
172.16.1.105:1 agencyD 2
172.16.1.106:1 agencyD 2
172.16.1.107:1 agencyD 3
172.16.1.108:1 agencyD 3
EOF

# 查看配置文件ip_list内容
$ cat ipconf
# 空格分隔的参数分别表示如下含义：
# ip:num: 物理机IP以及物理机上的节点数目
# agency_name: 机构名称
# group_list: 节点所属的群组列表，不同群组以逗号分隔
172.16.1.101:1 agencyA 1,2,3
172.16.1.102:1 agencyB 1,2,3
172.16.1.103:1 agencyC 1
172.16.1.104:1 agencyD 1
172.16.1.105:1 agencyD 2
172.16.1.106:1 agencyD 2
172.16.1.107:1 agencyD 3
172.16.1.108:1 agencyD 3

使用 build_chain.sh 脚本生成区块链节点配置文件夹

# 根据配置生成节点配置， 需要保证每台主机的30300~30301，20200~20201，8545~8546端口没有被占用
# -g : 表示使用国密版本，默认使用标密。
bash build_chain.sh -f ipconf -p 30300,20200,8545

是否编译源码
- 使用 WeBASE-Docker 方式部署时，可执行程序已经包含在镜像中，不能使用自编译可执行文件进行替换
- 如果需要使用带有调试信息的可执行程序，可以通过源码编译可执行程序，然后替换掉 nodes/172.16.1.10X/fisco-bcos文件即可。请参考：源码编译
备份
- 部署工具生成的所有文件中，除了 nodes/172.16.1.10X/fisco-bcos 可执行程序文件不用备份，备份其余的所有文件。

[root@host fisco]# ls -alh nodes/172.16.1.101/fisco-bcos
-rwxr-xr-x 1 root root 23M Apr 30 10:04 nodes/172.16.1.101/fisco-bcos

拷贝生成的配置文件到相应的物理主机
- 如果是云主机，强烈建议将该文件夹存放在云磁盘中，而不是主机磁盘。防止因意外导致主机被销毁时，主机磁盘顺带被销毁，导致配置文件和数据丢失。

# 根据 IP 拷贝相应的文件夹到相应的主机
[root@host fisco]# tree -L 1 nodes/
nodes/
├── 172.16.1.101    # 拷贝该文件夹到 172.16.1.101 的主机
├── 172.16.1.102    # 拷贝该文件夹到 172.16.1.102 的主机
........

登录每台物理主机，执行启动脚本，启动节点
- 使用 build_chain.sh 部署，执行 bash start.sh 脚本
- 使用 WeBASE-Docker，安装下面的格式，执行 docker run 命令

# 假设拷贝到的目录是  /opt/fisco
scp -r nodes/172.16.1.101/* root@172.16.1.101:/opt/fisco
........
........
# 查看拷贝后的文件
[root@host fisco]# ls -alh /opt/fisco/
total 21M
drwxr-xr-x  4 root root 4.0K Apr 30 16:21 .
drwxr-xr-x. 3 root root 4.0K Apr 30 14:48 ..
-rwxr-xr-x  1 root root  890 Apr 30 16:21 download_console.sh
-rwxr-xr-x  1 root root  21M Apr 30 16:21 fisco-bcos
drwxr-xr-x  4 root root 4.0K Apr 30 16:21 node0
drwxr-xr-x  2 root root 4.0K Apr 30 16:21 sdk
-rwxr-xr-x  1 root root  529 Apr 30 16:21 start_all.sh
-rwxr-xr-x  1 root root  516 Apr 30 16:21 stop_all.sh


#### 脚本启动
# 在 172.16.1.101 主机上，使用脚本调用命令行
cd /opt/fisco/ && bash start_all.sh

#### WeBASE-Docker 启动
# 在 172.16.1.101 主机上，使用 Docker 方式启动，只支持国密版本
# 1. 移动 sdk 目录，Docker 容器中的 WeBASE-Front 启动时需要使用
cd /opt/fisco/ && mv -fv sdk node0/
# 2. 启动容器，根据自己的需求修改镜像的 tag
cd /opt/fisco/ && docker run -d -v /opt/fisco/node0:/data -v /opt/fisco/frontlog:/dist/log --network=host -w=/data fiscoorg/front:bsn-0.2.0-gm

验证部署结果
- 具体验证方式和步骤，请参考：验证部署结果

脚本工具¶

检查节点是否共识脚本¶

创建 ~/fisco/nodes/127.0.0.1/check_seal.sh 脚本
- 脚本存放在跟 nodeX 同一级目录

#!/bin/bash
dirpath="$(cd "$(dirname "$0")" && pwd)"
cd $dirpath

# info message
info() {
        local timestamp=$(date "+%Y-%m-%d %H:%M:%S")
	echo -e "\033[32m[INFO] [${timestamp}] $1\033[0m"
}

# error message
error() {
        local timestamp=$(date "+%Y-%m-%d %H:%M:%S")
	echo -e "\033[31m[ERROR] [${timestamp}] $1\033[0m"
}

# alarm function
alarm() {
        local message="$1"
        error "${message}"
}


# check that the node is working properly
function check_node_work_properly() {
        # node dir
        local nodedir=$1
        # node name
        local node=$(basename $nodedir)
        # fisco-bcos path
        local fiscopath=${nodedir}/../fisco-bcos
        # config.ini for this node
        local config=$1/config.ini
        # rpc url
        local config_ip="127.0.0.1"
        local config_port=$(cat $config | grep 'jsonrpc_listen_port' | egrep -o "[0-9]+")

        # check if process id exist
        local pid=$(ps aux | grep "$fiscopath" | egrep "fisco-bcos" | grep -v "grep" | awk -F " " '{print $2}')
        [ -z "${pid}" ] && {
                alarm " ERROR! $config_ip:$config_port $node does not exist "
                return 1
        }

        # get group_id list
        local groups=$(ls ${nodedir}/conf/group*genesis | egrep -o "group.*.genesis" | egrep -o "[0-9]*" | tr "\n" " ")
        for group in ${groups}; do
                # get blocknumber
                heightresult=$(curl -s "http://$config_ip:$config_port" -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"getBlockNumber\",\"params\":[${group}],\"id\":67}")
                # echo $heightresult
                height=$(echo $heightresult | awk -F'"' '{if($2=="id" && $4=="jsonrpc" && $8=="result") {print $10}}')
                [[ -z "$height" ]] && {
                        alarm " ERROR! Cannot connect to $config_ip:$config_port $node:[group:$group] "
                        continue
                }

                height_file="$nodedir/$node_$group.height"
                prev_height=0
                [ -f $height_file ] && prev_height=$(cat $height_file)
                heightvalue=$(printf "%d\n" "$height")
                prev_heightvalue=$(printf "%d\n" "$prev_height")

                # get pbft view
                viewresult=$(curl -s "http://$config_ip:$config_port" -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"getPbftView\",\"params\":[$group],\"id\":68}")
                # echo $viewresult
                view=$(echo $viewresult | awk -F'"' '{if($2=="id" && $4=="jsonrpc" && $8=="result") {print $10}}')
                [[ -z "$view" ]] && {
                        alarm " ERROR! Cannot connect to $config_ip:$config_port $node:[group:$group] "
                        continue
                }

                view_file="$nodedir/$node_$group.view"
                prev_view=0
                [ -f $view_file ] && prev_view=$(cat $view_file)
                viewvalue=$(printf "%d\n" "$view")
                prev_viewvalue=$(printf "%d\n" "$prev_view")

                # check if blocknumber of pbft view already change, if all of them is the same with before, the node may not work well.
                [ $heightvalue -eq $prev_heightvalue ] && [ $viewvalue -eq $prev_viewvalue ] && {
                        alarm " ERROR! $config_ip:$config_port $node:[group:$group] is not working properly: height $height and view $view no change"
                        continue
                }

                echo $height >$height_file
                echo $view >$view_file
                info " OK! $config_ip:$config_port $node:[group:$group] is working properly: height $height view $view"

        done

        return 0
}


# check all node of this server, if all node work well.
function check_all_node_work_properly() {
        local workplace=$1
        for configfile in $(ls ${workplace}/node*/config.ini); do
                check_node_work_properly $(dirname $configfile)
        done
}

function help() {
        echo "Usage:"
        echo "Optional:"
        echo "    -d  <working directory path>     default: \$dirpath/ "
        echo "    -h                  Help."
        echo "Example:"
        echo "    bash check_seal.sh -d /data/app/127.0.0.1 "
        exit 0
}

work_dir=${dirpath}

while getopts "d:f:h" option; do
        case $option in
        d) work_dir=$OPTARG ;;
        h) help ;;
        esac
done

[ ! -d ${work_dir} ] && {
        echo " working directory($work_dir) not exist, place check_seal.sh at the same directory with node directory. "
        exit 1
}

#
check_all_node_work_properly ${work_dir} ${logfile}

执行脚本

$ cd ~/fisco/nodes/127.0.0.1 && bash check_seal.sh

社区¶

加入微众银行区块链社区¶

关于微众区块链开源的动态，社区活动，欢迎关注“微众区块链”公众号，不定期还有开源周边相送！(^▽^)

社区助手微信 ID : WeBank_Blockchain

_images/community_assistant.png

配置	开发（体验）环境	生产环境
CPU	1.5GHz * 2核	2.4GHz * 8核
内存	2 GB	8 GB
存储	40 GB	4 TB
带宽	1 Mb	10 Mb

区块链系统部署运维实践文档 | FISCO BCOS¶

文档介绍¶

认识区块链¶

文档版本¶

环境准备¶

操作要求和规范¶

文件操作¶

服务¶

网络¶

系统¶

硬件要求¶

推荐配置¶

预估硬件资源¶

开发（体验）环境¶

生产环境¶

容量预估¶

性能参考数据¶

磁盘类型¶

预估硬件资源¶

初始化系统环境¶

操作系统要求¶

检查系统环境¶

检查网络性能¶

配置防火墙¶

配置 DNS¶

配置 SSH¶

部署¶

概览¶

基本概念¶

部署流程¶

生产环境建议¶

机构节点数量¶

群组节点数量¶

备份¶

环境准备¶

选择版本¶

落盘加密¶

启用落盘加密特性¶

国密版本¶

源码编译¶

检查主机信息¶

部署区块链¶

开发（体验）环境¶

企业环境¶

开发者工具部署 和 WeBASE-Docker¶

运维工具部署（generator）¶

单机构部署¶

多机构对等部署¶

验证部署结果¶

check_seal.sh 脚本验证¶

可视化 WeBASE-Front 验证¶

问题排查¶

部署合约¶

控制台（console）¶

SDK¶

可视化（WeBASE-Front）¶

监控¶

日志说明¶

WeBASE-Front 监控示例¶

监控脚本¶

常见告警信息¶

常见日志¶

运维管理¶

压力测试¶

安全控制¶

节点准入¶

CA黑白名单¶

基于表的权限控制¶

基于角色的权限控制¶

新增机构¶

群组管理¶

节点管理¶

节点加入网络¶

节点加入群组¶

节点退出群组¶

节点退出网络¶

节点升级¶

升级方式¶

升级流程¶

节点迁移¶

开发者工具部署和 WeBASE-Docker¶

Ubuntu（Debian）安装 Java¶

开发工具和 WeBASE-Docker 部署详细操作¶