超全指南带你玩转可视化大屏
本文从技术和工具的角度分享玩转可视化大屏的开发！
主要是评估一下报表工具开发可视化大屏！
玩转可视化大屏开发工具选择
在常规的数据可视化方式中，可以选择直接读取数据库，通过绘图软件/库进行绘制，最终形成自建的前端展示效果，比如使用Apache ECharts(incubating)等工具。
此外，为了提高效率我们还可以选择成熟的报表套件，往往有一系列图表模板+支持拖放和可视化配置页面，方便我们快速搭建可视化大屏。事实上，大多数套件的机制并没有什么太大的不同。为了不占诸位太多阅读时间，我就只讲某一个套件。
当然报表套件又分为三类：
桌面应用产品生成桌面应用程序，这些应用程序通常直接连接到云端数据库，并要求数据库打开公网IP。一些服务器还将提供crud API以降低数据泄漏的风险
Web上的直连数据库/自建后端产品很少。毕竟，网络已经实现了。有一个服务器不是更好吗？否则，数据库还是应IP开放。
B-S产品，服务端提供与多源数据库的连接、数据提取、前端页面生成、前端负责显示、用户交互和动态刷新等功能。
本文选择第三类的一款套件作为讲解 —— 帆软 FineReport，选择此产品原因：
1、国产软件，支持中文目录、中文配置界面，对于国内用户友好度高
2、目前国内领域第一梯队的报表工具，可视化大屏开发技术成熟
（注：我会从可视化报表工具的角度出发客观讲解，而不是针对某个具体的产品，只是为了形象且可验证性会给出 FineReport 在下面各方面的实践/方案，不作任何补充评论，也不会带主观想法的）
既然是个套件应该有完善成熟的功能，我们就以下维度来聊聊：
环境与基础设施：设计平台，安装环境，故障传递与追溯，数据安全，协作开发，功能扩展性
视觉效果与用户交互：布局，配色，交互，可复用组件，组件自定义
设计平台
首先说说设计平台，一般分为两类类：
对于传统桌面应用的设计器，一般是直接安装和打开的。对于B/S类别的产品，设计器安装包通常附带一个服务，该服务可以在启动后自动运行可以调试的服务环境。
基于Web的设计器。设计器支持同时设计和提供演示服务，就是在构建之后，他们根据登录帐户的角色进入不同的环境，还有一些是完全相互独立的环境。
FineReport 属于前者，有不同安装包适配不同的系统环境，安装简易，配置要求简单。
安装环境
对于B/S产品，它类似于构建后端，但不需要复杂的配置。你可以根据教程安装，直接启动该服务即可。
此步骤可能会受到稍后讨论的功能扩展性的影响，如果产品具有功能可扩展性，则需要在服务上单独部署扩展的补充功能，并进行相关连接配置。如果扩展基于插件，则需要在服务端上安装相应的插件。建议打造一份完整的环境构建文件。如果产品可以通过脚本安装，可以直接将部署过程脚本化。
FineReport 环境安装也是安装包直接打包安装，具有插件平台，若有需要的额外插件需要通过 web 登录后下载对应插件。
故障传递与追溯
在企业数据应用阶段，可视化大屏往往是在数据可视化之后慢慢生成的。可视化大屏通常是单页信息含量极重、涉及的业务部门众多、数据分析维度周密。因此，从技术角度来看，我们需要确保单个故障不会大范围影响其他信息，例如：
设计器的故障是否会影响服务端？特别是通过 role 区分环境的 web 设计器。
某一指标的计算错误是否会导致同页面无法显示其他指标？
某一指标计算响应慢是否影响同页面其他指标响应慢？
对于故障还有额外要做的是实时处理方式：
关键指标计算错误是否应该预警？因为可视化大屏运行状况也是一个指标呢
指标计算错误时显示0还是直接显示现实错误？特别注意某一指标具有特殊的存在性价值时，不建议用同类型数据代替显示，以防统计出错
虽然可以保证故障扩大的可控性，但我们也希望追溯产生问题的不利因素，因此，我们需要确定相关产品是否有足够的日志，特别是数据库的交互执行语句和执行响应。
然后说 FineReport：
报表某一指标计算错误不会影响其他指标显示。
单一指标计算速度慢不会影响整体运行速度，会逐步更新计算的指标值，但初始打开页面布局时计算过程中未算得结果有错误的几率，此问题会逐步计算后实时动态调整布局，最终达到正确页面。
在设计和调试阶段有一个完整的执行日志，可以查询执行的SQL指令追溯计算错误，然而，对于复杂多层嵌套/页面联动等相关行为的追溯会耗时费力，因此我们可以考虑开发日志处理工具。
数据安全
在理论里，数据库不建议使用公网IP，对上面说的三个类型的来说就是：
桌面应用程序：此类程序通常不支持直连数据库，但可以通过自建后端或套件的后端获取数据。
web 直连产品：此类产品只提供基于 Web 的UI快速搭建，和后台框架很像，具体的数据读取方式可以选择 API或直连数据库，自主维护数据安全。
B-S 产品：这种类型的产品提供完整的前端和后端，后端负责连接多源数据库，前端则负责接收数据和发送指令，可以更好的保护数据库的安全，只需将服务端和数据库放在同一个云提供商中，就可以避免使用公共IP。但是，相同的风险转移到此类产品的后端，无论是该产品提供的后端服务还是基于web的后台。
FineReport作为 B/S 产品，有完整的服务端，前后端交互在数据方面用POST发送请求。
简单查看：请求参数是控件 id、控件内容、行为等，不涉及到要执行的 sql。返回结果为控件信息及控件内数据。用于确定是否有遗漏的情况，使用 SSL 可进一步提高安全性。
协作开发
报表不是一件简单的事情，无论是通过数据仓库还是数据中台的方式，就业务价值来讲，我们首先突破了部门壁垒，然后让各个部门的数据发生互动，开发出更多的剩余价值，这导致了我们报表业务的复杂性和庞大的工作量，以至于需要进行协作开发，特别是可视化大屏开发上。
一个可视化大屏可能有几十个模块，每个模块几个或者更多分析指标，一个页面上可以轻松显示上百指标，由此可见协作的重要性，所以需要把可协作性加入到开发里。
首先，针对协作性我们需要考虑以下问题：
协作过程数据库连接方法：由于数据库在云服务器上，出于安全考虑不会开放对外接口，推荐三种方式：① 使用 QA 环境，如果 QA 环境已经积累了较多虚假数据且不太重视数据结构安全性，可考虑此方案，但不太推荐。② 使用VPN，可以在本地VPN 连上数据库。③ 使用云服务器，通过云上开发来实现在内网访问数据库。
单一页面分工开发方法：一个页面一百多指标数量，根据业务内容分组安排任务，还考虑工具记录文件是否可以自动 merge，若不能自动 merge，还要考虑 怎么人工 merge，merge 时是否完整保留逻辑以及布局等信息……
重复性样式是否可方便复用：当样式重复只是逻辑和标题/标签的区别时，是否可以复用，是否可以套用模板，复用后是否能保证只是逻辑改变，其他完全一致，以保证样式的稳定性
……
FineReport支持通过将工作目录更改为远程工作目录直接启动协作开发，此方法只将设计文件的存储位置放在远端，实际操作执行仍然是本地的，这类似于设计文件版本管理器。
功能扩展性
产品是否提供模块化或插件平台，通过公开关键流程节点接口或其他方式支持第三方插件和定制组件的接入，实现未来“无限可能”。
插件包括但不限于：
更多地图表模板
用户交互过程更多的动画效果
花式提示框
设计阶段布局工具
运行阶段日志处理工具
整体的配色方案（皮肤? 主题?）
自定义计算模板/公式、领域专业公式集
鉴权认证插件
数据库驱动
……
FineReport有插件平台，里面有多种分类分组，有官方插件及第三方插件，也有插件开发 API 文档。
布局与配色
是否有整体的配色方案？便于在定制需求低的情况下快速成型，比如夜间模式……
设计阶段是否能进行常规的布局：水平、垂直、栅格、流、填表专用（label+editbox）……
图层、透明度、可见性、盒模型
特效方面是否可控制事件流
响应式布局
在FineReport布局上，可以选择绝对布局（全部手动拖动）或自适应布局，这可以配置双向单项（水平、垂直和网格），并配置内部边距和组件之间的边距。
交互
图自动刷新
图表联动
参数配置联动
动画效果
提示窗口
可复用组件
可复用性还直接或间接影响协作开发的效率、最终显示效果的一致性等。
FineReport提供了一个网页插件，它可以通过插入网页控件引用其他组件，并以嵌套方式组合各种显示块。
还提供了模板插件，通过将多个选定组件打包到一个模板中，并打包组件之间的布局关系和数据操作逻辑，实现了逻辑、关系和控件的整体迁移和复用，但是，它只能记住布局关系，不能记住布局的最终大小。在多次复用之后，需要自己调整总体大小
组件自定义
这种类型的工具通过各种通用长久的功能来提高开发效率，但不可避免会碰见特殊需求，所以就需要高度自由的开发，如提供插件平台、组件设计方法、API接口、可编程性等
FineReport提供了对 JS 的支持，可以在很多空间里在点击等操作时触发对应的 JS 脚本，后面就看开发自己的了。
FineReport提供对JS的支持，在许多空间中点击和执行其他操作时，可以触发相应的JS脚本，但下面就只能靠自己开发了。
同时，还有一个插件平台，可以通过插件持久化重复使用的功能，还有模板插件，可以持久化重复的组件/组件集。
立即沟通
