本文從技術和工具的角度分享視覺化大屏的開發！

主要是對報表工具開發視覺化大屏做測評！

視覺化大屏開發工具選擇

常規的資料視覺化方式我們可以選擇直接讀取資料庫，透過繪圖軟體/庫進行繪製，最終構成自建的前端顯示效果，比如使用 Apache ECharts (incubating) 等工具。

除此以外，追求效率的我們還可以選擇成熟的報表套件，這類套件往往具有一系列的圖表模板+支援推拽且視覺化的配置頁面，方便我們快速的構建出視覺化大屏。其實大部分套件的機理差異並不大，為了降低文章內容量，本文直接講解某一種套件，

當然報表套件又分為三類：

• 桌面應用產品，生成的是桌面端程式，程式往往直接連線雲端資料庫，需要資料庫開放公網 ip。也有部分會有服務端提供 crud api 來降低資料洩露風險
• web 端直連資料庫 / 自建後端產品，這種產品較少，畢竟已經做到 web 了再配個伺服器豈不是更好，否則還是要資料庫開放 ip
• B-S 產品，服務端提供與多源資料庫的連線、資料提取、前端頁面生成，前端負責顯示、使用者互動與動態重新整理等等

本文選擇第三類的一款套件作為講解 -- 帆軟的 FineReport，選擇此產品原因：

1、國產軟體，中文文件、中文配置介面，對於國內使用者友好度高

2、國內基本最領先的報表工具，視覺化大屏開發成熟

（注：我儘量從視覺化報表工具的角度出發描述，而不是針對某個具體的產品，只是為了形象且可查證會給出 FineReport 在下面各方面的實踐方式 / 方案，不作任何額外評價）

既然是個套件應該有很多完整成熟的功能，我們以這幾個維度來聊聊：

• 環境與基礎設施：設計平臺，安裝環境，故障傳遞與追溯，資料安全，協作開發，功能擴充套件性
• 視覺效果與使用者互動：佈局，配色，互動，可複用元件，元件自定義

設計平臺

首先說說設計平臺，一般分為兩類類：

• 傳統的桌面應用的設計器，前者往往直接安裝開啟使用即可，對於 B/S 類的產品，往往設計器安裝包會自帶一個服務在啟動後自動執行可用於除錯的服務環境
• 基於 Web 的設計器，這種設計器有些是支援同時設計與提供展示服務的，即一次搭建後根據登入賬號的 role 進入不同的環境，有些是完全分離的兩套環境。

FineReport 屬於前者，對於不同系統均由輕鬆安裝的安裝包，不需要複雜配置。

安裝環境

對於 B/S 產品，和搭建後端類似，只是不需要複雜的配置了，直接根據教程安裝一下就即可啟動服務.

對於後續要說的功能擴充套件性，可能會影響此步驟，如果產品具有功能擴充套件性，那麼額外擴充套件的功能需要單獨部署在服務上並配置相關連線，如果是基於外掛化的擴充套件需要在服務端安裝對應外掛。此部分建議構建完整的環境搭建文件，如果產品可以透過指令碼安裝，建議直接將部署過程指令碼化。

FineReport 環境安裝也是安裝包直接搞定，其具有外掛平臺，若有補充外掛需要透過 web 登入後新增對應外掛。

故障傳遞與追溯

企業資料應用階段，往往資料視覺化以後就逐漸地產生了視覺化大屏。視覺化大屏往往單頁面資訊含量極其豐富、跨越的業務部門繁多、資料分析維度全面。所以從技術角度來講，我們需要保證單一故障不會大面積的波及其他資訊，比如：

• 設計器出現故障是否會影響服務端？尤其是透過 role 區分環境的 web 設計器。
• 個別指標的計算錯誤是否會導致同頁面其他指標均無法顯示？
• 個別指標計算緩慢是否影響同頁面其他指標均無法重新整理？

對於故障還有額外要做的是實時處理方式：

• 關鍵指標計算錯誤是否也要報警？因為視覺化大屏執行狀態也許也是一個指標呢
• 指標計算錯誤時顯示 0 還是現實錯誤資訊？尤其注意在指標具有其獨特的存在性意義時，不建議隨意的用同型別資料作為展示，避免錯誤統計
• 雖然我們保證了故障波及的可控性，但我們還希望能夠追溯到問題產生的原因，這就需要確定相關產品是否有足夠的日誌，尤其是需要在於資料庫互動式的執行語句與執行響應。

繼續說 FineReport的情況：

• 報表單一指標計算錯誤不會影響其他指標顯示。
• 單一指標計算速度慢不會影響整體開啟速度，會逐步更新算的指標值，但初始開啟時計算過程中未算得結果的在頁面佈局上有一定機率不正確，此問題會逐步計算後動態的調整佈局，最終效果正確。
• 設計除錯階段有完整執行日誌，可查詢執行的 sql 指令追溯計算錯誤問題，但對於複雜多層巢狀/頁面聯動等行為追溯相對複雜可考慮開發日誌處理工具
• 生產環境（伺服器版）部署後的日誌並未調研

資料安全

理想狀態下，我們的資料庫不應該使用公網 IP，這方面針對前面提到的三種型別：

