概述
本文简单介绍：
1）工程部署的必要性/部署原理
2）单机和集群的简介/区别/适用场景/组成部件
3）各种部署方式的区别，什么是容器化部署？
工程部署原理
为什么不能直接用设计器，而需要在服务器部署工程？
问题：既然 FineReport 官网提供的设计器可以直接使用，为什么还需要在服务器端部署报表工程呢？
答案：官网提供的设计器内置了 Tomcat 服务器，所以可以直接使用。但是每个设计器都对应了一个本地工程，大家无法共用同一个工程。
而对于正式的企业工程，需要让多个操作员使用不同的设计器连接到同一个工程，并让多个查看者能够在不同的电脑上访问数据决策系统。
因此，需要在服务器上部署工程，来确保不同的操作员可以通过远程设计器连接到工程，同时也确保不同的查看者可以在各自的电脑终端上访问工程。
注意：请勿在设计器中运行正式工程，建议将工程部署在服务器中，使用设计器远程连接为佳。
为什么推荐将工程部署在中间件中？
中间件是位于操作系统和应用程序之间的软件层，用于支持应用程序之间的通信和交互。
为了实现报表工程的更好可用性和稳定性，通常会将FineReport部署在中间件中。
部署在中间件中可以提供以下优势：
应用服务器可以提供更好的安全性：应用服务器可以对传输协议和Web安全性进行控制和管理，可以使用HTTPS协议等加密协议来保证数据传输的安全性。
应用服务器可以提供更好的性能：应用服务器可以对请求进行负载均衡，以确保系统在高负载时仍然能够高效地运行。
应用服务器可以提供更好的扩展性：使用应用服务器可以方便地扩展系统，并为不同的应用程序提供专用资源，从而确保应用程序的稳定性。
应用服务器可以提供更高的可用性：应用服务器可以提供高可用性和容错机制，以最大化系统的可用性。
因此，将FineReport部署在中间件中可以提供更好的安全性、性能、扩展性和可用性，从而确保报表工程的稳定性和高可用性。
服务器工程的运作原理
服务器中工程部署的原理就是将 FineReport 报表工程部署到 Web 应用服务器端。
用户在客户端产生一个报表查看请求，发送给 Web 应用服务器端。
Web 应用服务器将 FineReport 报表的计算结果反馈给客户端。
FineReport 在计算报表结果时会涉及到数据库的读写操作。
集群与单机
什么是集群和单机？
单机
就是一个部署好的工程。
集群
集群（cluster）就是将多个相同的工程集中起来提供同一种服务，这些单个的工程就是集群的节点（node）。
基于集群的横向扩展性，用户可通过增加节点数量使并发趋于线性增长，从而获得较高的并发支撑性能。
同时也可以用多个工程做备份，避免单机不可用导致系统停止造成的损失（业务中断、数据/模板丢失），确保系统 7*24h 稳定运行。
集群的优势
帆软集群具有高可用性、高性能、易于管理、可伸缩性和安全保障等优点，适用于企业级的报表生成和管理需求，可以帮助企业更好地管理和控制报表数据的存储、生成、共享等方面的性能和效果。
| 优势 | 说明 |
|---|---|
| 高可用性 | 帆软集群通过集群节点、负载均衡器、状态服务器等多个组件协同工作，有多个节点来分担处理请求的负荷。 当集群节点发生故障时，负载均衡器会自动将请求转发到其他可用节点，保证系统的高可用性。 |
| 高并发 | 帆软集群允许并行处理多个报表生成和数据计算任务，通过多个节点从而实现任务的分布式处理。 通过集群的横向扩展，实现数据计算与报表生成的加速，从而提高整体的性能。 节点数量越多，支持的并发越高。 |
| 易于管理 | 帆软集群提供了完整的管理平台，包括集群节点的监控、配置、部署和故障自动修复等功能，可以大大降低集群维护和运维的难度和风险，帮助企业更好地管理和维护系统。
|
| 强扩展性 | 基于良好的架构设计，Web集群具有良好的横向扩展性，帆软集群可以快速增加集群节点的数量，使并发趋于线性增长，以应对高峰期和流量波动，做到系统的可伸缩性和高效性。 |
集群和单机的区别/集群解决什么问题？
当我们把集群和单机比作一组出租车承接客人的话，它们的区别可以这样解释：
1）解决高负载问题
单机就像是一辆出租车，它可以接受乘客的订单，但是如果订单请求变得非常多，该出租车的服务能力可能无法满足，并可能会出现性能瓶颈。
此时，你需要多辆出租车来分担订单处理工作。而这些出租车可以被组成为一个出租车队的形式称之为集群。
这样，您可以将乘客分配到不同的车辆中，并将他们同时送到目的地，从而提高服务效率。
2）解决高可用问题
但是，仅仅增加车辆的数量只能解决工程高负载问题，并不足以保证高可用性。
您还需要一个良好的车队管理系统来确保每辆车都可以顺利地运行，并提供相同的服务质量和客户体验。
在集群设计中，这意味着您需要将多个服务器组合在一起，以实现负载均衡、配置信息数据库、状态服务器和文件服务器等功能。
这些组件可以确保整个集群的高可用性，并提供稳定的服务。
3）总结
集群和单机的主要区别在于共享资源和协作工作。
集群中，多个工程相互通信共享数据和任务，可以提供更好的可扩展性和更高的性能。
单机中，所有的资源都被独占使用，没有扩展性和动态性可言。
总之，集群设计是一种有效的解决方案，可以提高系统的负载能力和可用性，并确保系统的稳定性和一致性。
集群为什么需要多类组件？
在搭建集群时，需要注意到这不是一件轻松简单的事情。
为了提供无缝丝滑的服务，必须提高服务质量并组建一个优秀的车队。
我们需要考虑如何构建一个良好的车队，这是集群架构需要解决的问题。
| 组件 | 说明 |
|---|---|
| 工程节点 | 集群节点就是一辆辆出租车。 当某个出租车出现了故障，会自动安排其他出租车来代替它的工作，以确保整个车队仍然正常工作。 帆软集群设计避免了主节点的概念，只将第一个加入集群的节点作为基准节点。每个节点都平等地提供服务和进行管理操作。 每个节点都是一个可以独立运行的工程，负责处理用户的请求，处理生成报表的任务和管理其他组件的工作。集群节点间通过一系列的网络协议和服务进行通信和协作。 |
| 负载均衡 | 负载均衡就像出租车队的调度中心，用于协调和分配所有的工作和请求。 在接待客户时，负载均衡作为统一入口，负责对接客户，不需要让客户一个个询问司机。 在集群中，负载均衡用于分配任务到各个节点上，使它们能够更高效地工作。 负载均衡器会在所有节点之间平衡负载，确保每个节点都分配到足够的任务并保持忙碌状态。 |
| 外接数据库 | 配置库，即外接数据库FineDB，类似于出租车队的车管所。 它存储并维护所有车辆和司机的信息，为每个司机提供相同的车辆装饰、报价、出行路线等信息。让每一辆车都给顾客提供一致的出行体验。 在集群中，配置库用于存储和维护所有节点的配置信息和参数，这些参数是为了使集群节点协调工作而必须合理设置的。 |
| 状态服务器 | 状态服务器就像出租车队的管理中心。 它负责监控和维护车队的整体状态，包括车辆和司机的位置，以及服务进度。 在集群中，状态服务器也执行相似的任务。它监控每个节点及整个集群的运行状态、记录日志和错误信息、协调节点间的通信和任务分配等。 |
| 文件服务器 | 文件服务器类似于出租车队的存储仓库。 它存储所有与车队相关的文件，包括车辆维护记录、保险单、车辆位置数据等。 在集群中，文件服务器用于存储和共享集群中所需的文件和数据资源，以确保每个节点都可以访问并使用它们。 |
帆软集群的架构非常灵活，可以根据不同的业务需求和特点进行配置。想要开启集群必须至少满足以下条件：
1）有1个以上工程节点
2）节点配置了外接数据库
3）节点配置了状态服务器
4）如果有2个以上工程节点，则必须配置文件服务器
容器化部署与传统部署
什么是容器化部署和传统部署？
传统部署：
用户可以自行准备，或使用帆软封装的部署包，搭建最普通的工程架构，即「FineReport工程+jdk环境+tomcat中间件」
容器化部署：
将应用“容器化”的过程，就是让应用能够运行在 Docker 容器或类似技术中，它们能将操作系统环境和应用封装在一起（完整的系统镜像）。
由于容器能给应用提供近似于完整系统的环境，这就为在不修改，或者少量修改应用的情况下，对应用的部署进行现代化改造提供了一种思路。
这也是应用的架构持续能保持“云友好”的基础。
容器化部署的优势
相比于传统部署架构，容器化部署可大幅降低客户的维护成本和资源成本。
1）维护成本低
每个工程的环境相互隔离，出现异常时影响范围小。
升级、灾备、回滚方便。
2）资源成本低
多集群管理、多租户、微服务化，更高资源使用率。
资源弹性伸缩。
容器化部署和传统部署的区别
容器在整个应用程序生命周期工作流中提供以下优点：隔离性、可移植性、灵活性、可伸缩性和可控性。
最重要的优点是可在开发和运营之间提供隔离。
| 对比项 | 传统方式部署 | 容器化部署 |
|---|---|---|
| JVM初始配置 | 需要自行手动修改 Tomcat 配置文件或其他容器对应配置文件 大部分用户可能不会完全配置，导致后续业务上出现异常 | 默认已经在镜像中配置好了常用的所有jvm参数，避免大多jvm参数造成的问题 yaml文件中可以单独配置Xmx内存上限 |
| 负载均衡 | 需要单独安装 Nginx 或其他负载软件，并进行转发配置 存在用户可能缺少很多配置，导致某些业务出现异常 可以根据需要配置keepalived+nginx的高可用架构 | 一键部署时，默认自动安装好nginx且已自动配置好（不支持其他负载） 避免因客户自行配置错误或缺失导致的问题 |
| 硬件要求 | 虽然有推荐，但没有强制 | 强制要求所有节点至少500G磁盘空间和16G内存 防止在不适合的硬件环境中部署工程，埋下隐患 |
| 组件要求 | 没限制，所有产品支持的组件都可以配置 | 没限制，所有产品支持的组件都可以配置 同时支持mysql、redis和minio的部署 |
| 操作系统要求 | 基本无限制 | 支持 amd64 架构的 Linux 系统 centos7.3 以下版本不支持 ubuntu18 以下版本不支持 防止因操作系统版本过低，导致工程运行出现问题 |
| 防火墙要求 | 需要对应服务器开放使用到的端口即可 | 必须开放所有节点所有组件使用的端口，否则无法部署 确保不因端口问题导致工程运行异常 |
| 单机部署 | 不配置外置库和其他组件的情况，上传部署包直接启动即可 否则需要单独配置外置库和组件以及需要的环境、如jdk | 本机root用户可以一键部署 支持在yaml文件中配置相关节点和组件信息后部署 支持通过yaml文件配置用户原有的组件 |
| 权限要求 | 需要保证文件权限 | 普通用户需要sudo权限（已经安装好docker，且用户属于docker用户组则无需权限） cp tar rm groupadd gpasswd groups dockerd systemctl（docker服务开机自启需要，不强制） |
| web容器配置修改 | 修改如tomcat目录下的配置文件后重启tomcat | 可以通过运维平台实现前端修改 |
| jvm参数修改 | 直接修改对应文件即可 | 可以通过运维平台实现前端修改 |
| 环境影响 | 使用受到各种环境影响，如：jdk、glibc、系统字体、系统语言、系统时间等都可能造成某些业务问题 | FR/BI应用都使用docker容器部署，环境统一，只要能支持部署，基本没有环境影响 |
