1.1 集群简介

集群（cluster）就是将多个相同的工程集中起来提供同一种服务，这些单个的工程就是集群的节点（node）。基于集群的横向扩展性，用户可通过增加节点数量使并发趋于线性增长，从而获得较高的并发支撑性能。

同时也可以用多个工程做备份，避免单机不可用导致系统停止造成的损失（业务中断、数据/模板丢失），确保系统 7*24h 稳定运行。

视频链接：【集群原理介绍】   

1.2 集群架构

如下图所示：

1.3 集群优势

1）高可用性

• 无主机模式，某一节点宕机后集群系统仍可正常提供服务。

• 节点宕机后，自动切换其他节点，已登录的用户无需重新登录。

2）高并发

同一个时间点，服务器响应了多个请求。比如 11:01:00 存在请求 A，11:01:03 服务器处理结束，如果 11:01:02 增加一个请求B、11:01:04 增加一个请求 C，此时的并发是 2（请求 A 和请求 B ）。

节点数量越多，支持的并发越高。由于并发是根据用户的实际业务场景，查看模板和制作模板，占用的服务器资源是不一样的。所以实际的服务器资源并发数量与业务使用情况有关，需要帆软专业的性能测试，结合实际的网络环境、文件读写效率、数据库并发性能等因素，得出实际能够支持的并发大小。

并发和容器没有关系，比如 Tomcat 、WebLogic、WebSphere 容器，并发相差不大。

3）高一致性

• 各节点间平台配置信息和资源文件修改更新能够实时同步。
  

• 对于节点间JAR包不一致情况，启动时可自动检测对比并提醒。

4）强扩展性

基于良好的架构设计，Web集群具有良好的横向扩展性，通过增加节点数量使并发趋于线性增长，从而获得较高的并发支撑性能。

5）使用简单

• 简单可视化配置，80% 的配置都可在平台上完成。
  

• 支持热部署，增加删除节点无须重启集群，只需要拷贝节点文件即可。

• 实时监控各节点的运行状态，对于节点宕机、节点间时间不一致等情况可以及时进行提醒。

帆软集群方案对于 Windows 系统和 Linux 系统均能支持。但考虑到稳定性和性能情况，推荐选用 Linux 系统作为服务器的操作系统。下面简单介绍 Linux 系统作为服务器操作系统对比：

• Linux 系统稳定性极佳，大部分硬件和配置更新无需重启。

• Linux 系统相对 Windows 系统，宕机机率更低，常常一年都不用关机。

• Linux 系统处理多线程比 Windows 要好的多，是真正的多用户多线程，而 Windows 是单用户伪多线程。

• Linux 系统不像 Windows 系统必备图形化操作界面，因此占用资源会少一些，性能也更好。

• 内存管理和调度方式优秀，有效利用一切硬件资源。

但是影响我们最终哪种系统的因素，还有一个最关键的点——运维能力，如果公司不具备 Linux 系统的运维能力，那只能选择Windows 系统了。

负载均衡分为软件负载均衡和硬件负载均衡，两种负载均衡核心作用是一样的，负载均衡作为集群的入口，起到请求分发和节点健康检查的作用。

注：不支持 Apache 负载均衡。

3.1 硬件负载均衡

硬件负载均衡很稳定，性能也相对较好，但是成本也高，最常用的负载均衡就是 F5 。若公司有硬件负载均衡且具备较好的配置和运维能力，确认硬件负载均衡具备主动健康检查功能后，即可选择使用硬件负载均衡。

简单介绍一下硬件负载均衡的优缺点：

• 优点：能够直接通过智能交换机实现,处理，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用。

• 缺点：成本高，除设备价格高昂，而且配置冗余．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态。

使用文档：负载均衡配置指导

3.2 软件负载均衡

简单介绍一下软件负载均衡的优缺点：

• 优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果只有几台服务器，用 F5 之类的硬件产品显然有些浪费，而用软件就要划算的多，因为服务器同时还可以跑应用做集群（虽然不太推荐），或者仅提供一般配置的服务器来给负载均衡应用。

• 缺点：负载能力会受服务器本身性能的影响。

帆软官方验证过的软件负载均衡有两种：Traefik 和 Nginx，两种均为开源软件，更新频率和维护力度稳定，下面说一下两个负载均衡的适用场景。

3.2.1 Nginx

Nginx 作为负载均衡在 Linux 系统上具备很好的并发性能，并且占用极小的内存。许多大公司都在用，稳定性和性能是经过充分验证的。但是在 Windows 系统上并不支撑较高并发，所以在 Windows 系统上选用 Nginx 作为负载均衡，需要考虑并发情况，若并发需求低于 200，部署集群仅以热备为目的，则可选用 Nginx 作为负载均衡，若并发需求超过 200 ，则不建议使用Nginx，须换用其他负载均衡。