• 桌面應用程式：此類程式往往也支援不直接連線資料庫，可以透過自建的後端或套件的後端來獲取資料。
• web 直連產品：此類產品只提供了基於 Web 的 UI 快速搭建，類似於後臺框架等等，具體的資料讀取方式可以選擇 API or 直連資料庫，需要自行維護資料安全。
• B-S 產品：此型別產品完整的提供了前後端，後端負責和多源資料庫的連線，前端只負責接受資料、傳遞指令，相對可以更好地保護資料庫安全，只需要將服務端與資料庫放到同一雲供應商，避免開啟公網 IP 即可。但同樣的風險轉嫁到了此型別產品的後端，無論是後端服務還是此產品提供的基於 Web 的後臺。

FineReport作為 B/S 產品，有完整的服務端，前後端互動在資料方面一般以 POST 請求。

簡單檢視：請求引數是控制元件 id、控制元件內容、行為等，不會涉及到要執行的 sql。返回結果為控制元件資訊及控制元件內資料。不確定是否有遺漏的情況，再加上使用 SSL 可進一步提高安全性。

協作開發

報表並不是一件簡單的事情，無論是經過數倉的手段還是資料中臺的手段，從業務角度來看，我們都是先打破了部門壁壘，然後讓各部門資料相互碰撞，挖掘出更多的剩餘價值，這就導致了我們報表業務的複雜性以及開發的工作量，我們不得不進行協作開發，尤其是視覺化大屏。

一個視覺化大屏可能有幾十個模組，每個模組有三五個甚至更多一些的分析指標，一個頁面上輕鬆可以出現過百的指標，因此能夠讓開發過程可協作是極其重要的環節。

首先對於協作我們需要考慮下面幾個問題：

• 協作過程資料庫如何連線：由於資料庫在雲上，為了安全也不會開放對外介面，此時推薦三種方式：① 使用 QA 環境，如果 QA 環境已經積攢了足夠多的虛假資料且對資料結構安全性並不敏感，可考慮此方案，但不太推薦。② 使用VPN，讓我們能夠在本地經過 VPN 連上資料庫。③ 使用雲伺服器，透過雲上開發來實現在內網訪問資料庫。
• 單一頁面分工開發方法：一個頁面過百指標數量，根據業務內容進行一定分組安排任務，但同時要考慮如何此工具的記錄檔案是否能夠自動 merge，如果不能自動 merge 如何進行人工 merge，merge 時能否正常的保留邏輯以及佈局等資訊……
• 重複性樣式是否可方便複用：當樣式重複只是邏輯和標題/標籤差異時，是否能複用，是否有模板的概念，複用後是否能保證只是邏輯改變其他具有完全一致性以保證風格統一

……

FineReport支援透過更改工作目錄為遠端的工作目錄的方式，直接開始協作開發，此方式只是將設計檔案的儲存位置放到了遠端，真正操作執行等還是在本地，類似於一個設計檔案版本管理器。

功能擴充套件性

產品是否提供了模組化 or 外掛化平臺，以透過公開流程關鍵節點的介面或其他方式來支援第三方外掛、自定義元件的接入，來實現“無限可能”的未來。

外掛包括但不限於：

• 更多地圖表模板
• 使用者互動過程更多的動畫效果
• 花式提示框
• 設計階段佈局工具
• 執行階段日誌處理工具
• 整體的配色方案（皮膚? 主題?）
• 自定義計算模板/公式、領域專業公式集
• 鑑權認證外掛
• 資料庫驅動
• ……

FineReport有外掛平臺，包含多種分類分組，有官方外掛及第三方外掛，且有外掛開發 API 文件

佈局與配色

• 是否有整體的配色方案？便於在不追求高度定製的情況下快速成型，比如夜間模式……
• 設計階段是否能進行規範的佈局：水平、垂直、柵格、流、填表專用（label+editbox）……
• 圖層、透明度、可見性、盒模型
• 特效方面是否可控制事件流
• 響應式佈局

FineReport佈局上可以選擇絕對佈局（一切靠手拖拽），或者選擇自適應佈局，其可以配置雙向單項（水平、垂直、柵格）同時可配置內邊距與元件間邊距。

互動

• 圖自動重新整理
• 圖表聯動
• 引數配置聯動
• 動畫效果
• 提示視窗

可複用元件

可複用性也直接或間接地影響到了協作開發的效率、最終展示效果一致性等多方面。

FineReport提供了網頁外掛，可透過插入網頁控制元件來引用其他的元件，以巢狀的方式組合多種顯示塊。

還提供了模板外掛，透過將選中的多個元件打包成一個模板，同時打包了元件間佈局關係、資料操作邏輯，實現了邏輯、關係與控制元件的整體遷移複用，但其只能記憶佈局關係，無法記憶佈局最終尺寸，在多次複用後需要調整整體的尺寸問題。

元件自定義

此型別工具是透過將多種常用功能進行持久化的方式提高開發效率，但難免遇到特殊的需要，這時候就需要高度的自由行，比如提供外掛平臺、元件設計方式、API 介面、可程式設計……

FineReport提供了對 JS 的支援，可以在很多空間裡在點選等操作時觸發對應的 JS 指令碼，後面就看開發自己的了。

同時有外掛平臺，可將重複使用的功能透過外掛的方式持久化，有模板外掛，可將重複的元件/元件集進行持久化。