用户资料门户的构建

1. 需求背景

老的页面停止维护了,且老旧, 功能单一,且页面分散. 急需做功能集成的平台化建设
原先的用户资料查询没有做权限管控, 每一次查询都会消耗我们组的人力资源.

2. 项目介绍

2.1. 项目地址

服务地址: [公司内网服务(略)]
工蜂地址: [公司内网仓库(略)]

2.2 项目的价值

进行平台化建设, 整合用户资料相关的所有功能, 方便使用者能一站式的解决问题
做好权限管理和管理员管控, 让所有人的查询都有迹可循, 可解放人力资源.
改造老的功能, 重构老的代码. 让现在的项目拓展性和可维护性更高, 后续交接项目更容易

2.3 项目的痛点

权限的细腻度划分

在进行权限管控时, 需要考虑到权限的细腻度问题, 往往相同小组中, 一个人需要使用到此功能, 那么小组的其他人大概率也会使用, 那么以小组为单位划分权限呢? 还是以个人为单位划分? 这里考虑到一些特殊情况(如, 某个小组的某个人可能需要管理员身份, 并且以小组为单位更容易信息造假), 所以采用的是以个人为单位划分权限. 不仅如此, 由于UDC/virtual字段众多, 并且有一些隐藏字段, 所以单纯的以人为单位做权限管控还不够, 这里采用的是以人+字段的方式做权限管控, 即: 某个人只能拥有某些字段的权限, 你无法查询到你没有权限的字段的信息(如你拥有20002/20031字段的权限, 但你去查询任意uin的20025字段的信息是会被拦截的

pb调用的动态性

项目中会用到RPC调用拉取用户信息, 用RPC调用就离不开protobuf, 而在当前项目的场景下, 使用普通的.proto文件作为源数据来源显然是不可行的, 主要有以下几点: (1) UDC字段和虚拟字段一共有上千个, 如果要使用.proto文件, 就需要在message中写上千行信息, 并且字段的数量是在不断增加的, 每增加一个字段就需要修改一次.proto文件. (2) 使用者每次查询的字段是动态变化的, 一次RPC调用中只需填使用者需要查询的字段. 基于上诉情况, 不得不抛弃传统的.proto文件作为源数据. 这里使用了protobuf的反射, 在程序运行时通过使用者传来的参数, 动态的构建,proto文件, 将使用者的输入作为源数据.

面对海量查询时的资源分配问题

在用户信息查询界面, 可以使用导入号码包的功能, 批量的查询uin信息. 一旦号码包中的uin过多(比如百万个), 后端的处理就会很慢. 并且机器资源有限, 不能采用负载均衡等操作来减缓服务器压力. 这里采用注册任务式的异步处理来完成任务, 使用者导入一个号码包来查询时, 主服务会在MySQL插入一条任务信息, 异步服务会串行的执行任务(不使用协程去办法完成任务的原因是, CPU资源有限). 使用者可以在查看任务清单界面, 查询任务的完成情况, 并能导出已完成的任务的数据

2.4 项目的基本使用

2.4.1 项目概览

项目支持的功能:

单uin单field查询
多uin多field查询
导入号码包进行异步查询
UDC字段的解释查询
虚拟字段的解释查询
用户资料修改的流水记录查询
管理员功能

2.4.2 使用说明

申请字段权限 --> 管理员通过 --> 使用自助工具

申请字段权限. 申请后, 请联系neokou/daviadai/hansonliang通过申请. 请一次性申请完你所需要的所有权限, 在已有权限的前提下二次申请, 会将之前已有的权限覆盖. 可以在查看审批进度的页面关注自己的审批流程

在这里插入图片描述

自助工具的使用. 自助工具分为普通的单uin查询和导入号码包查询两个功能. 单uin的查询是同步的, 而导入号码包的查询是异步的. 使用导入号码包创建任务后, 可以在查看任务清单页面关心任务的进度, 并且可在此页面导出查询结果的文件

注: 由于无极平台发包有大小限制, 导入号码包后若出现卡死, 证明此包已被无极丢弃. 后续会采用新的方案来解决此问题(十万个uin以内能正常工作)

2.5 项目的整体架构

3. 项目未来的拓展手段

代码的整体框架:

├── ao(业务逻辑代码)
│   ├── log
│   │   └── trading_handler.go
│   ├── robot
│   │   └── robot_handler.go
│   └── user
│       ├── authority_handler.go
│       ├── table_handler.go
│       └── tool_handler.go
├── async_task(异步服务)
│   ├── ao
│   │   └── rece_handler.go
│   ├── async_servers
│   │   └── servers.go
│   ├── async_task
│   ├── dao
│   │   └── mysql_dao.go
│   ├── main.go
│   ├── repo
│   │   └── processing.go
│   └── trpc_go.yaml
├── config(七彩石配置)
│   └── ── rainbow.go
├── copy(protobuf反射代码)
│   └── copy.go
├── dao(与MySQL和本地文件交互)
│   ├── file
│   │   └── file_dao.go
│   └── mysql
│       └── mysql_dao.go
├── entity(全局变量和实体)
│   └── comm.go
├── go.mod
├── go.sum
├── main.go
├── parse(字符串解析)
│   └── parse.go
├── repo(数据处理方法)
│   ├── log
│   │   └── processing.go
│   ├── robot
│   │   └── processing.go
│   └── user
│       ├── oidb.go
│       └── processing.go
├── servers(不同的路径路由)
│   └── servers_select.go
└── trpc_go.yaml

3.1 数据库的拓展

新增数据调用只需在原有的对象基础上, 增加一个你需要的对象. 并且实现接口方法即可

3.2 功能的拓展

现在的项目将日志查询, 用户资料查询, 机器人服务等模块做了解耦合

thttp.HandleFunc("/wxcb", servers.ServHTTPRobot)
thttp.HandleFunc("/wxcb1", servers.ServHTTPSelfTool)
thttp.HandleFunc("/wxcb2", servers.ServHTTPAuthorityManagement)
thttp.HandleFunc("/wxcb3", servers.ServHTTPFrontTable)
thttp.HandleFunc("/wxcb4", servers.ServHTTPQueryJournal)

拓展时只需为新的服务开辟一个路径, 并且在ao(Application Object), repo(Repository)文件中完成它的具体实现即可

3.3 权限管控的拓展

目前在数据库9.146.56.25中, userInfo用于保存所有人的权限. privilege为1代表是普通用户,只有读权限. privilege为3或者4代表管理员. privilege为4代表有查询流水记录的权限. 管理员的field字段都为1,代表有所有字段的查询权限

在这里插入图片描述

后续新增功能的权限管控可以沿用这种形式, 或者对这种方式做改造(代码只需要微调) pri为1代表只有查询用户数据的权限, pri为4代表是管理员, 可以使用所有权限. 目前资料修改的流水查询, 默认只有管理员才能使用, 若后续想要对普通用户开放, 可以自行设置字段, 并且在LOG代码中未改判断条件即可