如果希望 Nginx 层面也具备高可用性，避免单点故障，那么可以再做一个 Keepalived+Nginx 方案，确保一个 Nginx 服务宕机或异常后，有备用的 Nginx 服务可以接手。

使用文档：Linux 系统安装配置 Nginx、Windows系统安装配置Nginx、Keepalived+Nginx部署方案

3.2.2 Traefik

Traefik 是 Go 语言编写的单一可执行文件，无需安装，只要在命令行里执行即可，部署和使用非常简单，适用于对运维能力要求不高的用户使用。和 Nginx 相比，有两大优点：

• 在 Windows 系统上具备良好的性能，因此 Windows 系统推荐使用 Traefik 。

• 支持自动化更新反向代理和负载均衡配置。

使用文档：windows系统安装配置Traefik

Nginx 在 Linux 系统下的性能和稳定性、Traefik 在 Windows 系统下的性能和稳定性，帆软都已经进行了测试和验证。理论上Traefik 在 Linux 系统上也具备较好的性能，但是为了避免方案的繁杂以及考虑维护成本，未对 Traefik 在 Linux 系统上的性能和稳定性做充分的验证。

总的来说，Linux 系统推荐选用 Nginx 作为负载均衡，Windows 系统不建议选择 Nginx ，推荐选用 Traefik 。

Web容器是一种服务程序，是能够支持发布Web程序的软件，在服务器一个端口就有一个提供相应服务的程序，而这个程序就是处理从客户端发出的请求。

常规推荐：Tomcat 容器、WebLogic 容器、WebSphere 容器。

帆软集群方案里，状态服务器是用 Redis 实现的，常用的 Redis 方案有 Redis 单机、Redis 集群、Redis 哨兵三种，这里对如何选择三种方案进行介绍。

如果公司已有 Redis 服务，不管是下面哪一种，都可以直接使用，这样可以减少额外维护一个应用的成本，但是如果没有 Redis 服务，我们为了使用集群，就要新安装 Redis 服务了。

5.1 Redis单机

Redis 单机指的是只部署一个 Redis 应用，此种方案简单易部署，运维成本低，能够保证集群的可用性。

使用文档：Linux 系统安装配置单机 Redis

5.2 Redis集群

如果对于系统/方案的高可用性要求高，希望能够避免单点故障，那么 Redis 集群可以很好地满足需求。

5.2.1 架构介绍

Redis 集群结构是 N 个平权主节点（master），每个主节点对应 M 个从节点（slave），由于 Redis 集群的投票机制，N 须为奇数，且必须大于等于 3 ，否则创建集群时会失败。

业界经过大量检验最常用的 Redis 集群架构是 3 主 3 从。

5.2.2 资源需求

部署 3 主 3 从的 Redis 集群时，建议至少主从 3 台服务器，主从节点在构建 Redis 集群时会进行随机分配。

如果想要达到更加极致的高可用，避免主节点和从节点刚好分配到一台机器并且遇到服务器宕机导致整个 Redis 集群不可用的情况发生，可以准备 6 台服务器来做 3 主 3 从的 Redis 集群，这样任何一台服务器宕机都不会影响 Redis 集群对外提供服务。

5.2.3 优缺点说明

优点：

• 主节点宕机后，基于投票机制从节点可自动上升为主节点，可让 Redis 服务更加高可用。

• 数据分区存储在不同的主节点上，可以大幅度提升 Redis 服务的性能支撑。

缺点：

• 由于数据分区存储，所以当一个主节点及其对应的从节点全部宕机后，整个 Redis 集群将不能使用。

• 当存活的主节点数小于总节点数的一半时，整个 Redis 集群也会无法提供服务。

• 不管是 3 台服务还是 6 台服务器，我们都能感受到 Redis 集群对资源的要求是比较多的，且运维成本也会比 Redis 单机更高。

使用文档：linux系统安装配置Redis集群

简单总结，Redis 集群方案可以让 Redis 服务更加高可用，但是运维和资源成本更高，建议选择时仔细考虑。

5.3 Redis哨兵

5.3.1 架构介绍

Redis 哨兵模式是基于 Redis 主从模式的方案，Redis 2.8 及以后版本提供了哨兵工具来实现自动化的系统监控和故障恢复功能。哨兵的作用就是监控 master、slave 是否正常运行，master出现故障后自动将 slave 转换为 master。

建议至少使用 2 个哨兵（因为哨兵模式中将主服务器判断为失效至少需要 2 个 Sentinel 同意，所以至少要部署两个及以上的Sentinel ），

最常用的 Redis 哨兵方案为 1 主 2 从 3 哨兵，能够做到较好的高可用。

5.3.2 资源需求

