[System Design] BI资源服务 (ResourceService)

Posted by Akilis on 26 Jun, 2021

职责与定位

面向业务，整合BI metadata（存储在MySQL），对内（BI内部各服务），对外(第三方服务)提供统一出入口。
Metadata以资源实体及资源间关系承载，按业务领域（例如可视化、数据集）内聚沉淀通用功能。
ResourceService本身以RESTful API形式输出资源管理功能，在资源领域的业务中，ResourceService尽可能负责端到端的，做到服务自治，减少依赖内部其它服务。其它情况下，与各业务服务（例如DataService/VQS）配合完成实际需求。

系统框架

服务间交互

Client (终端用户)
- BI前端Browser
- BI Python SDK
- 第三方服务ThirdParty Service。
BI Service Eco (BI生态系统，涵盖BI后端的各子模块)
- BI后端服务 (BI BE)
  - 数据服务DataService
  - 可视化VQS
  - 智能服务InsightService（包括归因Find, 聚类Intellia）
- BI内部支撑服务 (SuppportWare)
  - 基础服务BasicService (提供用户、权限等操作接口，目前存在于DataService)
  - 元数据服务MetaService（BI BE已有资源相关功能，可沉淀为内部通用接口）
  - 前端可视化服务VizSchemaService (提供例如图表底层数据集替换等能力)
- ResourceService: BI资源服务自身。
备注
- 主服务无可避免的会有依赖，或者在原有处理逻辑下进行扩展。至于数据库的读取(DAL)，微服务共享DAL，各自定义ORM models，实现自己领域的业务才能服务自治、独立开发。

服务架构

分析大致需求，归纳到相关领域内解决问题。转化为对资源属性一系列操作，通过下沉通用性接口，达到尽可能解耦合，高度复用的目标。

Domain
按业务分割代码模块，便于之后可能的微服务孵化；面向资源对象建模，领域内聚并保障操作的原子性；对外暴露服务层接口。
Public interface
业务入口，承接RESTFul请求，组合Domain的服务接口，完成需求处理，返回应答。
Infrastructure
基础设施层，采用ORM设计数据接入层(DAL)访问元数据；设计通用的缓存装饰器(Cache)，加速重接口。
HTTP Client
对外转发(Stub)或者请求(Live)外部服务，包括BI内部的SupportWare，以及其他中台服务。从鲁棒性上，考虑重试、熔断等能力。

服务部署

采用Flask web快速开发RESTful服务ResourceService。
Web Server 选用Gunicorn，考虑到业务场景绝大多数应当是短链接，采用sync worker类型，缩短延时，提高并发能力。
对外通过域名方式访问，采用基于均匀随机的负载均衡策略。
使用外置Cache加速某些查询相关的重接口。
直接读写metadata存储装置，整合元数据，实现业务功能。

控制和数据协议

RESTful API
- ResourceService本身无状态，Endpoint描述资源目标和操作，采用JSON传递数据。
- 下面介绍应用图表r1的样式到新数据集d1的案例，说明客户端与服务器之间，以及BI内部服务之间如何交互。

JWT Token
- 考虑到效率与安全，BI后端各子模块之间通信时，携带token认证。
- token存储格式满足JWT规范，内容包括服务的身份信息。
- 统一生成、管理各子服务token。以ResourceService为例，ResourceService请求内部支撑服务时，使用代表自身身份的token；ResourceService自身配置授权token列表，其它服务访问ResourceService时也会携带身份token且该token已被ResourceService授权。

BI资源领域抽象(Resource domain abstraction)

资源对象模型属性

Comment
在资源不同粒度上，例如在Report上某时刻的指标进行评论，甚至对Report本身进行标注。
Composite
同种资源间以目录层级组织，树形结构化. 例如仪表盘。
Lineage
不同种资源间，具有依赖关系。例如典型的一条血缘依赖关系：DataTable -> DataSet -> Report.
Template
复杂模式构建的资源样式可以快速应用到其它上游资源。例如应用已存在的图表样式到某个新数据集，新数据集包含旧数据集的底表字段。
Connection
第三方扩展资源管理，以及关联BI内部资源。例如指标平台元数据关联BI图表。
Ownership
BI资源在项目(Project)粒度上进行隔离，所有资源都具有项目归属性。

资源操作类型原语

资源的不同属性有不同操作，为了满足跨项目迁移、复用模板、扩展关联第三方资源、评论标注、以及删除治理的场景需求，提出以下原语：

Transfer
跨项目移动资源。改变资源的Ownership。
Rebind
重绑定。改变资源的Lineage。例如发生在上游替换场景。
Apply
模板应用。应用模板样式到新的上游资源，可发生在具有Template属性的资源身上。
Upstreaming/Downstreaming
溯源. 往上游/下游应用当前操作。发生具有Lineage属性的资源身上。
Tag
打标。关联外部扩展资源，发生在可做关联(Connection)的资源身上。
Clone
资源复制。需要注意区分deep/shallow。
Generate
创建资源及衍生物。
Freeze
删除、回收、禁用资源，及其下游资源。
Relocate
在目录层级组织中移动资源，调整目录结构。
Locate
定位资源在目录层级组织中的位置。
Link
跨项目链接资源。复用资源以分享，而不用重复创建，造成资源浪费。

可行性展示

本节以一个实际需求，根据系统设计进行技术推演，证明可行性。同时提出落地接口的设计范式。

需求
将项目p1下的仪表盘d1（ID=2，可能是某个子目录）以及仪表盘包含的图表所依赖的数据集，移动到项目p2 (ID=456) 下的仪表盘目录d2 (ID=3)中，数据集也随之移动到项目p2下。
技术
主要资源涉及Dashboard/DashboardDir, DataSet, Project. 资源Dashboard/DashboardDir具有Composite属性，需要进行Transfer操作，同时要把上游依赖的数据集资源也进行移动，即Upstreaming。

接口

总体说明
- 所有请求path携带前缀/BI/resource/v3
- 所有请求header
  - 携带访问者token: x-BI-auth
  - content-type为 application/json

Endpoint

Path
/projects/{project_id}/transfer
Path variables
- project_id: 原项目ID
Method
POST 200 OK
Query parameters
Headers

Request

Example

{
  "email_prefix": "leo",  // 请求用户身份标志
  "resource_type": "dashboard",  // 资源类型
  "departure": 2,  // ID为2的仪表盘或文件夹以及目录内容
  "destination": {
    "project_id": 456,  // 目标项目ID
    "arrival": 3  // 挂在到ID为3的目录下。空表示根目录.
  },
  "upstreaming": true  // 是否同时迁移上游依赖的资源到目标项目
}

Note
- resource_type支持{app, dashboard, data_set}。app下，departure不生效; dashboard下，departure可以指定某个dashboard ID; data_set下，departure可以是null (移动项目下所有数据集) , dataset ID, 或者ID列表。

Response