反馈已提交
网络繁忙
本文简单介绍：
1）FineBI6.1架构简介
2）FineBI6.1的优势说明
| 负载均衡网关 | 作用： 负载均衡网关，处于客户端和bi-web组件之间 它负责接收客户端的请求，并将这些请求分发到bi-web组件上 因此负载均衡必须要能访问每一个bi节点 优点（为什么需要负载均衡？为什么不能直接客户端到bi？）： 性能优化：智能分配请求到各个bi节点，防止服务器过载，提升效率 故障隔离：自动检测并排查故障bi节点，避免影响整体服务 安全增强：作为第一道防线，过滤和监控流量，防止恶意攻击 会话保持：负载均衡网关支持配置会话保持策略，确保用户请求连续性，保持会话状态 可扩展性：客户端只需要知道负载均衡网关地址，随业务增长，增加bi节点不影响客户访问地址 类型： 帆软项目内网关，对帆软业务进行了定制调整，以均衡的分发用户请求，提升性能，因此不支持自备 如需使用F5、SLB、ELB等其他类型的负载均衡网关，可以自行配置转发，让客户端请求转发到自备网关，再转发到帆软项目内网关，再分发到各个bi节点上 |
| bi节点 | bi节点，切分为两层：网络转发层、业务处理层 网络转发层（怎么确保单个用户的业务，能被同一个节点连续的处理掉？）： 由于可能存在多个bi节点，必须确保单个用户的请求能被同一个bi节点持续处理，因此在客户端与bi节点建立连接时，会生成一个唯一的session ID 后续该客户端的请求无论被转发到了哪个bi节点，都可以根据session ID识别，并将请求转发到首次接待的bi节点，以保持会话状态，确保服务的一致性 业务处理层： 用于处理客户端的请求，包括平台的功能、前端界面渲染等。 在处理请求的过程中，如果涉及到数据更新或计算，这些任务将被智能分配给后端引擎worker |
| 引擎master | 引擎master，有两个作用：存储和提供worker信息、存储元数据 存储和提供worker信息（bi节点的任务是直接分配到worker的嘛？答案：是，但不完全是）： 当bi节点需要进行数据更新和计算时，任务会被智能分配给引擎worker来执行。 但是，引擎worker是无状态服务，这意味着它们不负责存储任何持久化的数据（可以想象成worker没有固定的"身份证"），因此bi节点无法直接识别或联系到任何一个引擎worker。 此时，bi节点会先与引擎master进行通信，引擎master负责动态地为bi节点提供一个可用的worker地址，这个地址是随机分配的，专门用于完成当前的任务。 一旦bi节点从引擎master获取到了引擎worker的地址信息，它就能够将任务顺利地分发给相应的引擎worker，确保数据处理和计算工作的顺利进行。 存储元数据（worker是怎么从数据存储组件里取数的？） 元数据，也就是每个bi数据表的信息（并非bi数据表中的数据），比如bi某个数据表的表名称、字段名、存储在数据存储组件的哪个位置 这些元数据存储在master组件的挂载目录下，即存储在服务器磁盘里 当worker需要从数据存储组件取数计算/更新数据时，需要先找master得到这些数据表的元数据，然后worker才能正确的找到所需要的各个表，并完成工作 |
| 引擎worker | worker分为两个部分：探活monitor和引擎worker 引擎worker： 用于执行bi节点分发的数据更新和计算任务。 默认情况下，每个引擎worker既可以执行数据更新，也可以执行数据查询计算任务 什么是读写分离？什么情况下配置？ 正式业务系统，往往白天工作时间进行业务数据查询计算，夜晚下班时间进行数据更新。 那么在白天如果有数据更新，不能占用查询的资源；在夜晚如果有数据计算，不能占用更新的资源。 此时可以对引擎worker进行属性配置，让部分节点在指定时间段内专注进行某一件事（即读写分离）。 探活monitor（为什么master和worker的重启有顺序要求？） worker会定期（3秒）向引擎master发送心跳信号，让master知道该worker仍然存活。 如果没有正常汇报，此时master就会认为这个worker出现了故障，需要重启。 master会向monitor发送任务，让他执行kill指令强制关闭worker，再关闭monitor自身。 此时worker自身的机制就会被触发，自动重启这个引擎worker。 因此如果需要重启master，master重启成功后，必须重启所有worker，否则master将无法判断worker是死是活 |
| 数据存储 | 用来存储FineBI中抽取的基础表和自助数据集数据 注意，数据存储组件中不包括以下数据： Excel数据集：相关文件存储在文件服务器的/WEB-INF/assets/temp_attach文件夹中 直连数据：直连相关缓存数据，由服务器内存+磁盘共同存储 |
| 配置库 | 配置库，也就是老版本所说的finedb，用来存储工程中的一些配置信息。 比如工程里有哪些用户，有哪些目录，用户有什么权限，数据更新任务什么时候执行。 这些配置信息单独存放在一个数据库里，与工程时刻对接，确保了工程长久稳定的运行。 这也就是配置库为什么必须一个项目用一个，为什么不能多个项目共用？会导致配置混乱。 举个例子： 一个多bi业务节点的集群，无论从负载均衡入口进入工程，还是从某个节点访问，都会看到同样的平台风格，看到同样的目录。因为每一个节点，都是从配置库中读取相关信息，然后进行展示。 |
| 状态服务 | 状态服务器是一个监控，它监控每个节点及整个BI项目中各个组件的运行状态、记录日志和错误信息、协调节点间的通信和任务分配等。 举个例子： 当用户在A节点处于登录状态，正常处理业务。但此时A节点宕机了，业务转移到B节点处理，此时B节点怎么知道这个用户在当前电脑处于登录状态？这就依赖状态服务判断，这些信息都存储在redis里 |
| 文件服务 | 文件服务器用于存储和共享集群中所需的文件和数据资源，以确保每个bi节点都可以访问并使用它们 此处列举下一些文件，即可理解文件服务器的作用： FineReport模板文件 FineReport模板备份文件 FineBI的Excel原始文件信息 驱动管理上传的驱动 工程资源文件（地图、图片） 定时调度生成的快照文件 云端运维生成的数据包 工程历史备份文件 |
| 日志服务 | 日志服务，是用于记录每一位用户在系统中的每一次操作，包括登录、访问数据、修改记录等 对于FineBI6.1，ElasticSearch组件取代了原有的Swift引擎，提供日志服务 为什么需要日志： 溯源追踪：能够确保系统操作的透明性和可追溯性，这对于审计和合规性检查非常重要 性能分析：记录系统的运行情况和性能数据，帮助分析和评估系统的性能瓶颈 行为分析：了解用户的行为习惯和使用模式，帮助改进系统功能和用户体验 |
| 6.0/5.x | 6.1存算分离 | |
|---|---|---|
| 稳定性提升 | 计算引擎和bi业务在同一个进程中，用户访问跟查询更新互相影响，宕机之后整个服务崩溃，用户可感知 | 引擎服务与bi业务服务剥离拆分 引擎拆分为独立进程，引擎宕机时业务用户无感知 引擎支持自动重启，可以在分钟级别快速重启 多个引擎节点下，满足真正高可用需求 |
| 可扩展性提升 | 5.x版本： 抽取数据需要通过插件实现主备集群，无法高可用 只支持本地磁盘存储，不能满足用户个性化存储需求 6.0.x版本： 最多支持5个业务节点，集群扩展节点受限 只支持本地磁盘存储，不能满足用户个性化存储需求 | 增加统一数据访问层，将计算引擎与数据存储分离，突破了历史多节点集群，本地抽取数据，持久化同步的瓶颈 计算引擎突破节点数限制，支持横向扩展，数据查询并发线性提升，可满足高并发查询的用户群体 抽取数据支持使用云OSS存储，持久化数据不落地，满足企业数据安全需求 |
| 性能提升 | 日常运维复杂
磁盘用量紧张
| 日常运维操作简单化 FineBI 基础运维操作，均可通过运维平台前端可视化完成。如工程启停、下载日志、生成堆栈dump等，有效降低一部分运维成本 磁盘空间释放 取消多节点同步存储抽取数据，只需要持久化一份数据在数据存储组件，即可确保多个引擎节点调用 |
| 优势 | 说明 |
|---|---|
| 一致性 |
|
| 隔离与安全 |
|
| 简化运维 |
|
| 快速故障恢复 |
|
如果将 Linux 比作一个厨房，那么Docker技术就像是预制菜品。
厨房可以从中央厨房（云镜像仓库）订购真空包装的食品（镜像），并存储在自己的冰柜中（本地镜像仓库）。
厨师（运维人员）可以将这些预制的真空包装食品（镜像）经过简单的操作变成一道道菜品（容器），供顾客“享用”（服务）。
Docker的三大特色1）镜像（Image）：类似于一个安装包，通过这个安装包来创建容器。
2）容器（Container）：利用容器技术，独立运行一个或一组应用，可以通过镜像创建多个容器。容器可以理解为一个简易的Linux系统。
3）仓库（Repository）：存放镜像的地方，分为公有仓库和私有仓库，如Docker Hub、阿里云、Harbor等。
通过Docker，企业可以实现更加高效和灵活的系统管理，提升服务的稳定性和可维护性。
鼠标选中内容，快速反馈问题
鼠标选中存在疑惑的内容，即可快速反馈问题，我们将会跟进处理。
不再提示
10s后关闭
上一篇：了解运维项目测试版与正式版