可以将主节点、从节点、哨兵节点部署在一台或多台服务器上，但是和 Redis 集群一样，如果我们想要达到极致的高可用，避免一台服务器宕机就导致整个 Redis 服务不可用，那么就把每个节点部署在一个独立的服务器上。

5.3.3 优缺点说明

优点：

• 主从可以自动切换，故障可以转移，系统可用性更好。

• 哨兵模式是主从模式的升级，系统更健壮，可用性更高。

缺点：

• 不能支持高并发，能提供写入功能的也就只有主节点。

简单总结，Redis 哨兵模式也可以让 Redis 服务更加高可用，但是也是比较耗费运维和资源的，而且与 Redis 集群相比最大的缺点就是性能和单机一样，无法提升 Redis 服务的性能。

集群一致性里有一个很关键的点就是文件一致性，帆软提供了多种方案来保障节点间资源文件的一致性。我们可以基于运维能力，实际场景来进行选择。

6.1 节点间同步

节点间同步是保障节点间资源文件一致性的最简单的方案了。

优点：

• 无须开启文件服务器，无须做任何配置即可使用，无运维成本，使用成本很低。

• 各个节点均存储有文件，因此可以达到热备的效果，具备高可用性。

缺点：

• 节点间同步方案不适用于多节点，建议仅在使用两节点时选用节点间同步方案，因为节点越多，由于通信和同步效率等原因，可能会同步失败或者由于同步不及时影响使用。

简单总结，节点间自动同步的方案能够满足双机热备的需求，运维和使用成本很低，无须额外维护组件，但是不适用于多节点，建议仅在两个节点时选用。

注：10.0.5 版本即 2020-04-26 发布的10.0 中已经可以满足节点间能够同步空文件夹，且从 Nginx 入口进行远程设计不会出现文件夹消失的情况。

6.2 文件服务器

帆软支持多种文件服务器，下面会对各个类型的文件服务器优缺点进行说明。

6.2.1 共性优缺点

先说明一下文件服务器共性的优缺点，共性优缺点指不管选择哪种文件服务器，都具备的。

优点：

• 文件一致性高，由于各个节点都是从同一个文件服务器读取资源文件，不涉及到同步，各个节点读取的资源文件永远会保持一致性。

• 适用于多节点、超多节点的场景。

缺点：

• 使用成本比节点间同步高，由于额外使用一个组件，导致部署运维成本会略高一些，需要更多的资源支撑这些组件。

6.2.2 特性优缺点

使用文档：Linux 系统安装配置 FTP、Windows系统配置FTP服务、Linux 系统配置使用 SFTP、HDFS 资源仓库

总结一下，当我们有超过2个节点时，为了保证各个节点文件的高一致性，建议使用文件服务器。基于高可用性、性能需求，以及公司实际的情况（是否已有文件服务器），再选择对应的文件服务器。

2019-11-08 号的 JAR 包增加了缓存模式，前端可进行选择，缓存和文件服务器搭配使用时可以增加文件服务器的高可用性，下面介绍一下如何选择。

7.1 缓存功能

缓存的资源文件：包含报表文件、仪表板文件、配置文件、地图数据等，目前是"reportlets/" ,"resources/", "assets/"，"dashboards"四个文件夹。

主动缓存：缓存所有资源文件。

被动缓存：仅对访问到的资源文件进行缓存。

7.2 缓存作用

优点：

• 提高文件服务器的高可用性，若使用文件服务器时开启了缓存，当文件服务器宕机时，系统从缓存中读取资源文件，仍可正常对外提供服务。

• 提高工程的性能，无法充分从节点下或者文件服务器中读取文件，可大幅提高模板的访问性能。

缺点：

• 缓存会占用系统内存资源。

总结一下，开启缓存功能可以大幅提高工程的性能，并且配合文件服务器使用时，可提高系统的高可用性，建议使用文件服务器时开启缓存。

外置数据库在集群方案里也是很关键的点，由于各个节点均使用同一个外置数据库，因此节点间的配置可以保持一致性。 FineReport 和 FineBI 对常用的数据库都可以支持，包括 MySQL 、SqlServer、Oracle、DB2，这里不作详细介绍。若公司已有数据库服务，数据库版本符合帆软的要求则可直接使用，若需要新部署数据库服务，则建议部署mysql，部署比较简单。

使用文档：配置外接数据库

帆软集群支持 TCP 和 UDP 两种通信协议，目前默认是 TCP 协议，下面列举两种协议的区别：

其中需要注意的是，大部分云服务器（阿里云、亚马逊云等）都不支持UDP协议，因此只能选择TCP协议。

若服务器对TCP/UDP协议均支持，当节点数较少时选择TCP/UDP协议差异不大， 当节点数较多时，建议选择UDP协议，通信效率更高。