春节快乐，干货来袭。相较于SDK与后台，Web可以说是直面我们交付的用户了。可以这么说，好的Web“千篇一律”，坏的Web“千奇百怪”。下面我们就来说说，面对“千奇百怪”的Web，我们是怎么做的。前言
经过我们的“千锤百炼”，总结出来在私有化交付中Web的难点无非有两方面：一是用户环境复杂，导致了许许多多的兼容性问题；其次，可能是完全没有共性的用户需求，可以这么说，做公有云，是20%的需求来满足80%的用户，而私有化呢？是99%的需求满足1%的用户，这些需求主要集中在前端。所谓的99%的需求，我们可以理解为这些其实面向的是行业的复杂性。那么，面对这种“千奇百怪”的用户环境，我们该如何提前做好准备，随时应对呢？
我们的实践
1）针对用户环境复杂
痛点：例如是没有外网环境，导致外部依赖的JS包以及CSS包全部都不能有；例如是想象不到的终端屏幕尺寸，也就是根本不知道最终我们业务的体验是怎样的，记得当时在交通银行北京研发中心进行私有化交付的时候，我们观察到用户的屏幕是我们之前没有见过的，在震惊之余，我们也马上购买了同款屏幕进行测试与适配，最终成功解决这个问题。而这也让我们思考，当再次遇上这种问题时，我们应该如何快速响应，如何提前做好准备呢？
解决方案：
（1）终端各尺寸和分辨率屏幕适配方案：
● 尽量使用响应式布局方案，例如flex布局，栅格布局等；
● 设置元素大小及间隔时，尽量使用百分比，而不要直接使用px。
（2）外部资源依赖解决方案：
● 所有的线上资源依赖需要下载为本地资源（例如字体文件，icon资源等等），并统一打包，否则在内网环境中无法正常下载这些依赖；
● 除此之外，尤其还需要注意依赖库引入的外网资源文件，我们需要在打包前的时候扫描node_modules中的代码，一旦发现这些依赖库中引入外网资源，同样需要将这些资源下载到本地，再将node_modules中的引入路径修改为本地路径。
2）针对完全没有共性的用户需求
痛点：在现有的Grafana插件中，针对于不同的报表有不同的插件以及不同的配置和使用方式，这就导致了数据报表配置的碎片化与高基础。同时，由于不同的实现方式又有不同的特性，这就导致了往往很难符合我们的使用场景，而使用SQL和DSL等语句时直接查询又过于危险，例如容易受到SQL注入攻击、XSS攻击等。那么我们的解决方案是什么呢？答案就是设计一个“中间层”解决跨数据源查询的问题，同时基于Grafana的自定义BI报表功能，提供用户可根据自身需求自主定制报表的能力。
解决方案：
1.中间层：RestSQL
首先，我们借用了Grafana的前端展示能力，设计了数据源与Grafana之间的中间层——RestSQL, 用于数据获取处理；
其次，我们定义了一种基于SQL的中间格式，将所有查询语句都先翻译为这种中间格式，以这种方式解决了多语句查询的困难；
最后，为了保护数据源，防止数据库的细节暴露，我们使用了对象的思想，封装了细节于系统内, 只对外展示我们设计的内容。
2.灵活的自定义能力：BI报表
BI报表以Grafana服务的形式开放给用户，考虑到数据安全问题，统一使用自研RestSQL数据源，该数据源与后端通过RestSQL协议进行通信。根据Grafana的API与使用需要，我们在BI报表上定义了大量有助于使用的接口，比如获取当前系统所有表名、获取某个表的所有字段名等等接口。我们以这种方式对外提供服务，帮助第三方基于我们的RestSQL进行二次开发。
具体架构图如下，在RestSQL协议的基础上，我们需要开发以下两部分模块：
● 前端：基于Grafana的RestSQL Datasource插件；
● 后端：RestSQL解析与查询模块。
（QAPM基于Grafana的自定义BI报表：http://km.oa.com/articles/show/455873
BI报表使用文档：https://docs.qq.com/doc/DYWRPWFpFdUFHRU1h ）
写在最后
不管用户环境再复杂，QAPM仍以探索者的姿态不断发现问题、解决问题，坚持为用户提供创新的体验；不管是99%的用户需求还是1%的用户需求，QAPM始终进行探索与优化，最大限度的满足用户的需求。在2021年，我们也希望能一直进步，持续为客户提供高质量的云原生数据服务，与我们的合作伙伴们实现“共赢”。
