概述
本文简单介绍：
1）工程部署的必要性/部署原理
2）单机和集群的简介/区别/适用场景/组成部件
3）各种部署方式的区别，什么是容器化部署？
工程部署原理
为什么不能直接用本地FineBI，而需要在服务器部署工程？
问题：既然用户可以直接在自己电脑端安装 FineBI ，为什么还需要在服务器端部署FineBI工程呢？
答案：对于正式的企业工程，需要让多个操作员连接到同一个工程，并让多个查看者能够在不同的电脑上访问同一个系统。
因此，需要在服务器上部署工程，来确保不同的操作员和查看者可以在各自的电脑终端上访问工程。
为什么推荐将工程部署在中间件中？
中间件是位于操作系统和应用程序之间的软件层，用于支持应用程序之间的通信和交互。
为了实现工程的更好可用性和稳定性，通常会将FineBI部署在中间件中。
部署在中间件中可以提供以下优势：
应用服务器可以提供更好的安全性：应用服务器可以对传输协议和Web安全性进行控制和管理，可以使用HTTPS协议等加密协议来保证数据传输的安全性。
应用服务器可以提供更好的性能：应用服务器可以对请求进行负载均衡，以确保系统在高负载时仍然能够高效地运行。
应用服务器可以提供更好的扩展性：使用应用服务器可以方便地扩展系统，并为不同的应用程序提供专用资源，从而确保应用程序的稳定性。
应用服务器可以提供更高的可用性：应用服务器可以提供高可用性和容错机制，以最大化系统的可用性。
因此，将FineBI部署在中间件中可以提供更好的安全性、性能、扩展性和可用性，从而确保工程的稳定性和高可用性。
服务器工程的运作原理
服务器中工程部署的原理就是将 FineBI 工程部署到 Web 应用服务器端。
用户在客户端产生一个查看请求，发送给 Web 应用服务器端。
Web 应用服务器将FineBI的计算结果反馈给客户端。
FineBI在计算结果时会涉及到数据库的读写操作。
集群与单机
什么是集群和单机？
单机
就是一个部署好的工程。
集群
集群（cluster）就是将多个相同的工程集中起来提供同一种服务，这些单个的工程就是集群的节点（node）。
基于集群的横向扩展性，用户可通过增加节点数量使并发趋于线性增长，从而获得较高的并发支撑性能。
同时也可以用多个工程做备份，避免单机不可用导致系统停止造成的损失（业务中断、数据/模板丢失），确保系统 7*24h 稳定运行。
集群的优势
帆软集群具有高可用性、高性能、易于管理、可伸缩性和安全保障等优点，适用于企业级的报表生成和管理需求，可以帮助企业更好地管理和控制报表数据的存储、生成、共享等方面的性能和效果。
| 优势 | 说明 |
|---|---|
| 高可用性 | 帆软集群通过集群节点、负载均衡器、状态服务器等多个组件协同工作，有多个节点来分担处理请求的负荷。 当集群节点发生故障时，负载均衡器会自动将请求转发到其他可用节点，保证系统的高可用性。 |
| 高并发 | 帆软集群允许并行处理多个仪表板生成和数据计算任务，通过多个节点从而实现任务的分布式处理。 通过集群的横向扩展，实现数据计算与仪表板生成的加速，从而提高整体的性能。 节点数量越多，支持的并发越高。 |
| 易于管理 | 帆软集群提供了完整的管理平台，包括集群节点的监控、配置、部署和故障自动修复等功能，可以大大降低集群维护和运维的难度和风险，帮助企业更好地管理和维护系统。
|
| 强扩展性 | 基于良好的架构设计，Web集群具有良好的横向扩展性，帆软集群可以快速增加集群节点的数量，使并发趋于线性增长，以应对高峰期和流量波动，做到系统的可伸缩性和高效性。 |
集群和单机的区别/集群解决什么问题？
当我们把集群和单机比作一组出租车承接客人的话，它们的区别可以这样解释：
1）解决高负载问题
单机就像是一辆出租车，它可以接受乘客的订单，但是如果订单请求变得非常多，该出租车的服务能力可能无法满足，并可能会出现性能瓶颈。
此时，你需要多辆出租车来分担订单处理工作。而这些出租车可以被组成为一个出租车队的形式称之为集群。
这样，您可以将乘客分配到不同的车辆中，并将他们同时送到目的地，从而提高服务效率。
2）解决高可用问题
但是，仅仅增加车辆的数量只能解决工程高负载问题，并不足以保证高可用性。
您还需要一个良好的车队管理系统来确保每辆车都可以顺利地运行，并提供相同的服务质量和客户体验。
在集群设计中，这意味着您需要将多个服务器组合在一起，以实现负载均衡、配置信息数据库、状态服务器和文件服务器等功能。
这些组件可以确保整个集群的高可用性，并提供稳定的服务。
3）总结
集群和单机的主要区别在于共享资源和协作工作。
集群中，多个工程相互通信共享数据和任务，可以提供更好的可扩展性和更高的性能。
单机中，所有的资源都被独占使用，没有扩展性和动态性可言。
总之，集群设计是一种有效的解决方案，可以提高系统的负载能力和可用性，并确保系统的稳定性和一致性。
集群为什么需要多类组件？
在搭建集群时，需要注意到这不是一件轻松简单的事情。
为了提供无缝丝滑的服务，必须提高服务质量并组建一个优秀的车队。
我们需要考虑如何构建一个良好的车队，这是集群架构需要解决的问题。
| 组件 | 说明 |
|---|---|
| 工程节点 | 集群节点就是一辆辆出租车。 当某个出租车出现了故障，会自动安排其他出租车来代替它的工作，以确保整个车队仍然正常工作。 帆软集群设计避免了主节点的概念，只将第一个加入集群的节点作为基准节点。每个节点都平等地提供服务和进行管理操作。 每个节点都是一个可以独立运行的工程，负责处理用户的请求，处理生成报表的任务和管理其他组件的工作。集群节点间通过一系列的网络协议和服务进行通信和协作。 |
| 负载均衡 | 负载均衡就像出租车队的调度中心，用于协调和分配所有的工作和请求。 在接待客户时，负载均衡作为统一入口，负责对接客户，不需要让客户一个个询问司机。 在集群中，负载均衡用于分配任务到各个节点上，使它们能够更高效地工作。 负载均衡器会在所有节点之间平衡负载，确保每个节点都分配到足够的任务并保持忙碌状态。 |
| 外接数据库 | 配置库，即外接数据库FineDB，类似于出租车队的车管所。 它存储并维护所有车辆和司机的信息，为每个司机提供相同的车辆装饰、报价、出行路线等信息。让每一辆车都给顾客提供一致的出行体验。 在集群中，配置库用于存储和维护所有节点的配置信息和参数，这些参数是为了使集群节点协调工作而必须合理设置的。 |
| 状态服务器 | 状态服务器就像出租车队的管理中心。 它负责监控和维护车队的整体状态，包括车辆和司机的位置，以及服务进度。 在集群中，状态服务器也执行相似的任务。它监控每个节点及整个集群的运行状态、记录日志和错误信息、协调节点间的通信和任务分配等。 |
| 文件服务器 | 文件服务器类似于出租车队的存储仓库。 它存储所有与车队相关的文件，包括车辆维护记录、保险单、车辆位置数据等。 在集群中，文件服务器用于存储和共享集群中所需的文件和数据资源，以确保每个节点都可以访问并使用它们。 |
帆软集群的架构非常灵活，可以根据不同的业务需求和特点进行配置。想要开启集群必须至少满足以下条件：
1）有1个以上工程节点
2）节点配置了外接数据库
3）节点配置了状态服务器
4）如果有2个以上工程节点，则必须配置文件服务器
抽取集群与直连集群
什么是抽取集群和直连集群？
直连集群：
FineBI工程中只使用直连数据，不使用抽取数据
抽取集群：
FineBI6.0工程，全新部署集群，工程中使用了抽取数据。
FineBI5.x热备工程升级FineBI6.0，升级后取消热备，建议调整为抽取集群
抽取集群的优势
1）业务高可用
方案特性：
集群由多个同步节点和非同步节点组成，只要还有一台同步节点存活，就能够提供完整的数据，保证数据查询高可用性。
当数据更新在执行过程中出现异常（宕机或节点假死），则通过恢复机制，将正在进行的任务重新恢复为执行前的状态，并重新执行，以保证更新业务的高可用。
特性表现：
与热备相比，抽取集群中节点宕机时不再会有节点切换的耗时，降低了不可用的时间。
此外，6.0集群还支持更新业务的高可用，提供更新任务的异常恢复机制。
2）查询高并发
方案特性：
多台节点同时提供查询服务，实现负载均衡，查询并发量随节点数量近似线性提升，提供可横向扩展的查询能力。
特性表现：
抽取集群的查询，达到了真正的负载均衡，且并发性能可以随节点增加而线性增加。
抽取集群方案并不优化单个节点的并发数，而是优化整体。
抽取集群方案的性能提升，随节点数增加非整倍的提升，会有一定的衰减。
注：下表用六种情况，展示在不同节点和并发数下，查询性能的表现。这些情况仅作为测试用例，实际部署中节点数不推荐超过5，并发数不止支持140。
实际配置中，需要根据用户使用高频场景（查看仪表板/自助分析），来选择最优节点数，详情请参见：工程部署方案选择
| 节点数-并发数 | 相比单机，性能提升的倍数 |
|---|---|
| 单节点-10并发 | - |
| 4节点-40并发 | 3.6 |
| 7节点-70并发 | 6.7 |
| 单节点-20并发 | - |
| 4节点-80并发 | 3.6 |
| 7节点-140并发 | 6.1 |
3）提升更新吞吐量
方案特性：
可以通过增加节点的方式来提高更新性能，更新耗时随节点数变多呈现非线性降低的趋势。
特性表现：
多表更新任务的更新性能，随节点数变多，呈现非线性地先提升后降低趋势（由于数据同步机制）。
抽取集群方案并不优化单个节点的更新性能和吞吐量，而是优化整体。
由于数据同步机制，单表更新在多节点的更新性能会比单节点有所下降。
由于数据同步机制，全局更新的性能提升，在4节点会相比于3节点有所下降。因此部署中节点数不推荐超过5（相比单机，提升幅度还算比较大）。
注：实际配置中，需要根据用户使用高频场景（查看仪表板/自助分析），来选择最优节点数，详情请参见：工程部署方案选择。
| 节点数 | 相比单机，全局更新性能提升的百分比 |
|---|---|
| 单节点 | - |
| 2节点 | 31% |
| 3节点 | 39% |
| 4节点 | 37% |
抽取集群的运作原理
1）更新调度
数据更新请求可以向所有节点均衡转发。
所有节点均可对更新任务进行预处理，将更新任务的信息存储到任务队列。
所有同步节点可领取数据集更新子任务，并进行实际的抽取。
数据集在某节点抽取完成后，会同步到其他同步节点，全部同步完成后，该数据集才视为更新完成。
2）数据同步
同步节点：
该类节点上的数据文件状态都保持最新，即保持数据强一致性。更新过程中，必须保证该类节点数据同步完成，才算更新成功。
该类节点是高可用的基本保障，也是查询和更新高并发的主力。
非同步节点：
6.0.8之前版本，该类节点是查询高并发的支撑。节点上的数据文件可以不是最新的，通过同步的机制，逐渐将该节点上的数据更新为同步节点一样的状态。
6.0.8及之后版本，该类节点是查询转发的支撑。节点作为不使用引擎功能的查询节点，本地不存储抽取数据，只做查询转发。
3）查询请求转发
数据查询请求可以向所有节点均衡转发；
若配置库返回的节点数据状态为最新状态，则由该节点处理请求；
6.0.8之前版本，若节点数据落后，则BI内部转发请求到最新数据的节点，并触发本节点的数据同步。
6.0.8及之后版本，所有请求都会转发到有最新数据的节点，不需要更新非同步节点的数据。
容器化部署与传统部署
什么是容器化部署和传统部署？
传统部署：
用户可以自行准备，或使用帆软封装的部署包，搭建最普通的工程架构，即「FineBI工程+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容器部署，环境统一，只要能支持部署，基本没有环境影响 |
